<div dir="ltr">re. integrating with the community: this is certainly something we're willing to do. when i mentioned that we have funding through 2015, what i wanted to communicate is that we're not going to dump this patch and disappear from the llvm community :)<div>
<br></div><div>re. copyright protection: diversity has indeed been positioned against a defense against piracy [1]. that being said, i think the current diversity patch will make complicate cracking but certainly not make it impossible. a secondary effect of nop insertion is that the resulting binary has an unique pattern that facilitates tracing pirated software back to the source. (note that removing the nop pattern without breaking or slowing down the program is very hard due to the difficulties of disassembly.) we'll certainly support this use case if need be.</div>
<div><br></div><div>beyond the two above mentioned uses, diversity complicates/protects patch reverse engineering [2] and attacks against just-in-time compilers too [3]. again, i'm not claiming that nop insertion is ideal in these cases, my point is rather that diversity is indeed a multi-pronged defense. </div>
<div><br></div><div>cheers,</div><div>per</div><div><div class="gmail_extra"><br>[1] <a href="http://dl.acm.org/citation.cfm?id=1029157">http://dl.acm.org/citation.cfm?id=1029157</a></div><div class="gmail_extra">[2] <a href="http://dl.acm.org/citation.cfm?id=2400683">http://dl.acm.org/citation.cfm?id=2400683 </a></div>
<div class="gmail_extra">[3] <a href="http://dl.acm.org/citation.cfm?id=2516675">http://dl.acm.org/citation.cfm?id=2516675</a></div><div class="gmail_extra">(if you cannot access these articles through acm, google for the title to download them from the author's home page.)<br>
<br><div class="gmail_quote">On Thu, Jan 23, 2014 at 7:49 PM, Sean Silva <span dir="ltr"><<a href="mailto:silvas@purdue.edu" target="_blank">silvas@purdue.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">On Thu, Jan 23, 2014 at 10:07 PM, Alp Toker <span dir="ltr"><<a href="mailto:alp@nuanti.com" target="_blank">alp@nuanti.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><br>
On 24/01/2014 01:08, Sean Silva wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Was there ever consensus that we want to maintain this in LLVM? I just looked back at the original thread on llvmdev, and it looked like basically:<br>
<br>
- A number of security folks having an inconclusive, wandering, back-and-forth discussion about various security things that should have been done on a security mailing list.<br>
- Lots of "this seems maybe interesting, but ..." with the "but ..." not clearly addressed in any way. Often times the "but ..." was an alternative approach that would be more maintainable, effective, and/or fit in better with existing deployment processes.<br>
- No concrete use cases.<br>
</blockquote>
<br></div>
It's a killer feature for anyone who has to support copy protection mechanisms in commercial software.<br></blockquote><div><br></div></div><div>This was not brought up in the original discussion thread, and seems outside the scope of what the Irvine team is working on. Per Larsen said that they were working under these two programs <<a href="http://www.darpa.mil/Our_Work/I2O/Programs/Clean-slate_design_of_Resilient_Adaptive_Secure_Hosts_(CRASH).aspx" target="_blank">http://www.darpa.mil/Our_Work/I2O/Programs/Clean-slate_design_of_Resilient_Adaptive_Secure_Hosts_(CRASH).aspx</a>> and <<a href="http://www.darpa.mil/Our_Work/I2O/Programs/Mission-oriented_Resilient_Clouds_(MRC).aspx" target="_blank">http://www.darpa.mil/Our_Work/I2O/Programs/Mission-oriented_Resilient_Clouds_(MRC).aspx</a>> which have no connection with copy protection.</div>
<div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Software "cracks" are smart enough to find and patch patterns even when binaries change between releases, but nops and register shuffling will block the kind of automated "farming" organised criminals use.</blockquote>
<div><br></div></div><div>I'd be amazed if such a trivial code modification would fool crackers (and you certainly don't need a CSPRNG for that use case). Joe (CC'd), I know you guys at Arxan have a lot of experience with this kind of thing. Can you maybe give some input on this patch from a copy protection perspective?</div>
<div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
A feature that's so easy to deploy (just switch compiler flag every point release) is a valuable tool in giving the edge back to individuals and companies who have to earn some or all of their living through commercial software.</blockquote>
<div><br></div></div><div>I'm not saying that you're wrong, but I think that this needs to be discussed; there was a fairly lengthy thread about this "diversity for security" thing a while back, and nobody seemed to bring up this facet of the functionality.</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Who is going to be deploying this? If nobody is deploying, then how do we know it will be maintained? It seems like the initial patch submitter has already jumped ship on this patch; doesn't exactly inspire confidence.<br>
</blockquote>
<br></div>
Clearly the two use cases are copy protection and security through obscurity so genuine users aren't going to be at liberty to join an open debate here.</blockquote><div><br></div></div><div>Maybe such a feature doesn't belong in an open-source project then ;)</div>
<div><br></div><div>Neither of the two use cases you mentioned seem to be even remotely related to the actual intent of this patch as described by its authors. In Stephen's original email he describes it as "This diversity prevents<br>
code-reuse attacks such as return-oriented-programming (ROP) by<br>denying the attacker information about the exact code layout."</div><div><br></div><div>Irvine team, is am I understanding this correctly? Or is the use case Alp is describing something that you are aiming for and would be willing to support? <br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
It seems like basically nobody who participated in the original discussion on llvmdev is participating in this patch review either. Especially the people who had doubts don't seem to be participating; those doubts need to be addressed.<br>
</blockquote>
<br></div>
Having spent the day cleaning up dubious code that LLVM developers themselves landed and walked away from, this patch makes a refreshing change: a high quality contribution with responsive author that succinctly implements a "killer feature" for many of our users in very few lines of code.<div>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Also, at the very least, adding the RNG should be split out into a separate patch.<br>
</blockquote>
<br></div>
Why? We usually land supporting facilities together with the first use for ease of review and testing.<br></blockquote><div><br></div></div><div>Especially for integrating with foreign code, we do separate patches (even sometimes separate discussions on llvmdev), consult e.g. the additions of MD5 and zlib.</div>
<div><br></div><div>Maybe if the "supporting facilities" is a helper function it can be done inline, but for anything larger (i.e. it's its own independent functionality) it's usually best to split out an incremental patch that can get a focused review.</div>
<div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I think this is ready to go once we hear from the developers that there's a commitment to supporting the new scheduler.<br></blockquote><div><br></div></div><div>This definitely needs more discussion. Please hold back.</div>
<span class=""><font color="#888888">
<div><br></div><div>-- Sean Silva<br></div></font></span><div><div class="h5"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Alp.<br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
-- Sean Silva<div><div><br>
<br>
<br>
On Thu, Jan 23, 2014 at 6:08 PM, Julian Lettner <<a href="mailto:julian.lettner@gmail.com" target="_blank">julian.lettner@gmail.com</a> <mailto:<a href="mailto:julian.lettner@gmail.com" target="_blank">julian.lettner@gmail.<u></u>com</a>>> wrote:<br>
<br>
Move patch forward to ToT.<br>
<br>
Hi rinon, ahomescu,<br>
<br>
<a href="http://llvm-reviews.chandlerc.com/D1802" target="_blank">http://llvm-reviews.chandlerc.<u></u>com/D1802</a><br>
<br>
CHANGE SINCE LAST DIFF<br>
<a href="http://llvm-reviews.chandlerc.com/D1802?vs=6581&id=6621#toc" target="_blank">http://llvm-reviews.chandlerc.<u></u>com/D1802?vs=6581&id=6621#toc</a><br>
<br>
Files:<br>
include/llvm/CodeGen/<u></u>CommandFlags.h<br>
include/llvm/MC/<u></u>MCRegisterInfo.h<br>
include/llvm/Support/<u></u>RandomNumberGenerator.h<br>
include/llvm/Target/<u></u>TargetOptions.h<br>
lib/CodeGen/LLVMBuild.txt<br>
lib/CodeGen/SelectionDAG/<u></u>ScheduleDAGRRList.cpp<br>
lib/LTO/LTOCodeGenerator.cpp<br>
lib/LTO/LTOModule.cpp<br>
lib/Support/CMakeLists.txt<br>
lib/Support/<u></u>RandomNumberGenerator.cpp<br>
lib/Target/X86/CMakeLists.txt<br>
lib/Target/X86/NOPInsertion.<u></u>cpp<br>
lib/Target/X86/X86.h<br>
lib/Target/X86/<u></u>X86TargetMachine.cpp<br>
test/CodeGen/X86/nop-insert-<u></u>percentage.ll<br>
test/CodeGen/X86/nop-insert.ll<br>
test/CodeGen/X86/sched-rnd-<u></u>test.ll<br>
tools/llc/llc.cpp<br>
tools/llvm-lto/llvm-lto.cpp<br>
tools/lto/lto.cpp<br>
tools/opt/opt.cpp<br>
<br>
______________________________<u></u>_________________<br>
llvm-commits mailing list<br></div></div>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a> <mailto:<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.<u></u>edu</a>><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvm-commits</a><div><br>
<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/<u></u>mailman/listinfo/llvm-commits</a><br>
</div></blockquote>
<br><div><div>
-- <br>
<a href="http://www.nuanti.com" target="_blank">http://www.nuanti.com</a><br>
the browser experts<br>
<br>
</div></div></blockquote></div></div></div><br></div></div>
</blockquote></div><br></div></div></div>