The compiler knows the semantics of memset, specifically that it can be treated as a dead store. memset_s (and the other _s functions) have defined semantics of guaranteeing a write, even if it’s dead - a compiler that tried lowering them such that they did not zero the memory would be nonconforming. As a result they essentially just don’t special case them at all.
memset_s: more or less yes, that is the core of what this article is talking about.
It sounds like memset_explicit might be the “solution”. This requires the backend be aware of these semantics, and while I don’t know about GCC, llvm’s register allocation does not carry such info and I’ve generally encountered push back against adding the data required to track such semantics (though in my case in the context of pointer authentication). IMO it would be a general win for a lot of security related purposes.
The compiler knows the semantics of memset, specifically that it can be treated as a dead store. memset_s (and the other _s functions) have defined semantics of guaranteeing a write, even if it’s dead - a compiler that tried lowering them such that they did not zero the memory would be nonconforming. As a result they essentially just don’t special case them at all.
score 1 · canonical
Even if normally the variable is stored only in a register,
memset_s()has to write to memory? Even if marked non-volatile?score 1 · canonical
deleted by creator
memset_s: more or less yes, that is the core of what this article is talking about.
It sounds like memset_explicit might be the “solution”. This requires the backend be aware of these semantics, and while I don’t know about GCC, llvm’s register allocation does not carry such info and I’ve generally encountered push back against adding the data required to track such semantics (though in my case in the context of pointer authentication). IMO it would be a general win for a lot of security related purposes.
score 1 · canonical