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

Jonathan Roelofs jonathan at codesourcery.com
Fri Sep 12 05:56:35 PDT 2014



On 9/11/14 9:53 PM, Robinson, Paul wrote:
> 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?
"zero all the callee-modified registers which are not return values" perhaps?

Jon
>
> --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
>
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>

-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded



More information about the cfe-dev mailing list