This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]