This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] explicit_bzero final
On 12/15/2016 04:21 PM, Zack Weinberg wrote:
Right. Just to correct a bit on terminology, it's not spilled to the
stack, but the object has to be addressable due to the call to
explicit_bzero. That forces the object into the stack. It might still
wind up in the stack due to other reasons (it's an aggregate and thus
not subject to live in registers).
Right. I suspect that sensitive data objects pretty much always wind up
in memory anyway, but people _were_ really worried about the case where
explicit_bzero is the only thing that makes one addressable.
Agreed on both accounts.
To be clear, explicit_bzero itself is not going away. It is already in
use in a wide variety of applications, and substitutes (such as the
hypothetical __attribute__((sensitive))) will not become widespread
quickly enough to avoid adding it to glibc. I've been working on this
patch off and on for _two years_, and I picked it up from someone else
who'd given up on the process after roughly that long himself. I fully
intend to commit it in some form tomorrow evening; I consider missing
2.25 unacceptable.
Understood. And my position is that explicit_bzero is inherently
flawed. You really need direct compiler support.
So while it's not going away and it's an incremental improvement over
nothing, it comes with a cost. Namely that some objects which
previously weren't addressable become addressable and are now sitting in
memory waiting to be extracted.
What I'd hope we could do with compiler-side smarts is _convert_
explicit_bzero to __attribute__((sensitive)) or a clobbering assignment
or whatever the most convenient compiler-side representation winds up
being, so that artifacts of glibc's implementation become irrelevant.
We can likely infer something passed to explicit_bzero is sensitive and
build a web to capture whatever DECLs potentially feed the explicit_bzero.
So we convert the fence to the CONSTRUCTOR assignment. That's fine.
Then we'd want DSE to eliminate the memset, then recompute addressability.
Then you just have to find a way to deal with the argument passing and
register allocation artifacts, and that's going to be hard I suspect.
Yeah. But hey, at least it won't involve reload, right?
Depends on your target :-)
You've also got things like setjmp, caller saves, etc which can stuff
registers into memory that you'll want to deal with. But at least the
surface is getting smaller.
jeff