This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] explicit_bzero final
- 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>, Joseph Myers <joseph at codesourcery dot com>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, Wilco Dijkstra <Wilco dot Dijkstra at arm dot com>
- Date: Tue, 13 Dec 2016 10:53:45 -0500
- Subject: Re: [PATCH] explicit_bzero final
- Authentication-results: sourceware.org; auth=none
- References: <20161212230622.14045-1-zackw@panix.com> <96232743-345c-5126-e526-9a8aadc4fdb7@redhat.com>
On Tue, Dec 13, 2016 at 2:02 AM, Florian Weimer <fweimer@redhat.com> wrote:
> On 12/13/2016 12:06 AM, Zack Weinberg wrote:
>> By exposing __glibc_read_memory to external callers, we can write
>> a fortify wrapper for explicit_bzero in terms of __memset_chk and
>> __glibc_read_memory.
>
> I need to talk to some GCC people to see if the above is just plain ugly, or
> something that can actively interfere with predictable properties of a
> fortified call to explicit_bzero.
It's probably good to loop in some GCC people, but off the top of my
head, I think it should be sufficient to have it treat a call to
'__glibc_read_memory' as triggering the same special behavior as a
call to 'explicit_bzero'. Of course that would mean
__glibc_read_memory can't be used for other cases where we need a
"those writes are not dead" optimization fence, so maybe I should
rename it __explicit_bzero_fence or something like that.
zw