This is the mail archive of the
mailing list for the GCC project.
Re: Compiler support for erasure of sensitive data
- From: Szabolcs Nagy <nsz at port70 dot net>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: Paul_Koning at Dell dot com, dje dot gcc at gmail dot com, gcc at gcc dot gnu dot org, libc-alpha at sourceware dot org, musl at lists dot openwall dot com
- Date: Wed, 9 Sep 2015 22:26:54 +0200
- 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> <55F08296 dot 10003 at panix dot com>
* Zack Weinberg <firstname.lastname@example.org> [2015-09-09 15:03:50 -0400]:
> On 09/09/2015 02:02 PM, Paul_Koning@Dell.com wrote:
> >> On Sep 9, 2015, at 1:54 PM, David Edelsohn <email@example.com>
> >> wrote:
> >> 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?
> I *assume* David is referring to register renaming, which is not
> architecturally visible...
or async signal handler copying all the register state on sigaltstack
or internal counters and debug features making sensitive info observable
or timing/cache-effect side channels that let other processes get info
or compiling to a highlevel language (js) with different kind of leaks
or running under emulator/debugger that can make secrets visible
> I would consider data leaks via state inaccessible to a program
> executing at the same privilege level as the code to be hardened to be
> out of scope. (Which does mean that *when hardening an OS kernel* one
specifying the info leak at the abstract c machine level is not useful
(the memset is not observable there, unless you assign meaning to
undefined behaviour which is a can of worms), but you do have to specify
the leak on some abstraction level (that is applicable to the targets of
a compiler and gives useful security properties in practice) otherwise
the attribute is not meaningful.
leaks can happen for many reasons that are layers below the control
of the compiler, but still observable by high level code.