This is the mail archive of the 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 RFC] explicit_bzero, again

On 08/21/2015 04:24 PM, Zack Weinberg wrote:
> On Fri, Aug 21, 2015 at 2:37 AM, Florian Weimer <> 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:


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

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