This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH RFC] explicit_bzero, again
- From: Florian Weimer <fweimer at redhat dot com>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 21 Aug 2015 16:29:18 +0200
- Subject: Re: [PATCH RFC] explicit_bzero, again
- Authentication-results: sourceware.org; auth=none
- References: <55C7E246 dot 3000006 at panix dot com> <55D0BDA7 dot 40402 at panix dot com> <55D6C745 dot 30000 at redhat dot com> <CAKCAbMhC-zUqxdV1jcO_KYhnX1_2s+z5d2Amb+0r7TxKaN1b4w at mail dot gmail 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