Re: Compiler support for erasure of sensitive data

[David Edelsohn <dje dot gcc at gmail 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