This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 0/3] explicit_bzero v5
- From: Zack Weinberg <zackw at panix dot com>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, "Carlos O'Donell" <carlos at redhat dot com>, Florian Weimer <fweimer at redhat dot com>
- Date: Tue, 15 Nov 2016 12:46:17 -0500
- Subject: Re: [PATCH 0/3] explicit_bzero v5
- Authentication-results: sourceware.org; auth=none
- References: <20161115155509.12692-1-zackw@panix.com> <677c23f1-d10a-890d-b875-039d32a3d228@cs.ucla.edu>
On Tue, Nov 15, 2016 at 11:20 AM, Paul Eggert <eggert@cs.ucla.edu> wrote:
> On 11/15/2016 07:55 AM, Zack Weinberg wrote:
>>
>> Paul Eggert also observed that a call to explicit_bzero might expose
>> the_address_ of a buffer containing sensitive data, and perhaps
>> another thread could exfiltrate the data before it was erased.
>> I thought about it and I have concluded that this, like the other
>> remaining problems with this API, needs to be addressed in the
>> compiler
>
>
> That sounds reasonable. Could you please document this, though? Perhaps
> something like the following, after the paragraph about copying objects?
>
>
> @strong{Warning:} Calling @code{explicit_bzero} may expose
> the object's address to other parts of the program, defeating
> address space layout randomization.
Without a concrete, short example, like we have for the
copying-objects scenario, I think this will confuse people more than
it helps. And I am currently failing to think of such an example - in
fact, thinking about it is only leading me to suspect that, in any
scenario where the arguments to explicit_bzero are visible to
malicious code, the adversary has already won. Those arguments, after
all, are either in registers or on the stack. If the adversary can
read either of those, they can already learn return addresses.
Do you have any suggestions?
zw