4 ms·

C++ programmers already have to worry about cache timing and sizes to make secure code (both data and code), have to worry about how integer overflow works (har

C++ programmers already have to worry about cache timing and sizes to make secure code (both data and code), have to worry about how integer overflow works (hardware dependent for signed), have to worry about data sizes, have to worry about integer shifting and how it varies across hardware, have to worry about relative speeds between multiplication, division, subtraction, and addition on your hardware to avoid timing attacks, and on and on. This is just another case where C/C++ makes it very hard to write secure code.

pjmlp 8y ago
True, however given this is an hardware exploit, it affects everyone. The biggest difference, is that because of the issues you listed, systems programmers are more understanding to the problem.
- ChrisLomont 8y ago
  >however given this is an hardware exploit Lots of what I listed are hardware exploits - cache timing leaks information, integer shifting and overflow behavior are hardware dependent, stack issues and exploits are hardware dependent, and to make secure C/C++ code on a specific target takes understanding of all these issues. This is only the tip of the iceberg. There's lots more, depending on platform. It's nearly impossible to make C/C++ code robust across platforms to all of these. Chip errata (Intel, AMD, etc.) list thousands more hardware bugs, many exploitable to some degree, and every platform has them. Hypervisor, secure instructions failing, lazy fp restore, Intel Management Engine, biased (or backdoored) RNG generation, and on and on all have security issues. Yes, Spectre is a pretty big one, but so we/are many of the others, and the only reason many people think Spectre is the only one that is important is because they are unaware of how prevalent hardware holes are. I suspect integer overflow alone has caused more severe security issues than these speculative execution attacks will get close to doing. But all these exploits exist because of hardware bugs or designed behavior that C/C++ programmers are unaware of or ignore.
  - kazinator 8y ago
    > integer shifting and overflow behavior are hardware dependent, stack issues and exploits are hardware dependent Those are hardware-dependent consequences of incorrect code either producing or failing to handle erroneous values. This is a different class of problem from that of correct code being turned into a security problem by the hardware.
    - ChrisLomont 8y ago
      > consequences of incorrect code either ... The point is it's trivial in the language to write incorrect code that behaves differently on different hardware. To write robust code you need to know how the underlying hardware behaves, how it can vary across platforms, and write code very carefully to ensure you write code that operates properly on the hardware. All these issues are consequences of the underlying hardware, including hardware errata and bugs. >This is a different class of problem from that of correct code being turned into a security problem by the hardware. Where would you put cache timing attacks then? It's "correct" code, the hardware performs as intended, yes the error is a result of the code + hardware interaction in a manner the programmer did not understand. All of these are related: programmer + language + hardware interact to make code that is exploitable. C/C++ in the mix makes this harder to do correctly.
  - pjmlp 8y ago
    I agree, however I don't see any of the possible replacements achieve a similar position in my lifetime. I have witness them both grow from also-ran attempts to system programming to the place they hold now. This is the kind of tech that only gets replaced with a generation change or via some nuke effect in architecture like quantum computing.
    - ChrisLomont 8y ago
      >however I don't see any of the possible replacements achieve a similar position in my lifetime Agreed. I've been doing C/C++ code for decades, and still do it, but routinely work on other languages. For many problems the best solution is still C/C++, but it makes security for such code significantly more trouble.

pjmlp 8y ago

True, however given this is an hardware exploit, it affects everyone. The biggest difference, is that because of the issues you listed, systems programmers are more understanding to the problem.

ChrisLomont 8y ago
>however given this is an hardware exploit Lots of what I listed are hardware exploits - cache timing leaks information, integer shifting and overflow behavior are hardware dependent, stack issues and exploits are hardware dependent, and to make secure C/C++ code on a specific target takes understanding of all these issues. This is only the tip of the iceberg. There's lots more, depending on platform. It's nearly impossible to make C/C++ code robust across platforms to all of these. Chip errata (Intel, AMD, etc.) list thousands more hardware bugs, many exploitable to some degree, and every platform has them. Hypervisor, secure instructions failing, lazy fp restore, Intel Management Engine, biased (or backdoored) RNG generation, and on and on all have security issues. Yes, Spectre is a pretty big one, but so we/are many of the others, and the only reason many people think Spectre is the only one that is important is because they are unaware of how prevalent hardware holes are. I suspect integer overflow alone has caused more severe security issues than these speculative execution attacks will get close to doing. But all these exploits exist because of hardware bugs or designed behavior that C/C++ programmers are unaware of or ignore.
- kazinator 8y ago
  > integer shifting and overflow behavior are hardware dependent, stack issues and exploits are hardware dependent Those are hardware-dependent consequences of incorrect code either producing or failing to handle erroneous values. This is a different class of problem from that of correct code being turned into a security problem by the hardware.
  - ChrisLomont 8y ago
    > consequences of incorrect code either ... The point is it's trivial in the language to write incorrect code that behaves differently on different hardware. To write robust code you need to know how the underlying hardware behaves, how it can vary across platforms, and write code very carefully to ensure you write code that operates properly on the hardware. All these issues are consequences of the underlying hardware, including hardware errata and bugs. >This is a different class of problem from that of correct code being turned into a security problem by the hardware. Where would you put cache timing attacks then? It's "correct" code, the hardware performs as intended, yes the error is a result of the code + hardware interaction in a manner the programmer did not understand. All of these are related: programmer + language + hardware interact to make code that is exploitable. C/C++ in the mix makes this harder to do correctly.
- pjmlp 8y ago
  I agree, however I don't see any of the possible replacements achieve a similar position in my lifetime. I have witness them both grow from also-ran attempts to system programming to the place they hold now. This is the kind of tech that only gets replaced with a generation change or via some nuke effect in architecture like quantum computing.
  - ChrisLomont 8y ago
    >however I don't see any of the possible replacements achieve a similar position in my lifetime Agreed. I've been doing C/C++ code for decades, and still do it, but routinely work on other languages. For many problems the best solution is still C/C++, but it makes security for such code significantly more trouble.