Optimising away memset() calls?

[Sandy Harris]

On Fri, Oct 10, 2014 at 5:20 AM, Andrew Haley <aph@redhat.com> 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.