4 ms·

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 somet

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.
  - 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.
mehrdadn 9y ago
> It's kind of semantics though isn't it? I never understood how this sentence became a defense. Yes, yes it is. It is semantics. Everything is semantics. The difference between getting fired and getting laid off is semantics, and everybody cares about it and recognizes it. The difference between "I'll pick you up at 5pm" and "I promise I will pick you up at 5pm even if my car breaks down and the train gets derailed" is semantics. Calling something "semantics" isn't a defense to your argument; it's often more like a concession. (And the difference between a defense and a concession is, as I'm sure you realize, also semantics...)
- tedivm 9y ago
  Since we're being semantic about things, lets be clear that when someone says it's all "semantics" they mean that the person is engaging in a semantic dispute. This is a type of argument that has a specific meaning- > A semantic dispute is a disagreement that arises if the parties involved disagree about the definition of a word or phrase, not because they disagree on material facts, but rather because they disagree on the definitions of a word (or several words) essential to formulating the claim at issue. When someone is "arguing semantics" they are often trying to obfuscate the original issue being discussed. In this specific case the argument is being made that Intel is trying to use a different meaning for the word "bug" that favors them. redcalx is then stating the general definition of "bug" in an attempt to point out how limiting and nonstandard their definition is.
  - mehrdadn 9y ago
    > When someone is "arguing semantics" they are often trying to obfuscate the original issue being discussed. Well (and the irony is not lost on me here), this wasn't part of the definition of a semantic dispute that you just presumably quoted... it was just something you tacked onto it afterward. And the entire problem is that to you a semantic dispute might imply the original issue is being obfuscated, whereas to the other person it might imply you are trying to stretch your own ideas to where they wouldn't apply. Read your own definition: you said a semantic dispute is when they disagree on essential words. Not fluff words. People don't need to disagree on facts to have legitimate disagreements about about their interpretations and consequences. We all agree the CPU behaved in an undesirable way. There is no debate there, but that fact was insufficient to get us anywhere. What we disagree on is whether that is a "bug", which matters to all sides because it has consequences as who is to resolve the issue and how. > In this specific case the argument is being made that Intel is trying to use a different meaning for the word "bug" that favors them. [Edit: I misread part of the comment here; see below.] If it's "unintended behavior", then, sure, the CPU has "bugs", but that's a pretty useless definition that gets you nowhere (especially legally). If it's "does not perform as specified", which at least to me is a more logical choice, then I'm afraid I have not seen a shred of evidence that they ever claimed memory contents are immune from CPU timing/cache/etc. effects.

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

mehrdadn 9y ago

> It's kind of semantics though isn't it? I never understood how this sentence became a defense. Yes, yes it is. It is semantics. Everything is semantics. The difference between getting fired and getting laid off is semantics, and everybody cares about it and recognizes it. The difference between "I'll pick you up at 5pm" and "I promise I will pick you up at 5pm even if my car breaks down and the train gets derailed" is semantics. Calling something "semantics" isn't a defense to your argument; it's often more like a concession. (And the difference between a defense and a concession is, as I'm sure you realize, also semantics...)

tedivm 9y ago
Since we're being semantic about things, lets be clear that when someone says it's all "semantics" they mean that the person is engaging in a semantic dispute. This is a type of argument that has a specific meaning- > A semantic dispute is a disagreement that arises if the parties involved disagree about the definition of a word or phrase, not because they disagree on material facts, but rather because they disagree on the definitions of a word (or several words) essential to formulating the claim at issue. When someone is "arguing semantics" they are often trying to obfuscate the original issue being discussed. In this specific case the argument is being made that Intel is trying to use a different meaning for the word "bug" that favors them. redcalx is then stating the general definition of "bug" in an attempt to point out how limiting and nonstandard their definition is.
- mehrdadn 9y ago
  > When someone is "arguing semantics" they are often trying to obfuscate the original issue being discussed. Well (and the irony is not lost on me here), this wasn't part of the definition of a semantic dispute that you just presumably quoted... it was just something you tacked onto it afterward. And the entire problem is that to you a semantic dispute might imply the original issue is being obfuscated, whereas to the other person it might imply you are trying to stretch your own ideas to where they wouldn't apply. Read your own definition: you said a semantic dispute is when they disagree on essential words. Not fluff words. People don't need to disagree on facts to have legitimate disagreements about about their interpretations and consequences. We all agree the CPU behaved in an undesirable way. There is no debate there, but that fact was insufficient to get us anywhere. What we disagree on is whether that is a "bug", which matters to all sides because it has consequences as who is to resolve the issue and how. > In this specific case the argument is being made that Intel is trying to use a different meaning for the word "bug" that favors them. [Edit: I misread part of the comment here; see below.] If it's "unintended behavior", then, sure, the CPU has "bugs", but that's a pretty useless definition that gets you nowhere (especially legally). If it's "does not perform as specified", which at least to me is a more logical choice, then I'm afraid I have not seen a shred of evidence that they ever claimed memory contents are immune from CPU timing/cache/etc. effects.