This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Compiler support for erasure of sensitive data
- From: David Edelsohn <dje dot gcc at gmail dot com>
- To: Paul_Koning at dell dot com
- Cc: Zack Weinberg <zackw at panix dot com>, GCC Development <gcc at gcc dot gnu dot org>, GNU C Library <libc-alpha at sourceware dot org>, musl at lists dot openwall dot com
- Date: Wed, 9 Sep 2015 14:11:52 -0400
- Subject: Re: Compiler support for erasure of sensitive data
- Authentication-results: sourceware.org; auth=none
- References: <55F05FF1 dot 3000405 at panix dot com> <CAGWvnykLHzcM+puBr4G0gGOefpdVjg77mCsd3GM9--HAOacivg at mail dot gmail dot com> <EEF686A4-BC3C-4BC8-BEB8-3502965F2405 at dell dot com>
On Wed, Sep 9, 2015 at 2:02 PM, <Paul_Koning@dell.com> wrote:
>
>> On Sep 9, 2015, at 1:54 PM, David Edelsohn <dje.gcc@gmail.com> wrote:
>>
>> On Wed, Sep 9, 2015 at 12:36 PM, Zack Weinberg <zackw@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