Re: [RFC] [PATCH] Support explicit_bzero, memset_s, memzero_explicit, or similar.

[Nick Mathewson <nickm at torproject dot org>]

On Mon, Dec 22, 2014 at 2:46 PM, Rich Felker <dalias@libc.org> wrote:
> On Sun, Dec 21, 2014 at 11:33:17AM -0800, Paul Eggert wrote:
>> Nick Mathewson wrote:
>>
>> >if I'm reading the consensus right, people think
>> >that the implementation is correct, and the functionality is
>> >standards-conformant and probably better than nothing.
>>
>> I don't see that consensus.  As I recall, the proposed functionality
>> doesn't conform to C11 Annex K, and it's not clear (to me at least)
>> that the patch is better than nothing.
>
> It doesn't conflict with Annex K in any way. IMO there's a huge
> difference in adding an interface that conflicts with he requriements
> of Annex K (even if glibc doesn't want to support Annex K now or for
> the forseeable future), and adding one which simply does not support
> all the 'features' specified in Annex K but matches the semantics for
> the features it does support.

Incidentally, there are some places in glibc which, in order to match
the programmers' intent, probably need functionality like this today.

For example, see the memset calls at the end of:
     __md5_crypt_r
     __sha256_crypt_r
     __sha512_crypt_r

The documented intent there is to clear data from the stack before
returning, but the compiler is free to remove them IIUC.


(As I said before, it doesn't make a big difference to me whether a
non-removable memset is called memset_s() or whether it's called
explicit_bzero() or whether it gets another name entirely.)


cheers,
-- 
Nick