On Fri, Oct 10, 2014 at 5:20 AM, Andrew Haley <aph@xxxxxxxxxx> wrote: >> The compiler would need to know that memset_s is special (either >> intrinsically or thorugh eg. function attributes). Either way, IMHO >> an advanced knowledge allowing to optimize it out would be a >> violation of K.3.7.4.1. > > It would be a perverse thing to do and goes against intent, but we > again fall into the problem of defining an access. ... So, > all we can have here is a best effort. Anyone who wants to be sure > that the key is wiped is going to have to do something machine- > dependent. I agree there may have to be some machine-dependent code, but it seems to me it should be in the definition of memset_s(). The library code (or the compiler if it provides it as a built-in) should deal with this so application programmers do not have to. That is one of the main reasons to have library functions. Almost any programmer could write a version of memset() easily, but we use the library function instead and let library implementers worry about things like optimizing for a particular word size or using assembler for speed. Similarly, making memset_s() live up to the spec is a problem for the library implementers. Currently glibc, at least on my Ubuntu box, does not have memset_s(), so Linux kernel code has memzero_explicit(). That is OK as a short-term solution, but memsets_s() would be a cleaner solution.
