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 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


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