4 ms·

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

by cperciva 10mo 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.

shakna 10mo ago
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 https://llvm.org/docs/LangRef.html#llvm-memset-intrinsics [1] https://gitweb.git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=lib/memset_explicit.c;hb=refs/heads/stable-202301 https://gitweb.git.savannah.gnu.org/gitweb/?p=gnulib.git;a=b...
- raverbashing 10mo ago
  Yeah the C committee is wrong here
  - uecker 10mo ago
    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.
    - raverbashing 10mo ago
      Because, for the 1384th time, they're pretending they can ignore what the programmer explicitly told them to do Creating memset_explicit won't fix existing code. "Oh but what if maybe" is just cope. If I do memset then free then that's what I want to do And the way things go I won't be surprised if they break memset_explicit for some other BS reason and then make you use memset_explicit_you_really_mean_it_this_time
      - uecker 10mo ago
        Your problem is not the C committee but your lack of understanding how optimizing compilers work. WG14 could, of course, specify that a compiler has do exactly what you tell it to do. And in fact, every compiler supports this already: Im most cases even by default! Just do not turn on optimization. But this is not what most people want. Once you accept that optimizing compilers do, well, optimizations, the question is what should be allowed and what not. Both inlining "memset" and eliminating dead stores are both simply optimizations which people generally want. If you want a store not to be eliminated by a compiler, you can make it volatile. The C standard says this can not be deleted by optimizations. The criticism with this was that later undefined behavior could "undo" this by "travelling in time". We made it clear in ISO C23 that this not allowed (and I believe it never was) - against protests from some compiler folks. Compilers still do not fully conform to this, which shows the limited power WG14 has to change reality.
        raverbashing 10mo ago
        Nope it is the C committee > Once you accept that optimizing compilers do, well, optimizations Why in tarnation it is optimizing out a write to a pointer out before a function that takes said pointer? Imagine it is any other function besides free, see how ridiculous that sounds?
        shakna 10mo ago
        Tree shaking is pretty standard. Optimising out the write sounds fine to me - with the exception of a volatile pointer. That, there, is a mistake.
        raverbashing 10mo ago
        Optimizing out a write to (example) an array on the stack seems fine to me. Optimizing out a function call to a heap pointer (especially memset) seems wrong to me. You called the function, it should call the function! But it's again the C language saving time not wearing a seatbelt or checking the tire pressure for saving 10s on a 2h trip
- sitkack 10mo ago
  Relying on implementation behavior is the perfect way to introduce a hidden in plain site vulnerability.
  - shakna 10mo ago
    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.
  - CJefferson 10mo ago
    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.
  - 112233 10mo ago
    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.

shakna 10mo ago

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 https://llvm.org/docs/LangRef.html#llvm-memset-intrinsics [1] https://gitweb.git.savannah.gnu.org/gitweb/?p=gnulib.git;a=blob_plain;f=lib/memset_explicit.c;hb=refs/heads/stable-202301 https://gitweb.git.savannah.gnu.org/gitweb/?p=gnulib.git;a=b...

raverbashing 10mo ago
Yeah the C committee is wrong here
- uecker 10mo ago
  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.
  - raverbashing 10mo ago
    Because, for the 1384th time, they're pretending they can ignore what the programmer explicitly told them to do Creating memset_explicit won't fix existing code. "Oh but what if maybe" is just cope. If I do memset then free then that's what I want to do And the way things go I won't be surprised if they break memset_explicit for some other BS reason and then make you use memset_explicit_you_really_mean_it_this_time
    - uecker 10mo ago
      Your problem is not the C committee but your lack of understanding how optimizing compilers work. WG14 could, of course, specify that a compiler has do exactly what you tell it to do. And in fact, every compiler supports this already: Im most cases even by default! Just do not turn on optimization. But this is not what most people want. Once you accept that optimizing compilers do, well, optimizations, the question is what should be allowed and what not. Both inlining "memset" and eliminating dead stores are both simply optimizations which people generally want. If you want a store not to be eliminated by a compiler, you can make it volatile. The C standard says this can not be deleted by optimizations. The criticism with this was that later undefined behavior could "undo" this by "travelling in time". We made it clear in ISO C23 that this not allowed (and I believe it never was) - against protests from some compiler folks. Compilers still do not fully conform to this, which shows the limited power WG14 has to change reality.
      - raverbashing 10mo ago
        Nope it is the C committee > Once you accept that optimizing compilers do, well, optimizations Why in tarnation it is optimizing out a write to a pointer out before a function that takes said pointer? Imagine it is any other function besides free, see how ridiculous that sounds?
        shakna 10mo ago
        Tree shaking is pretty standard. Optimising out the write sounds fine to me - with the exception of a volatile pointer. That, there, is a mistake.
        raverbashing 10mo ago
        Optimizing out a write to (example) an array on the stack seems fine to me. Optimizing out a function call to a heap pointer (especially memset) seems wrong to me. You called the function, it should call the function! But it's again the C language saving time not wearing a seatbelt or checking the tire pressure for saving 10s on a 2h trip
sitkack 10mo ago
Relying on implementation behavior is the perfect way to introduce a hidden in plain site vulnerability.
- shakna 10mo ago
  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.
- CJefferson 10mo ago
  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.
- 112233 10mo ago
  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.