This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v3] explicit_bzero yet again

On 07/12/15 14: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

obviously the concern is about static linking.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]