Re: [PATCH] explicit_bzero final

[Jeff Law <law at redhat dot com>]

On 12/13/2016 08:53 AM, Zack Weinberg wrote:
> On Tue, Dec 13, 2016 at 2:02 AM, Florian Weimer <fweimer@redhat.com> wrote:
> > On 12/13/2016 12:06 AM, Zack Weinberg wrote:
> > > By exposing __glibc_read_memory to external callers, we can write
> > > a fortify wrapper for explicit_bzero in terms of __memset_chk and
> > > __glibc_read_memory.
> >
> > I need to talk to some GCC people to see if the above is just plain ugly, or
> > something that can actively interfere with predictable properties of a
> > fortified call to explicit_bzero.
>
> It's probably good to loop in some GCC people, but off the top of my
> head, I think it should be sufficient to have it treat a call to
> '__glibc_read_memory' as triggering the same special behavior as a
> call to 'explicit_bzero'.  Of course that would mean
> __glibc_read_memory can't be used for other cases where we need a
> "those writes are not dead" optimization fence, so maybe I should
> rename it __explicit_bzero_fence or something like that.
It's going to be hard for GCC to recognize the memset_chk+read_memory as 
an explict_bzero.  It'll have to infer it from the code pattern, which 
is inherently prone to misses.

I'd also worry that this style definition may be prone to goofs.  The 
keys being that if LTO were to see inside __glibc_read_memory and 
realize that the reads are dead and removes the reads.

That would in turn allow DSE to come along and potentially realize that 
the memory written by builtin__memset_chk is never read -- and GCC would 
wipe out the call to builtin__memset_chk.  That, of course, leaves the 
secret data in memory and available for someone to try and extract.

I think a proper explicit_bzero is probably a better choice.  We ought 
to be able to tag it properly and ensure that it never goes away.

Jeff