Hacker News Reader

Comment by AshleysBrain | Hacker News Reader

Quite possibly, but it still a bad omen for Intel. This sounds a lot worse than a slightly off division.

> Quite possibly, but it still a bad omen for Intel. This sounds a lot worse than a slightly off division.

It actually doesn't even sound comparable to me, let alone worse. A wrong division is an operation producing incorrect results contrary to the specifications, plain and simple. What we have is a CPU producing correct results, and simply refusing to provide a guarantee about caching or timing. In particular it makes no guarantee that caching or timing behavior is data-independent. So it's not exactly hard to argue that it is not malfunctioning at all, and that people were (rightly or wrongly) simply assuming more about the CPUs than they were guaranteed.

Mind you, I don't like the bug any more than you do, and I would obviously like this to get fixed too. But it seems pretty hard to compare this with the division bug.

Wait, what? If this allows code running in ring 3 to read from ring 0 protected memory then it's not an issue due to a lack timing guarantees, even if its internally caused by a timing issue. Now the speculation about the underlying problem could be way off, but if not it would be hard to see how Intel would argue that it isn't a bug.

> If this allows code running in ring 3 to read from ring 0 protected memory then it's not an issue due to a lack timing guarantees, even if its internally caused by a timing issue.

I was never saying "the lack of timing guarantees was [or wasn't, for that matter] an issue" in itself. I said "given the lack of timing guarantees, this behavior is perfectly correct and compliant with their specs [as far as I know]". You're muddying the waters here as to what you mean by "the issue". People often (even rightly) have "issues" with things that go beyond, you know, actual issues with those things. They do this because they extrapolate and their assumptions turn out to be incorrect, and they get annoyed (again, in this case, rightly so). And that's what I'm saying here: yes, this is a genuine issue for people, but no, far as I'm aware, all Intel has guaranteed is a certain behavior for each instruction, and as far as I'm aware, no specification has been violated. Hence this is a very different situation from one where they are violating their own specs and producing incorrect output.

If you can point to one guarantee in their specs that they violate (this may not be hard -- I have barely read their specs, given that they are thousands of pages), then I agree, this is potentially like the FDIV bug, and I would more than love to be aware of it. Until then, I see the two as quite different.

So it's your contention that Intel never guaranteed that ring 0 protected memory couldn't be read by code running in ring 3, thereby rendering the concept of memory read protection useless by design?

> So it's your contention that Intel never guaranteed that ring 0 protected memory couldn't be read by code running in ring 3.

Assuming by "read" you mean "inferred", yes, I'm not aware of any such guarantee, but again, I of course have't read everything they have published, so by all means prove me wrong.

Intel® 64 and IA-32 Architectures Software Developer’s Manual, Volume 3A 4-30

  4.6.1 Determination of Access Rights

  For user-mode accesses:
  — Data reads.
  Access rights depend on the mode of the linear address:
    ...
    • Data may not be read from any supervisor-mode address.

And this contradicts the above how, exactly?

> And this contradicts the above how, exactly?

Documentation: Data may not be read from any supervisor-mode address.

Published vulnerability: Data may be read from any supervisor-mode address.

Reply on news.ycombinator.com