Re: Compiler support for erasure of sensitive data

[Zack Weinberg <zackw@panix.com>]

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

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

This is correct.  Other avenues for the sensitive data to leak include
use-after-free or out-of-bounds memory reads within the program, and
malicious code (having gained control via some other bug) scanning
memory in bulk.

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
would possibly have to worry about special mechanisms that reveal the
"true" register file, and the like, but I'd be plenty happy with
something that was good enough for user mode.)  Techniques involving
direct manipulation of the hardware or the microcode, ditto.

> Another threat that I don't believe is covered here is disclosure of
> copies of the process state held in the OS, like saved context from
> thread switching, copies of stuff in the page file or in now-freed
> memory pages, or things like that.

Some of that might conceivably be in-scope; jmp_buf comes to mind.  (I'm
not prepared to make an exhaustive list at the moment.)  Normally,
people programming this kind of code expect to have to lock pages in
memory and so on.

zw