Re: [PATCH RFC] explicit_bzero, again

[Florian Weimer <fweimer at redhat dot com>]

On 08/21/2015 04:24 PM, Zack Weinberg wrote:
> On Fri, Aug 21, 2015 at 2:37 AM, Florian Weimer <fweimer@redhat.com> wrote:
>> On 08/16/2015 06:43 PM, Zack Weinberg wrote:
>>> +@strong{Warning:} The compiler is free to make additional copies of
>>> +any object, or parts of it, in temporary storage areas (such as
>>> +registers and ``scratch'' stack space).  @code{explicit_bzero} does
>>> +not guarantee that temporary copies of sensitive data are destroyed.
>>
>> Perhaps you should add that explicit_bzero can create the copy which it
>> is about to overwrite, leaving the original untouched.  A partial
>> countermeasure could be a barrier with register clobbers for as many
>> caller-saved registers as possible.
> 
> I'm not doubting you, but that's surprising enough that if I am going
> to put it in the manual, it needs an example of the situation where it
> can happen, and I am failing to think of one; what do you have in
> mind?

Oh, if you find it surprising, it is certainly worth documenting.
Here's an example:

  <https://gcc.gnu.org/ml/gcc-help/2014-10/msg00071.html>

Any variable which is not already addressable for another reason is
likely to trigger such behavior.

> Also, are you saying that this barrier should be part of
> explicit_bzero itself, or something the application needs to do?

Calling explicit_bzero should take care of that, I think.  I'm not
completely sure how to achieve that.  It might be sufficient to put the
barrier into the implementation, or it might have to be in a wrapper in
a header file.

-- 
Florian Weimer / Red Hat Product Security