[cfe-dev] Zero'ing Registers on Function Return

[Robinson, Paul]

Add a function attribute, say __attribute__((clear_regs_on_return)) which when a thus annotated function returns will zero all callee owned registers and spill slots.
Seems reasonable, if insufficient.  For compiler-guaranteed clearing, the annotated function would have to have other restrictions. (Can't call external functions; can't call local functions that aren't also marked clear-on-return; can't have optimizations do things like convert memset-style loops into memset calls.)

Then, all unused caller owned registers will be immediately cleared by the caller after return.
Seems completely wrong. Why should the caller clear its own registers?  ABI says callee left them alone (or restored them) therefore they contain no sensitive state left behind by the callee.  Or did I misunderstand this part of the spec?
--paulr

From: cfe-dev-bounces at cs.uiuc.edu [mailto:cfe-dev-bounces at cs.uiuc.edu] On Behalf Of Russell Harmon
Sent: Thursday, September 11, 2014 7:31 PM
To: cfe-dev at cs.uiuc.edu
Subject: [cfe-dev] Zero'ing Registers on Function Return

I've been thinking about the issues with securely zero'ing buffers that Colin Percival discusses in his blog article<http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html>, and I think I'd like to take a stab at fixing it in clang. Here's my proposal:

Add a function attribute, say __attribute__((clear_regs_on_return)) which when a thus annotated function returns will zero all callee owned registers and spill slots. Then, all unused caller owned registers will be immediately cleared by the caller after return.

As for why, I'm concerned with the case where a memory disclosure vulnerability exposes all or a portion of sensitive data via either spilled registers or infrequently used registers (xmm). If an attacker is able to analyze a binary for situations wherein sensitive data will be spilled, leveraging a memory disclosure vulnerability it's likely one could craft an exploit that reveals sensitive data.

What does the list think?
-Russ Harmon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140912/a44336df/attachment.html>