On Wed, Sep 9, 2015 at 2:02 PM, <paul_kon...@dell.com> wrote: > >> On Sep 9, 2015, at 1:54 PM, David Edelsohn <dje....@gmail.com> wrote: >> >> On Wed, Sep 9, 2015 at 12:36 PM, Zack Weinberg <za...@panix.com> wrote: >> >>> The ABI dictates basically everything you see. The call to >>> explicit_bzero has forced the compiler to *create* a second copy of >>> the variable `k` on the stack, just so it can be erased -- and the >>> copy in registers survives (at least for a short time), which is not >>> what the programmer wanted. With or without explicit_bzero, we have >>> no way of getting rid of the copy in registers. More complicated >>> scenarios of course exist. >> >>> Comments? Please note that I do not have anything like the time >>> required to implement any of this myself (and I'm ten years out of >>> practice on GCC and have no experience whatsoever with Clang, >>> anyway). I'm hoping this catches someone's interest. >> >> What level of erasure of sensitive data are you trying to ensure? >> Assuming that overwriting values in the ISA registers actually >> completely clears and destroys the values is delusionally naive. > > Could you point to some references about that? > >> Most modern hardware architectures have hardware capabilities to >> encrypt and protect sensitive data. > > I'm not sure about "most". I haven't worked on any that could do this.
Intel, Power, z/Arch, and (probably) SPARC. > > I agree it would be good to specify the threat model. Reading between the > lines, I believe it is: capture of the software-visible process state after > the code is finished with the sensitive data, either via a process dump file, > or a debugger. With an explicitly stated list of goals and non-goals we can > see whether a proposed solution addresses all, part, or none of the problem > space, and whether it is a small solution or one much more powerful than is > actually requested. > > If the threat is indeed delayed process state examination in software, then I > think your "dangerously naive" does not apply. If you're talking excavating > the chip and doing quantum forensics, that's a different matter. If this feature is implying / assuring that all values have been irrecoverably destroyed, and one can find the values in physical register files, then one is being dangerously naive in the assertions / expectations about the feature. One must specify the threat model. - David