That "bug" or "flaw" sentence is very carefully worded. It's like:

    bool bug = true;
    bool flaw = true;
    bool uniqueToIntel = false;

    bool reportsAreTrue = (bug || flaw) && uniqueToIntel;

    // reportsAreTrue == false!

Yes it's designed in such a way that in a court of law they could claim they were announcing a bug, but most or many people reading it would come to the opposite conclusion. In other words it's deceptive.

> Hearing echos of Intel's early FDIV response along the lines of "the average computer user doesn't need perfectly accurate division"...

Has to be pointed out that they were correct. Public outrage forced them to change their tune, but their original summary was still on point. That said, it of course could majorly impact a select few.

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.

> do not have the potential to corrupt, modify or delete data.

I believe the point of this sentence was simply to distinguish malicious read access (possible) from any modifying access (impossible).

> Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect.

I believe the second half of the sentence is far more important, i. e. the attempt to broaden the news story to include other chip vendors. The scare-quotes around "bug" may suggest that Intel thinks they correctly implemented Tomasulo’s algorithm, and any flaw would not be theirs–which actually goes well with the second half of the sentence.

The part on performance is probably correct: Consumers might not notice any hit in performance. Gaming seems not to be impacted, and CPUs tend to be under-utilised anyway.

Overall, I think this statement is obviously damage control, but there really isn't anything wrong with the content from a consumer user of an Intel CPU. Basically: don't freak out, install patches, stay tuned.

The tone is actually refreshingly to-the-point. At least they are not taking us on a voyage to Qualityland.

Your typical system has a rather large number of pieces that rely on that protection against read access in order to keep an attacker from obtaining information that would allow malicious corruption, modification, and deletion of data. Intel are being weaselly.

> Reading from kernel memory is something of a flaw, no? Fair point about not being Intel specific though.

Well the concept is not, but the company who's processors run most of the worlds' databases was PoC'ed, so ....

Source please?

Is the source to this published anywhere?

Wondering the same thing, though presumably if one researcher were able to deduce how the exploit worked, more will soon.

I’m with you that this is corporate-speak panicked PR damage containment at its finest, but reading from kernel memory is only a flaw if you aren’t the kernel. ;)

Haha good point! That's what I meant of course :) edited for clarity.

While I agree with most of the analysis, I don’t see any issue with the “operating as designed”. I mean, it is operating as designed. Really, I think they screwed up here. Instead of saying it’s an accident or a mistake, they are saying it’s the result of a careful and deliberate design choice.

That is lawsuit fodder.