Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: