
“Intel Core 2 bugs will assuredly be exploitable from userland code” (2007) - pixelmonkey
https://marc.info/?l=openbsd-misc&m=118296441702631&w=2
======
jlgaddis
This image is linked in the e-mail thread, with (some of?) the errata:
[https://www.geek.com/images/geeknews/2006Jan/core_duo_errata...](https://www.geek.com/images/geeknews/2006Jan/core_duo_errata__2006_01_21__full.gif)

I'm just surprised that the URL is still valid after 12 years!

~~~
agumonkey
same, and don't bother reading too much, the best bugs came after ...

incredible how I (we) ran on buggy hardware for so long.

We should fund a tiny group for sane cpu design.

~~~
busterarm
> We should fund a tiny group for sane cpu design.

It's happened, again and again. The ARM CPUs powering your phones are a good
example. Maybe with more of a market, POWER9 prices might come down.

~~~
agumonkey
Half recent application class arm core are affected.

They are saner but the problem is still here

~~~
busterarm
I was more trying to point to RISC in general ("RISC is good"
[https://www.youtube.com/watch?v=wPrUmViN_5c](https://www.youtube.com/watch?v=wPrUmViN_5c)).
What I really wanted to say is that we've tried but RISC hasn't really been
successful in the (mass consumer) market, which because of ARM is only
partially true.

In truth you're correct, and ARM is sort of an unruly mess at this point, but
that's a much larger discussion.

------
ycmbntrthrwaway
See also, Kris Kaspersky claimed he was able to exploit some of them in
browsers back in 2008:
[https://news.ycombinator.com/item?id=16076941](https://news.ycombinator.com/item?id=16076941)

------
nasredin
Prescient money quote:

>As I said before, hiding in this list are 20-30 bugs that cannot be worked
around by operating systems, and will be potentially exploitable. I would bet
a lot of money that at least 2-3 of them are.

------
colemannugent
Wow. This is bad for Intel. Industry experts have been expressing concerns for
this for ten years. Does this open Intel up to possible repercussions?

~~~
forapurpose
> Industry experts have been expressing concerns for this for ten years.

AFAICT, de Raadt was concerned about Intel in general, but not the recent
exploits in particular. We can find endless criticisms of every major company
from the last 10 years (including on HN!); picking this one mailing list
posting is bit arbitrary in the context of these exploits, even if de Raadt
makes some good general points.

~~~
mrep
I work with a bunch of hardware engineers who used to work at intel and the
really knowledgeable ex-intel guy I know said speculative execution has always
been known to be risky but actually exploiting it was presumed to be very
difficult/impossible.

Looking back, I should have asked him how intel evaluates security risks
considering how much of modern day computing uses it (which makes it an
extremely valuable black hack exploit since it can work on practically every
computer).

~~~
mannykannot
In practice, if you cannot demonstrate an exploit, your concerns will be
heavily discounted, and this is a case in point. Even if you do show an
exploit, attempts will often be made to dismiss it as infeasible in practice
(this is for security issues in general, not specifically Intel.)

------
nmjohn
The linked intel erata pdf file is 404'ing, but I think this [0] matches if
you are curious about this line:

> Note that some errata like AI65, AI79, AI43, AI39, AI90, AI99 scare the hell
> out of us.

[0]:
[http://download.intel.com/design/processor/specupdt/313279.p...](http://download.intel.com/design/processor/specupdt/313279.pdf)

~~~
buryat
ugh, I checked some of them, and most of them suggest accessing protected
memory.

I believe that Intel didn't believe that these bugs suggest a fundamental
issue that can be exploited, until Google Project Zero created a working
exploit.

------
jokoon
I know I will sound like a conspiracy theorist, but can those bugs be
intentional? I mean if you are a security agency, would it be possible to push
for the introduction of such bugs?

~~~
jerf
Occam's Razor suggests to me that intelligence agencies have not had to push
for processor bugs, on the grounds that A: we can adequately explain the
initial existence of these bugs by normal engineering, marketing, and
management considerations such as almost everyone here has experienced
personally and B: the field of the bugs that come from my first point is so
ripe that the intelligence agencies are better served by examining them
carefully and finding their own exploits. The primary reason for this is that
the best hidden paper trail is the non-existent paper trail; by finding bugs
independently and holding all knowledge within the agency, there is zero risk
of it ever being revealed that they deliberately inserted bugs into the CPU,
which would be a PR disaster for all concerned (and to a non-trivial extent,
an act of war).

Given that we _know_ that intelligence agencies have asked for backdoors
before, in both hardware and encryption standards, do not interpret my post
here as a claim that they would never ever even think of asking for plausibly-
deniable CPU bugs to be inserted into hardware. I am just saying that Occam's
Razor says we should prefer the perfectly plausible scenario I gave above
where they do not have direct involvement in these bugs, not because of their
pristine ethics, but because given the circumstances on the ground, actively
intervening is not their best choice from their point of view using their
valuation function, when they can attain all their goals without active
intervention.

(I'm willing to believe in things that might be labelled "conspiracy
theories"; history is rife with proof that they have existed in the past, such
as the aforementioned cases where we know backdoors have been inserted into
crypto standards, as well as other things such as the way in which the Soviet
Union was created which essentially involved what was initially a small
conspiracy, and I see no reason to believe they have ceased in the modern
times. But I want to see how the conspiracy theory passes Occam's Razor; many
of the conspiracy-minded, in my opinion, underestimate the randomness and
everything-is-always-correlated-a-bit-ness of the real world.)

~~~
crdoconnor
>there is zero risk of it ever being revealed that they deliberately inserted
bugs into the CPU, which would be a PR disaster

Since neither the threat nor the reality of PR disasters has ever given the
NSA pause before, occam's razor strongly suggests this theory of yours is
wrong.

~~~
jerf
Since the threat of PR disaster is just an ancillary bit of evidence, rather
than core to my logic, even if I accept your point entirely (which I do not),
it is not sufficient to destroy my argument. Of the motivations I gave, the
one I would expect to be most powerful is the general desire to keep things
internal without involving any external resources, which is just a general
operational security principle.

I would also disagree that your assessment is correct anyhow; they are
insensitive to _certain kinds_ of bad PR, but not generally immune to it, nor
do they act generally immune to it. The people in charge of funding the
intelligence community may not come after them for getting caught putting
backdoors in things; indeed, this may even prove to the people controlling the
purse that they are doing their job. But they are certainly sensitive to
ensuring that the people controlling the purse do not come off looking bad,
and as a part of that, sensitive to not getting caught conducting open,
unambiguous acts of war against every nation in the world. We all "know" that
they do, everybody else "knows" that they do, and everybody also "knows" that
you shouldn't trust Chinese-manufactured electronics either for the same
reason, but it's still not _openly_ known. The distinction between open
secrets and openly-known facts may greatly confuse Spock and he may shake his
head about how illogical it is for everyone to know a thing and for everybody
to know everybody else knows but still act as if nobody knows, but is an
integral element of understanding human politics, in which appearances matter
a _lot_.

------
forapurpose
At least one of the recent exploits needs to be mitigated at the OS level (I
haven't looked at the details carefully, but I know Microsoft and Linux are
working on it). Is OpenBSD affected and if so, what are they doing to mitigate
it?

~~~
tedunangst
Affected and probably doing what everybody is doing for mitigation.

~~~
forapurpose
> probably doing what everybody is doing for mitigation

Is there any discussion? I thought OpenBSD development mostly took place on
public mailing lists ?

~~~
tedunangst
Some issues tend to attract a lot of lookie loos. The patch probably won't be
improved by a dozen replies about the incompetence of intel.

~~~
forapurpose
I understand their need and priority, but sometimes those discussions are a
great way to learn about the vulnerability - open development teaches others.

~~~
tedunangst
I don't disagree. I prefer more open development and try to encourage it, but
everyone has their own preferences for what to share.

------
andrewstuart
There's nothing prescient about saying that computer system X or Y can be
exploited in ways yet to be discovered.

The entire Internet is wide open, the holes just aren't known yet.

~~~
chris_wot
You miss the point. Theo wasn't just hand waving, he had identified specific
issues that he believed would eventually get exploited.

~~~
endorphone
" _he had identified specific issues that he believed would eventually get
exploited_ "

But those aren't the issues that were exploited. His post has absolutely
nothing to do with the current issues. It's just uninformed dogpiling (the
ignorance of the crowd).

All chips have errata. This post is not particularly informative or relevant
to anything.

~~~
mannykannot
This is not the ignorance of the crowd, it is the insight of one informed
individual. Dismissing as irrelevant all concerns except those that have
already been exploited would be closer to being "the [self-inflicted]
ignorance of the crowd" in these matters.

~~~
endorphone
Everyone fishing around for anyone saying anything about Intel chips ever, and
then trying to shoehorn it into a current narative is the ignorance of the
crowd. Every single chip has errata. In this case Theo is pointing at Intel's
_own_ list of defects in a revision/chip, which is profoundly unilluminating,
and is completely and absolutely irrelevant.

~~~
mannykannot
The issue is not that the errors existed, but the risk some of them presented.
Theo correctly identified an area where the risks were greater than generally
recognized.

~~~
endorphone
No, he didn't. Intel specifically states that the errata can allow
unauthorized access to protected memory. Theo then says "oooh, that sounds
scary!". Yes, of course it is, which is why it appears in the errata list.

~~~
mannykannot
You are misrepresenting Theo's message, which looks beyond individual errata,
saying that collectively they amount to a significant change in how the MMU
operates, and from that predicts a high likelihood of a then-yet undiscovered
flaw that would lead to problems much greater than were then being
acknowledged by Intel (and he said AMD was heading the same way.)

He was less prescient when he implied that it would take Intel a year or two
to get beyond this.

------
equalunique
From the email:

"(While here, I would like to say that AMD is becoming less helpful day by day
towards open source operating systems too, perhaps because their serious
errata lists are growing rapidly too)."

Glad to see that in 2018 AMD's reputation has generally improved from this.

------
linohh
Has HN begun to collect suggestions to intel how to handle the situation and
what to change regarding community interaction to reduce the impact of such
flaws? Instead of bashing our heads out, maybe it's time to offer them a hand
when they're down on the ground.

~~~
rdtsc
I am sure Intel will be fine. It is effectively a monopoly in the desktop and
server market and enjoyed their position and profits for years. They can
handle a bit of criticism from a bunch of nerds on HN.

Maybe loading data speculatively across a protection boundary was careless. It
seems besides the latest ARM CPUs no other vendor went that route. But not
owning up to it and issuing PR statements saying "This works as designed, not
a bug" is a bit hard to stomach.

But if it needs help drafting a better PR release, someone is welcome to point
them to HN's comments section.

~~~
wasx
>They can a handle a bit of criticism from a bunch of nerds on HN.

What a reductive and shortsighted evaluation of the situation.

Can they handle the loss of faith from big companies? Can they handle the loss
of faith from the entire tech community? Seems to me that AMD et al have now
got the perfect opportunity to erode intels market share and build up a large
market base amongst cloud providers etc (not to mention security minded users)
that require technology that is both resistant to meltdown and not
underperforming hardware.

It's silly to act like this is a storm in a teacup because the HN community is
up in arms over it. Monopolies fall, and the loss of trust and key clients
tends to precipitate that fall.

>But if it needs help drafting a better PR release, someone is welcome to
point them to HN's comments section.

Their PR was shocking, but on the order of things people are upset about over
this incident, this is literally at the bottom.

~~~
dannyw
AMD’s x86/x86-64 Cross licensing agreement terminates if they ever have more
than X (I think 30% or 50%) of the desktop and server market share, so I don’t
think so. The agreement purposefully gimps AMD as a minority player.

~~~
lloeki
> AMD’s x86/x86-64 Cross licensing agreement terminates if they ever have more
> than X (I think 30% or 50%)

Wow I'm surprised this is even legal because it sounds like an implemented
monopoly.

~~~
phs2501
Well if it means that AMD couldn't ship any x86 processors and Intel couldn't
ship x86-64 (i.e. AMD64) processors, that effectively means neither of them
could ship any modern x86 processors at all, so that's effectively mutually-
assured destruction. If that were in any danger of happening I'd bet dollars
to donuts it'd be renegotiated immediately since they both stand to lose
everything.

------
danjoc
Since C2Ds are still highly regarded by the FSF RYF crowd, I wonder how much
of this has been mitigated and how much of this is still an issue with
LibreBoot Trisquel laptops.

------
thisisit
Dupe?

[https://news.ycombinator.com/item?id=16071813](https://news.ycombinator.com/item?id=16071813)

~~~
alecco
Yes, but as the mods didn't catch it now the conversation is here.

------
dis-sys
this is a good reminder for everyone to stay away from from those engineering
sample Xeon processors on ebay/taobao.

------
paulhodge
If only he had come up with a catchy name and a logo, we would have listened.

~~~
buryat
Remember that naming is one of the hardest things in software engineering.

~~~
mrep
That and off by one errors ;)

~~~
endymi0n
Concurrency

You forgot 2) Cache invalidation and 3)

~~~
tracker1
The two most difficult things in software development.

    
    
        * naming things
        * cache invalidation
        * off by one errors

~~~
taneq
It's always worth having it stated in the canonical form. :)

~~~
evanmoran
The fifth hardest thing is figuring out the canonical form :)

