Re: [PATCH] explicit_bzero final

[Zack Weinberg <zackw@panix.com>]

On Fri, Dec 16, 2016 at 1:26 PM, Jeff Law <law@redhat.com> wrote:
> On 12/15/2016 04:21 PM, Zack Weinberg wrote:
>> To be clear, explicit_bzero itself is not going away.  It is already in
>> use in a wide variety of applications, and substitutes (such as the
>> hypothetical __attribute__((sensitive))) will not become widespread
>> quickly enough to avoid adding it to glibc.  I've been working on this
>> patch off and on for _two years_, and I picked it up from someone else
>> who'd given up on the process after roughly that long himself.  I fully
>> intend to commit it in some form tomorrow evening; I consider missing
>> 2.25 unacceptable.
>
> Understood.  And my position is that explicit_bzero is inherently flawed.
> You really need direct compiler support.
>
> So while it's not going away and it's an incremental improvement over
> nothing, it comes with a cost.  Namely that some objects which previously
> weren't addressable become addressable and are now sitting in memory waiting
> to be extracted.

I do agree with both parts of this as well.

>> What I'd hope we could do with compiler-side smarts is _convert_
>> explicit_bzero to __attribute__((sensitive)) or a clobbering assignment
>> or whatever the most convenient compiler-side representation winds up
>> being, so that artifacts of glibc's implementation become irrelevant.
>
> We can likely infer something passed to explicit_bzero is sensitive and
> build a web to capture whatever DECLs potentially feed the explicit_bzero.
> So we convert the fence to the CONSTRUCTOR assignment.  That's fine. Then
> we'd want DSE to eliminate the memset, then recompute addressability.

What I just committed to glibc does not have the inlines, so that
memset won't be kicking around.  It will probably still be necessary
to recompute addressability after lowering the builtin, though.

I wish I could say that I would have time to help with making compiler
support happen, but realistically I don't.

zw