<div dir="ltr">Seems reasonable, but I think you would need to zap the stack memory too, as well as the memory used for inner calls.<div><br></div><div>This would probably end up being an LLVM IR function attribute that gets handled in the backend.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 11, 2014 at 7:30 PM, Russell Harmon <span dir="ltr"><<a href="mailto:eatnumber1@google.com" target="_blank">eatnumber1@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I've been thinking about the issues with securely zero'ing buffers that Colin Percival discusses in his <a href="http://www.daemonology.net/blog/2014-09-06-zeroing-buffers-is-insufficient.html" target="_blank">blog article</a>, and I think I'd like to take a stab at fixing it in clang. Here's my proposal:<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>What does the list think?</div><div>-Russ Harmon</div>
<br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div>