Live data from Hacker News

“Intel Core 2 bugs will assuredly be exploitable from userland code” (2007)

marc.info

111–120 of 130 posts

Re: “Intel Core 2 bugs will assuredly be exploitable from userland code” (2007)

#111
post #80
post #4

Earlier quoted context omitted.

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…

> It is effectively a monopoly in the desktop and server market But it couldn't be better timing for ARM. AMD isn't the competition (Though this helps them a little bit) it really is all about ARM and it is going to get a lot more attension with this. Windows runs on ARM now. CPUs can't get much smaller. It is now how many cores and thermal control you can place on a waffer. ARM has the advantage in both of those. We…

Which ARM? Have you ever even looked at ARM implementation errata? At the errata for people doing semi-custom ARM like Cavium? Do you think that those companies are as diligent as Intel?

I can’t say anything about ARM vendors, but I’m pretty familiar with MIPS and PowerPC errata from chips in the mid-2000s and they generally made Intel look 10x as professional and careful.

Re: “Intel Core 2 bugs will assuredly be exploitable from userland code” (2007)

#112
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.

Re: “Intel Core 2 bugs will assuredly be exploitable from userland code” (2007)

#113

This image is linked in the e-mail thread, with (some of?) the errata: https://www.geek.com/images/geeknews/2006Jan/core_duo_errata... I'm just surprised that the URL is still valid after 12 years!

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.

The Mill computing people seem to have figured out quite a lot of elegant yet fast security solutions[0][1].

One simple example is the zero-bit. I don't have time to look up the exact details now, but IIRC, it's a simple hardware bit-flag that is part of the metadata of any value that can be read. If set, reading out that value returns zero. If not, it returns the actual value.

Data defaults to having the zero-bit set, and the only way to unset a zero bit is writing new data into whatever you want to read from. The exact mechanism is probably a bit different, but that's how I remember it.

Regardless of what the precise implementation is, the point is that by adding some smart hardware-based metadata like this in the form of bit-wise flags, you don't have to worry about having to manually wipe the data in memory once you are done with it (and have the speed benefits of not having to do so as well), yet still get all the safety benefits of never having to worry about buffer overflows and whatnot again.

[0] https://millcomputing.com/

[1] https://millcomputing.com/docs/security/

Re: “Intel Core 2 bugs will assuredly be exploitable from userland code” (2007)

#114
post #89
post #78

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?

Does the NSA use Intel chips? If so, it would seem unlikely that they made their own compute infrastructure insecure. Their mission isn't to make everything less secure, it's to make the other team's stuff less secure (where "other team" includes the citizens of the US apparently). Furthermore, given the number of bugs in just about every piece of software (including kernels), I don't think these bugs are even an ano…

> (where "other team" includes the citizens of the US apparently).

Not really. It's not like stuff like that Dual_EC_DRBG were export only, and IIRC, they did hold on to zero days that would affect American systems, leaving those system vulnerable, while they exploited them elsewhere.

Re: “Intel Core 2 bugs will assuredly be exploitable from userland code” (2007)

#115

Earlier quoted context omitted.

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.

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.

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.

Re: “Intel Core 2 bugs will assuredly be exploitable from userland code” (2007)

#116
post #2

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.

(playing devil's advocate here, to be clear) What leads you to believe that Intel has any reason to think that there's an issue that needs changed? Or that "the community" knows anything about their business processes or what Intel should do? They have their highly-paid C-levels to figure that out. From their perspective, there's no problem. Nothing needs fixin'. You'll keep buying their CPUs, anyways -- you don't re…

You are right in your assessment. This is how it will go down. The vendors simply need Intel. There is now way they will make enemies with them. The problems are simply passed on to the customers who have no other option but accept the reduced performance.

Re: “Intel Core 2 bugs will assuredly be exploitable from userland code” (2007)

#117

Earlier quoted context omitted.

> Opensource software is, by default, non-malicious. So is closed source software. You seem to be deeply confused about the scenarios people are worried about. The main ones are 1. untrusted users being hosted 2. javascript off the web. All the open source in the world doesn't help in either scenario. You're focused on someone deliberately running a malicious program. But if they do that, these exploits aren't even n…

> > Opensource software is, by default, non-malicious. > So is closed source software. Sorry what? 99.999999% of all the malware that exists and has existed today, is/was closed source. Compare that to the other 0.0000001% that got once or twice into opensource and was removed as soon as it got detected. > The main ones are 1. untrusted users being hosted 2. javascript off the web. I've never talked about (1), of cou…

> Sorry what? 99.999999% of all the malware that exists and has existed today, is/was closed source. Compare that to the other 0.0000001% that got once or twice into opensource and was removed as soon as it got detected.

There is plenty of open-source malware, and most closed source software is not malware.

You seem to be conflating "is in a trusted open source distribution, listed as non-malware" with mere "open source". Code that is openly malicious, or has never been peer-reviewed, is still perfectly capable of being open source.

> I've never talked about (1), of course my comment was not targetted to server owners but by normal workstation owners that only have one user.

That's cool but the workstation use case is not why people are freaking out. The workstation is the place where you don't even need this bug to take over and ruin everything, because it's all under one account anyway.

Saying it's a "way to not be affected by these bugs" is pretty myopic.

Re: “Intel Core 2 bugs will assuredly be exploitable from userland code” (2007)

#118

Earlier quoted context omitted.

Affected and probably doing what everybody is doing for mitigation.

> probably doing what everybody is doing for mitigation Is there any discussion? I thought OpenBSD development mostly took place on public mailing lists ?

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.

Re: “Intel Core 2 bugs will assuredly be exploitable from userland code” (2007)

#119

Earlier quoted context omitted.

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.

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.

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.

Re: “Intel Core 2 bugs will assuredly be exploitable from userland code” (2007)

#120
post #103

Earlier quoted context omitted.

Concurrency You forgot 2) Cache invalidation and 3)

I’d risk saying we’re all intensely aware how hard Cache invalidation is, right now

well, we can only speculate...
Post reply on HN