5 ms·

C and C++ are systems-programming languages which get used for kernels/drivers/etc so these guidelines absolutely do fall into the responsibility of C/C++ progr

C and C++ are systems-programming languages which get used for kernels/drivers/etc so these guidelines absolutely do fall into the responsibility of C/C++ programmer. In the embedded world we have a saying that software always fixes hardware. This is generally true as many hardware issues result in software workarounds.

kazinator 8y ago
A problem from spectre could show up literally anywhere, in any package in an embedded distro, kernel or userspace. Good luck. This is not like a "insert a delay between these two accesses to the PHY and the issue goes away" kind of thing. Something in the compiler would be appropriate here, rather than the wild goose chase of tracking this down in countless lines of code and guessing at solutions. How do you even test for this, in all its possible incarnations and scenarios. Never fix something if you don't have a test plan.
- TickleSteve 8y ago
  You missed the point. The post I replied to implied that C/C++ people shouldn't have to worry about this and that they should not take account of it. My point was that C/C++ is used in privileged locations (i.e. kernel & drivers) and (although spectre itself is a user-mode exploit) as such it is perfectly within its domain to be concerned about such things. Since it is impractical for hardware to be changed, the only pragmatic solution is to either a) live with it b) have software do its best to reduce the likelihood of you being bitten. Practically, that means s/w mods. Test-wise; I can imagine a new class of static-analysis tools that may be able indicate worrisome areas for known hardware exploits. None that I've heard of so far tackle these type of issues.
- aseipp 8y ago
  The Microsoft compiler can do some level of automated mitigation. But fundamentally it is a static analysis that cannot cover all cases. You do need help from the compiler to de-speculate loads appropriately (GCC and Clang will feature these intrinsics). But only the programmer knows the true security model the program exists under. Spectre V1, quite fundamentally, means that branch conditions are not necessarily a legitimate security boundary anymore. That's really all there is to it. Either you have to accept this and fix your code, or not fix it and say the threat exists outside your model. Even leveraging newer hardware features (e.g. perhaps segregating cache regions like Intel CAT) will likely require software integration if they wish to retain speculative capabilities, and this seems likely. We also cannot test for all possible side channel attacks in highly error-prone and detailed cryptographic algorithms, and new ones are found. But we manage through many mechanisms to try and mitigate the things we know about (through various static and dynamic methods, and enhancing our security and programming models). These all require coordination on the programmers behalf, still. It's not necessarily our fault this is all happening. It's unfortunately our responsibility to fix and mitigate it. And, unfortunately -- it's also another thing on top of the 200 other things a C/C++ programmer/systems programmer writing security-relevant code will have to understand.
  - pjmlp 8y ago
    The problem is that this affects everyone, even when using safer languages.
travmatt 8y ago
So we can give some responsibility to the low level people, which is all well and good - but then what? We’ve already started seeing some of these types of attacks against JavaScript engines too, so it’s a good guess that other languages are similarly vulnerable, as this isn’t a software bug.
OnlyRepliesToBS 8y ago
Heh.

kazinator 8y ago

A problem from spectre could show up literally anywhere, in any package in an embedded distro, kernel or userspace. Good luck. This is not like a "insert a delay between these two accesses to the PHY and the issue goes away" kind of thing. Something in the compiler would be appropriate here, rather than the wild goose chase of tracking this down in countless lines of code and guessing at solutions. How do you even test for this, in all its possible incarnations and scenarios. Never fix something if you don't have a test plan.

TickleSteve 8y ago
You missed the point. The post I replied to implied that C/C++ people shouldn't have to worry about this and that they should not take account of it. My point was that C/C++ is used in privileged locations (i.e. kernel & drivers) and (although spectre itself is a user-mode exploit) as such it is perfectly within its domain to be concerned about such things. Since it is impractical for hardware to be changed, the only pragmatic solution is to either a) live with it b) have software do its best to reduce the likelihood of you being bitten. Practically, that means s/w mods. Test-wise; I can imagine a new class of static-analysis tools that may be able indicate worrisome areas for known hardware exploits. None that I've heard of so far tackle these type of issues.
aseipp 8y ago
The Microsoft compiler can do some level of automated mitigation. But fundamentally it is a static analysis that cannot cover all cases. You do need help from the compiler to de-speculate loads appropriately (GCC and Clang will feature these intrinsics). But only the programmer knows the true security model the program exists under. Spectre V1, quite fundamentally, means that branch conditions are not necessarily a legitimate security boundary anymore. That's really all there is to it. Either you have to accept this and fix your code, or not fix it and say the threat exists outside your model. Even leveraging newer hardware features (e.g. perhaps segregating cache regions like Intel CAT) will likely require software integration if they wish to retain speculative capabilities, and this seems likely. We also cannot test for all possible side channel attacks in highly error-prone and detailed cryptographic algorithms, and new ones are found. But we manage through many mechanisms to try and mitigate the things we know about (through various static and dynamic methods, and enhancing our security and programming models). These all require coordination on the programmers behalf, still. It's not necessarily our fault this is all happening. It's unfortunately our responsibility to fix and mitigate it. And, unfortunately -- it's also another thing on top of the 200 other things a C/C++ programmer/systems programmer writing security-relevant code will have to understand.
- pjmlp 8y ago
  The problem is that this affects everyone, even when using safer languages.

travmatt 8y ago

So we can give some responsibility to the low level people, which is all well and good - but then what? We’ve already started seeing some of these types of attacks against JavaScript engines too, so it’s a good guess that other languages are similarly vulnerable, as this isn’t a software bug.

OnlyRepliesToBS 8y ago

Heh.