This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH RFC] explicit_bzero, again
- From: Zack Weinberg <zackw at panix dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 21 Aug 2015 10:24:12 -0400
- 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>
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?
Also, are you saying that this barrier should be part of
explicit_bzero itself, or something the application needs to do?
zw