[PATCH 2/4] New string function explicit_bzero (from OpenBSD).

[Adhemerval Zanella]

On 18/08/2016 17:53, Torvald Riegel wrote:
> On Thu, 2016-08-18 at 20:31 +0200, Florian Weimer wrote:
>> On 08/17/2016 07:19 PM, Zack Weinberg wrote:
>>> +#ifdef __USE_MISC
>>> +/* As bzero, but the compiler will not delete a call to this
>>> +   function, even if S is dead after the call.  Note: this function
>>> +   has its own implementation file and should not be slurped into
>>> +   string-inlines.o.  */
>>> +__extern_inline void
>>> +explicit_bzero (void *__s, size_t __n)
>>> +{
>>> +  memset (__s, '\0', __n);
>>> +  __glibc_read_memory (__s, __n);
>>> +}
>>> +#endif
>>
>> __extern_inline can expand to nothing at all, and you would get multiple 
>> definitions of explicit_bzero this way.
>>
>> I don't think we want explicit_bzero to be inlined, it's useful to have 
>> this name in the executable.  Furthermore, we might want to add 
>> additional state clearing later, so an implementation in libc.so.6 seems 
>> desirable anyway.
>>
>> For an implementation in libc, there is currently no different between 
>> the __glibc_read_memory kludge and a full memory barrier, so I suggest 
>> to go with the latter.  (The explicit_bzero call will serve as a rather 
>> broad barrier anyway, but we can annotate it with __THROW.)
> 
> I suppose we just want a compiler barrier here though, and don't need a
> memory barrier in the sense of something that constrains HW reordering.

I would also suggest to avoid adding this inline optimization, it just add
another exported symbol by glibc with little performance benefit.