<div dir="ltr">Hi Oskar, <div><br></div><div>You may want to look at how the ShadowCallStack is implemented:</div><div><a href="https://clang.llvm.org/docs/ShadowCallStack.html">https://clang.llvm.org/docs/ShadowCallStack.html</a></div><div>Note that the current LLVM trunk supports only AARch64, </div><div>but at some point we also had a x86_64 implementation (which wasn't very useful and so we removed it). </div><div><br></div><div>Not sure if this is exactly what you are looking for, but will give you something. </div><div><br></div><div>Also, maybe reach out to the authors of <a href="https://www.semanticscholar.org/paper/SCADS-Separated-Control-and-Data-Stacks-Kugler-M%C3%BCller/af9d39f8002ba2047841258e9d761d162fb5aea1">SCADS</a>, who did something very similar to your proposal.  </div><br>--kcc<div><br></div><div> </div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Apr 8, 2019 at 6:00 AM Oskar Szakinnis via llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>

    
<div><p>Hello,<br></p><p><br></p><p>I'm attempting to implement a buffer overflow protection mechanism very similar to safestack. The key difference of my approach is that the "unsafe stack" should be accessed using the target dependent frame pointer (as for now, I'm focusing on x86 architecture specifically).<br></p><p>However, I'm unsure how to go about this. Simply modifying the existing safestack pass seems to be insufficient: from my understanding, safestack lets the compiler choose a free GPR by design (see [0]) and I don't see a way to force a specific register to be used at IR stage.</p><p>I thought about implementing an instruction similar to alloca (lets call it allocaUS for the moment), which replaces all "unsafe" allocas and works identically to alloca, but is eventually lowered in a way that it uses the frame pointer instead of the stack pointer. I know that adding a new instruction into the IR instruction set is discouraged, as stated at [1]. <br></p><p>Another option would be to modify the the LLVM target-independent code generator [2], so that "unsafe" alloca instructions will be treated differently during the generation of the SelectionDAG or the instruction selection/register allocation phases.<br></p><p>Which stage of code generation would be a suitable starting point for me to implement such a mechanism? Did I miss an even better option? <br></p><p><br></p><p>Thank you<br></p><p>Oskar<br></p><p><br></p><p>[0] <a href="https://github.com/llvm-mirror/llvm/blob/9736ffc02af86add87912db3427d088bf6bbd94d/lib/CodeGen/SafeStack.cpp#L796" target="_blank">https://github.com/llvm-mirror/llvm/blob/9736ffc02af86add87912db3427d088bf6bbd94d/lib/CodeGen/SafeStack.cpp#L796</a></p><p>[1] <a href="https://llvm.org/docs/ExtendingLLVM.html" target="_blank">https://llvm.org/docs/ExtendingLLVM.html</a><br></p><p>[2] <a href="https://llvm.org/docs/CodeGenerator.html" target="_blank">https://llvm.org/docs/CodeGenerator.html</a><br></p></div>
 _______________________________________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br>
</blockquote></div>