This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH v3] explicit_bzero yet again
- From: Alexander Cherepanov <ch3root at openwall dot com>
- To: Zack Weinberg <zackw at panix dot com>, 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, 11 Jan 2016 18:34:21 +0300
- 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> <566593F4 dot 8040108 at panix dot com>
On 2015-12-07 17:13, Zack Weinberg wrote:
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
I see that you added some uses of explicit_bzero into glibc. Hence
global optimization of glibc itself is a concern?