This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v3] explicit_bzero yet again
- From: Zack Weinberg <zackw at panix dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: GNU C Library <libc-alpha at sourceware dot org>, Joseph Myers <joseph at codesourcery dot com>
- Date: Mon, 7 Dec 2015 09:13:08 -0500
- Subject: Re: [PATCH v3] explicit_bzero yet again
- Authentication-results: sourceware.org; auth=none
- References: <564DE0BE dot 5070607 at panix dot com> <20151119155533 dot GT3818 at brightrain dot aerifal dot cx>
On 11/19/2015 10:55 AM, Rich Felker wrote:
> On Thu, Nov 19, 2015 at 09:46:22AM -0500, Zack Weinberg wrote:
>> [PATCH 1/3] New library function, explicit_bzero
>>
>> The new function explicit_bzero is functionally identical to bzero,
>> but the compiler will not delete a call to it, even if the memory
>> region it's applied to is dead after the call. You should use this
>> function, for instance, to erase cryptographic keys or similar when
>> you are done with them. Taken from OpenBSD.
>
> Perhaps glibc explicitly does not support LTO, but with LTO this is
> trivially removable by the compiler. IMO from the beginning there
> should be asm constraints to make it impossible to remove the code
> even if it's inlined.
Presently there *is* no such asm construct (all possibilities either
don't work sufficiently universally, someone on this list has already
objected to them, or both). Therefore I do not think this is feasible.
However, presently no compiler will LTO-optimize across shared library
boundaries, and even if such a compiler existed I would argue that the
optimization you contemplate is invalid for functions whose semantics
are unknown to the compiler, because the library could be swapped out at
runtime.
zw