Comment by cperciva
2 days ago
That code is not guaranteed to work. Declaring memset_v as volatile means that the variable has to be read, but does not imply that the function must be called; the compiler is free to compile the function call as "tmp = memset_v; if (tmp != memset) tmp(...)" relying on its knowledge that in the likely case of equality the call can be optimized away.
Whilst the C standard doesn't guarantee it, both LLVM and GCC _do_. They have implementation-defined that it will work, so are not free to optimise it away.
[0] https://llvm.org/docs/LangRef.html#llvm-memset-intrinsics
[1] https://gitweb.git.savannah.gnu.org/gitweb/?p=gnulib.git;a=b...
Relying on implementation behavior is the perfect way to introduce a hidden in plain site vulnerability.
Most of C++ programs written before P0593R6 depended on implementation behaviour, and were graciously allowed to not be undefined behaviour just 5 years ago. C++ as a language standard is mostly irrelevant, what one should care about is what the compiler authors consider valid code.
Using pragmas, attributes and optimisation guarantees is the point of implementation-defined behaviour in the first place.
The Linux kernel extensively uses gcc extensions. That doesn't inherently make it insecure.
You have to rely on implementation for anything to do with what happens to memory after it is freed, or really almost anything to do with actual bytes in RAM.
Yeah the C committee is wrong here
I don't see why?
The C committee gave you memset_explicit. But note that there is still no guarantee that information can not leak. This is generally a very hard problem as information can leak in many different ways as it may have been copied by the compiler. Fully memory safe languages (so "Safe Rust" but not necessarily real-word Rust) would offer a bit more protection by default, but then there are still side-channel issues.
18 replies →