This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Compiler support for erasure of sensitive data
- From: Zack Weinberg <zackw at panix dot com>
- To: Paul_Koning at Dell dot com, dje dot gcc at gmail dot com
- Cc: 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 15:03:50 -0400
- 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>
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