3 ms·

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

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.
- zde 9y ago
  Reminds me of dieselgate. "Our product is ok unless operated out of spec" didn't work, iirc.
losteric 9y ago
I think that analogy paints a pretty clear picture, this is a flaw because it's undesirable behavior in unexpected circumstances. A bug is unexpected behavior in expected use-cases.
SAI_Peregrinus 9y ago
I'd agree. The implementation conforms to the specification, so it's not a bug. The specification is flawed.

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.

zde 9y ago
Reminds me of dieselgate. "Our product is ok unless operated out of spec" didn't work, iirc.

losteric 9y ago

I think that analogy paints a pretty clear picture, this is a flaw because it's undesirable behavior in unexpected circumstances. A bug is unexpected behavior in expected use-cases.

SAI_Peregrinus 9y ago

I'd agree. The implementation conforms to the specification, so it's not a bug. The specification is flawed.