<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">check this out: <a href="http://users.ece.cmu.edu/~ejschwar/bib/schwartz_2011_rop-abstract.html" target="_blank">http://users.ece.cmu.edu/~ejschwar/bib/schwartz_2011_rop-abstract.html</a><br>
<br>
tl;dr: a minimal executable (from 20kB on) likely provides enough gadgets, real life<br>
executables and libraries (think glibc, apache, firefox, etc) have more than enough.<br>
<span class=""><br>
> but something that I found interesting in <a href="https://www.ics.uci.edu/~ahomescu/multicompiler_cgo13.pdf" target="_blank">https://www.ics.uci.edu/~ahomescu/multicompiler_cgo13.pdf</a><br>
> is how figure 2 shows that inserting a nop between instructions reduce the possibility of finding<br>
> gadgets on x86 because of the variable-length encoding.<br>
<br>
</span>this is only true for gadgets that are composed of unintended byte sequences (i.e,<br>
where the redirected control flow jumps into the middle of intended insns) and only<br>
if such sequences cross intended insn boundaries. as you can see in the paper, there's<br>
no case where gadgets are eliminated altogether, only their numbers are reduced and<br>
that means that blind ROP will work against these binaries.</blockquote><div><br></div><div>Sorry, I'm kind of lost as to what you're arguing for/against. Could we back up a bit?</div><div><br></div><div>Do you think nop insertion is a poor mitigation on its own? Or do you think it's not useful even when combined with other mitigations?</div><div><br></div><div>I'm also not clear on what kind of attack you're making assertions for: LLVM is used in many different situations, and adding tools such as this may be thoroughly useless in some situations and really useful in others.</div></div></div></div>