4 ms·

> Intel believes these exploits do not have the potential to corrupt, modify or delete data. Reading from kernel memory [edit: from unprivileged apps] is still

> Intel believes these exploits do not have the potential to corrupt, modify or delete data. Reading from kernel memory [edit: from unprivileged apps] is still a severe security issue though, right? This sounds like they're trying to downplay that hard, especially with the "operating as designed" phrase. > Recent reports that these exploits are caused by a “bug” or a “flaw” [Unprivileged] reading from kernel memory is something of a flaw, no? Fair point about not being Intel specific though. > any performance impacts are workload-dependent, and, for the average computer user, should not be significant Hearing echos of Intel's early FDIV response along the lines of "the average computer user doesn't need perfectly accurate division"... > However, Intel is making this statement today because of the current inaccurate media reports. This and similar sentences has a strange tone to me, it sounds almost grumpy. I guess it got rushed out.

qubex 9y ago
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. ;)
- AshleysBrain 9y ago
  Haha good point! That's what I meant of course :) edited for clarity.
aneutron 9y ago
> 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 ....
- ghrifter 9y ago
  Source please?
  - blattimwind 9y ago
    https://twitter.com/brainsmoke/status/948561799875502080 https://twitter.com/brainsmoke/status/948561799875502080
    - wyldfire 9y ago
      Is the source to this published anywhere?
      - peatmoss 9y ago
        Wondering the same thing, though presumably if one researcher were able to deduce how the exploit worked, more will soon.
    - deleted 9y ago
      [deleted]
matt4077 9y ago
> 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.
- makomk 9y ago
  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.
nebulous1 9y ago
> 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.
- AshleysBrain 9y ago
  Quite possibly, but it still a bad omen for Intel. This sounds a lot worse than a slightly off division.
  - mehrdadn 9y ago
    > 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.
    - nebulous1 9y ago
      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.
      - mehrdadn 9y ago
        > 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.
Nition 9y ago
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!
- redcalx 9y ago
  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.
JurgenKlein 9y ago
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.

qubex 9y ago

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. ;)

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

aneutron 9y ago

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

ghrifter 9y ago
Source please?
- blattimwind 9y ago
  https://twitter.com/brainsmoke/status/948561799875502080 https://twitter.com/brainsmoke/status/948561799875502080
  - wyldfire 9y ago
    Is the source to this published anywhere?
    - peatmoss 9y ago
      Wondering the same thing, though presumably if one researcher were able to deduce how the exploit worked, more will soon.
  - deleted 9y ago
    [deleted]

matt4077 9y ago

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

makomk 9y ago
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.

nebulous1 9y ago

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

AshleysBrain 9y ago
Quite possibly, but it still a bad omen for Intel. This sounds a lot worse than a slightly off division.
- mehrdadn 9y ago
  > 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.
  - nebulous1 9y ago
    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.
    - mehrdadn 9y ago
      > 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.

Nition 9y ago

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!

redcalx 9y ago
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.

JurgenKlein 9y ago

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.