From: David Edelsohn <dje.gcc@gmail.com>
To: Paul_Koning@dell.com
Cc: Zack Weinberg <zackw@panix.com>,
GCC Development <gcc@gcc.gnu.org>,
GNU C Library <libc-alpha@sourceware.org>,
musl@lists.openwall.com
Subject: Re: Compiler support for erasure of sensitive data
Date: Wed, 9 Sep 2015 14:11:52 -0400 [thread overview]
Message-ID: <CAGWvnykFeiupQEkNiWnwHdiNnWQHqLufMiC4L38ih7XPyGANww@mail.gmail.com> (raw)
In-Reply-To: <EEF686A4-BC3C-4BC8-BEB8-3502965F2405@dell.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
next prev parent reply other threads:[~2015-09-09 18:11 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-09 16:36 Zack Weinberg
2015-09-09 16:39 ` Fwd: " Zack Weinberg
2015-09-09 16:41 ` Zack Weinberg
2015-09-09 16:42 ` Rich Felker
2015-09-09 16:47 ` [musl] " Zack Weinberg
2015-09-09 17:13 ` Rich Felker
2015-09-09 18:48 ` [musl] " Zack Weinberg
2015-09-09 20:05 ` Rich Felker
2015-09-09 16:52 ` Paul_Koning
2015-09-09 16:58 ` Zack Weinberg
2015-09-09 17:25 ` [musl] " Rich Felker
2015-09-09 17:54 ` David Edelsohn
2015-09-09 18:02 ` Paul_Koning
2015-09-09 18:11 ` David Edelsohn [this message]
2015-09-09 19:03 ` Zack Weinberg
2015-09-09 20:26 ` Szabolcs Nagy
2015-10-22 16:02 ` [musl] " Denys Vlasenko
2015-10-22 16:09 ` Denys Vlasenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAGWvnykFeiupQEkNiWnwHdiNnWQHqLufMiC4L38ih7XPyGANww@mail.gmail.com \
--to=dje.gcc@gmail.com \
--cc=Paul_Koning@dell.com \
--cc=gcc@gcc.gnu.org \
--cc=libc-alpha@sourceware.org \
--cc=musl@lists.openwall.com \
--cc=zackw@panix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).