<div dir="ltr">I thought a little about implementing PAX_RANDSTRUCT for clang a couple months back but I didn't get to the point where I implemented anything. My notes indicate that my two ideas at the time I left it were: (1) see if there's a point between parsing and codegen that a clang plugin could insert a TreeTransform to rewrite struct definitions, or (2) perform randomization as an LLVM pass that rewrites types and the GEPs, GVs, etc. referencing those types.<div><br></div><div>For approach #2 you would need to hook into offsetof()--Linux defines offsetof() as both __builtin_offsetof() and ((size_t) &((TYPE *)0)->MEMBER) in different places. The latter would transform into a GEP and shouldn't require special casing, while the former might mean it's not doable as an LLVM pass alone. Thinking about it now, if you wanted to implement the unoptimized version of RANDSTRUCT (where elements are randomized across cache lines) you would also need to hook into sizeof() as well. I might be missing other code constructs that would further complicate the pass approach.</div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Sep 21, 2017 at 6:08 PM Friedman, Eli via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
Recently our team was asked about the possibility of implementing<br>
functionality equivalent to the Linux kernel's randstruct gcc plugin for<br>
clang.  Essentially, what the plugin does is modify the AST to put the<br>
members of structs marked with "__attribute__((randomize_layout))" in a<br>
random order (order chosen at compile-time, and controlled by a provided<br>
seed).  The idea is that this provides security hardening by making it<br>
harder for an attacker to guess where a field is stored in memory.  See<br>
<a href="https://lwn.net/Articles/722293/" rel="noreferrer" target="_blank">https://lwn.net/Articles/722293/</a> for more details.<br>
<br>
I can see the following possible approaches for implementing this with<br>
clang:<br>
<br>
1. A source-rewriting plugin which generates a new version of the source<br>
code with reordered structs.  This probably doesn't require any changes<br>
to clang itself, but it introduces a bunch of complexity interacting<br>
with the build system for a project.<br>
<br>
2. Some new kind of plugin which hooks deeply into semantic analysis;<br>
not sure what this would look like.<br>
<br>
3. Modifying clang's structure layout code.  This is probably easiest to<br>
write the code for, but merging it to the clang repo would require<br>
consensus that this is actually generally useful.<br>
<br>
Has anyone else looked at this?<br>
<br>
-Eli<br>
<br>
--<br>
Employee of Qualcomm Innovation Center, Inc.<br>
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>