4 ms·

I could be wrong, but I take the "bug/flaw" language to mean this: the processor is doing exactly what it was designed to do (unlike the Pentium FDIV bug, for e

I could be wrong, but I take the "bug/flaw" language to mean this: the processor is doing exactly what it was designed to do (unlike the Pentium FDIV bug, for example). A new class of exploit was recently discovered, and these CPUs are vulnerable to this new exploit. But there was no bug in how these CPUs were implemented, and the only design flaw is that they failed to withstand a new class of exploit that was not known at the time they were designed. (I don't have any information that could confirm/deny this, it's just how I interpret their verbiage). I don't get the sense that they are trying to deceptively contradict only part of the previous statement.

foxylad 9y ago
My limited understanding is that the vulnerability is due to kernel memory protections not being applied during speculative execution, when the CPU is trying to second guess what the next instructions might be. Unless you are in PR, any reasonable person would expect a CPU touted as having kernel memory protection to protect it under all circumstances. I'm sure that the people who wrote the speculative execution code would have included that protection had they thought of it, and all developers would class it's omission as a bug. So yes, this is yet another example of awful PR, trying to cover up a serious mistake with careful language that makes it seem not their fault. My policy when I make a mistake is immediate disclosure, along with two commitments: to put the mistake right, and to amend processes to prevent similar mistakes in the future. It isn't clear how Intel can put this right, but perhaps a good discount on replacement parts might help. And they can certainly implement processes to catch such omissions in the future. So this press release (particularly combined with reports of execs selling stock) are appalling. Intel have badly damaged their brand, and I'll never buy another Intel processor again.
redcalx 9y ago
It's kind of semantics though isn't it? If I write a piece of software that follows the spec and fulfils the customer's need, but then someone tries to do something with it that we hadn't thought of and that results in a security hole... around here we call that a bug, a flaw, something we missed. Maybe it's reasonable to have not spotted the bug, but that wouldn't make it not a bug/flaw.
- haberman 9y ago
  Yeah I agree there is a line there somewhere. If someone sells you a safe and it can be opened with a ballpoint pen, that seems like a flaw. If someone sells you a safe and it can be opened with a military grade laser, that's sort of expected. If someone sells you a safe and it can be opened with a cheap consumer gadget, but that gadget is complex and was unforeseen when the safe was designed, what do you say about that? The last one seems like the closest analogy. Another example: would you say that MD5 is buggy/flawed? I guess overall I think this is fair to call a "flaw" but not a "bug."
  - 13of40 9y ago
    I was about to say something like, "Well, in a broad sense they introduced protection features to x86 to prevent modification or disclosure of memory contents across process boundaries...and that's broken, therefore bug." However, looking at the reference manual for the 80386 [1], and a modern version of their x64 manual [2], they don't actually say it's for security: Original: "6.1 Why Protection? The purpose of the protection features of the 80386 is to help detect and identify bugs. The 80386 supports sophisticated applications that may consist of hundreds or thousands of program modules..." Modern: "The IA-32 architecture’s protection mechanism recognizes four privilege levels, numbered from 0 to 3, where a greater number mean less privilege. The reason to use privilege levels is to improve the reliability of operating systems." So it's more like someone sells you a box with a lock on the front that looks a lot like a safe and all of the individual hinges and pins and whatnot are guaranteed to some degree, but they never actually say it's OK to lock your stuff inside. [1]https://css.csail.mit.edu/6.858/2013/readings/i386.pdf https://css.csail.mit.edu/6.858/2013/readings/i386.pdf [2]https://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-manual-325462.html https://www.intel.com/content/www/us/en/architecture-and-tec...
  - redcalx 9y ago
    > I guess overall I think this is fair to call a "flaw" but not a "bug." Yes I agree, it's not a bug in the sense of a silly mistake that slipped through development and testing. It's a flaw / attack-vector that no-one thought of... until now.
x0x0 9y ago
This feels pretty deceptive when the most relevant competitor, amd, is not susceptible...
- deleted 9y ago
  [deleted]
arghwhat 9y ago
I do not think the processor was designed to improperly unwind from speculative execution, such that the state after failed speculation is not identical to the state prior to speculation. But yeah, this an old discussion, and a deep rabbit hole. There's many layers to consider bugs at. Implementation can differ from developer intention, developer intention can differ from group agreement, group agreement can differ from design document, design document can differ from product development intention, and product development intention can differ from communicated functionality. I'm betting this would be implementation differing from developer intention, although I would consider (almost) all of the above to be bugs.

foxylad 9y ago

My limited understanding is that the vulnerability is due to kernel memory protections not being applied during speculative execution, when the CPU is trying to second guess what the next instructions might be. Unless you are in PR, any reasonable person would expect a CPU touted as having kernel memory protection to protect it under all circumstances. I'm sure that the people who wrote the speculative execution code would have included that protection had they thought of it, and all developers would class it's omission as a bug. So yes, this is yet another example of awful PR, trying to cover up a serious mistake with careful language that makes it seem not their fault. My policy when I make a mistake is immediate disclosure, along with two commitments: to put the mistake right, and to amend processes to prevent similar mistakes in the future. It isn't clear how Intel can put this right, but perhaps a good discount on replacement parts might help. And they can certainly implement processes to catch such omissions in the future. So this press release (particularly combined with reports of execs selling stock) are appalling. Intel have badly damaged their brand, and I'll never buy another Intel processor again.

redcalx 9y ago

It's kind of semantics though isn't it? If I write a piece of software that follows the spec and fulfils the customer's need, but then someone tries to do something with it that we hadn't thought of and that results in a security hole... around here we call that a bug, a flaw, something we missed. Maybe it's reasonable to have not spotted the bug, but that wouldn't make it not a bug/flaw.

haberman 9y ago
Yeah I agree there is a line there somewhere. If someone sells you a safe and it can be opened with a ballpoint pen, that seems like a flaw. If someone sells you a safe and it can be opened with a military grade laser, that's sort of expected. If someone sells you a safe and it can be opened with a cheap consumer gadget, but that gadget is complex and was unforeseen when the safe was designed, what do you say about that? The last one seems like the closest analogy. Another example: would you say that MD5 is buggy/flawed? I guess overall I think this is fair to call a "flaw" but not a "bug."
- 13of40 9y ago
  I was about to say something like, "Well, in a broad sense they introduced protection features to x86 to prevent modification or disclosure of memory contents across process boundaries...and that's broken, therefore bug." However, looking at the reference manual for the 80386 [1], and a modern version of their x64 manual [2], they don't actually say it's for security: Original: "6.1 Why Protection? The purpose of the protection features of the 80386 is to help detect and identify bugs. The 80386 supports sophisticated applications that may consist of hundreds or thousands of program modules..." Modern: "The IA-32 architecture’s protection mechanism recognizes four privilege levels, numbered from 0 to 3, where a greater number mean less privilege. The reason to use privilege levels is to improve the reliability of operating systems." So it's more like someone sells you a box with a lock on the front that looks a lot like a safe and all of the individual hinges and pins and whatnot are guaranteed to some degree, but they never actually say it's OK to lock your stuff inside. [1]https://css.csail.mit.edu/6.858/2013/readings/i386.pdf https://css.csail.mit.edu/6.858/2013/readings/i386.pdf [2]https://www.intel.com/content/www/us/en/architecture-and-technology/64-ia-32-architectures-software-developer-manual-325462.html https://www.intel.com/content/www/us/en/architecture-and-tec...
- redcalx 9y ago
  > I guess overall I think this is fair to call a "flaw" but not a "bug." Yes I agree, it's not a bug in the sense of a silly mistake that slipped through development and testing. It's a flaw / attack-vector that no-one thought of... until now.

x0x0 9y ago

This feels pretty deceptive when the most relevant competitor, amd, is not susceptible...

deleted 9y ago
[deleted]

arghwhat 9y ago

I do not think the processor was designed to improperly unwind from speculative execution, such that the state after failed speculation is not identical to the state prior to speculation. But yeah, this an old discussion, and a deep rabbit hole. There's many layers to consider bugs at. Implementation can differ from developer intention, developer intention can differ from group agreement, group agreement can differ from design document, design document can differ from product development intention, and product development intention can differ from communicated functionality. I'm betting this would be implementation differing from developer intention, although I would consider (almost) all of the above to be bugs.