Re: Compiler support for erasure of sensitive data

[Szabolcs Nagy <nsz at port70 dot net>]

* Zack Weinberg <zackw@panix.com> [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 <dje.gcc@gmail.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
or...

> 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.