|
Date: Wed, 9 Sep 2015 14:11:52 -0400 From: David Edelsohn <dje.gcc@...il.com> To: Paul_Koning@...l.com Cc: Zack Weinberg <zackw@...ix.com>, GCC Development <gcc@....gnu.org>, GNU C Library <libc-alpha@...rceware.org>, musl@...ts.openwall.com Subject: Re: Compiler support for erasure of sensitive data On Wed, Sep 9, 2015 at 2:02 PM, <Paul_Koning@...l.com> wrote: > >> On Sep 9, 2015, at 1:54 PM, David Edelsohn <dje.gcc@...il.com> wrote: >> >> On Wed, Sep 9, 2015 at 12:36 PM, Zack Weinberg <zackw@...ix.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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.