Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 9 Sep 2015 14:11:52 -0400
From: David Edelsohn <>
Cc: Zack Weinberg <>, GCC Development <>, 
	GNU C Library <>,
Subject: Re: Compiler support for erasure of sensitive data

On Wed, Sep 9, 2015 at 2:02 PM,  <> wrote:
>> On Sep 9, 2015, at 1:54 PM, David Edelsohn <> wrote:
>> On Wed, Sep 9, 2015 at 12:36 PM, Zack Weinberg <> 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.