
C++ Developer Guidance for Speculative Execution Side Channels - pjmlp
https://docs.microsoft.com/en-us/cpp/security/developer-guidance-speculative-execution
======
kazinator
Absolutely not the job of the C or C++ programmer to diddle perfectly correct
code to compensate for this hardware screwup. I mean, seriously?

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

~~~
aseipp
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
The problem is that this affects everyone, even when using safer languages.

