<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 23, 2014 at 9:20 PM, Per Larsen <span dir="ltr"><<a href="mailto:per.larsen@gmail.com" target="_blank">per.larsen@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>just want to add a few points to my colleague stephen's response to sean silva who brought up some good points.</div>
<div><br></div>there was a discussion of the relative merits of software diversity and control-flow integrity (cfi). just as we are advocating diversity, some folks are advocating that cfi is the better way to thwart arbitrary code execution attacks. the bottom line is that both of these two security technologies are powerful and each with a distinct set of tradeoffs and there are situations where one is clearly more appropriate than the other. this might give the impression that there is no clear consensus that diversity is a good addition to the security toolbox. all evidence points to the contrary. the top security conferences have all published work on security. furthermore, our patch for llvm was developed as part of research funded by two darpa programs–crash and mrc–which includes an extensive red team evaluation by a large team of researchers from mit. the current consensus is that this patch provides substantially better protection against code reuse attacks than the currently deployed defenses and remains compatible with virtually all existing code.<div>
<div><br></div><div>our funding runs through 2015 which means that we can definitely commit to maintain this for the next two years and possibly beyond that.</div></div></div></blockquote><div><br></div><div>Hi, to clarify my concern, maintenance is about more than "our funding runs through 2015". It's about building community trust and showing an understanding of LLVM development practices along with a commitment to the LLVM codebase, not just your corner of it.</div>
<div><br></div><div>Consider this scenario: this patch gets committed, but one of our buildbots breaks. Who is going to identify the errant commit and revert the patch? Who is going to dig into the issue and fix it? If your team hasn't integrated itself into the community enough to understand and handle these issues in tandem with the community, then that means that someone is going to be taking time off of their work to handle it for you.</div>
<div><br></div><div>For integrating into the community, there is no substitute for sending patches (start small) and getting them committed; it shouldn't take more than a handful of quality patches to learn the ropes and show that you are serious.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><br></div><div>i hope this helps clarify the merits of this patch.</div></div>
</div></div></blockquote><div><br></div><div>To clarify: I'm not qualified to discuss the merits of this patch from a security-researcher perspective; for all I care it could be a theoretically optimal approach. What I'm more concerned about is "who needs this?", "will they use it?", "does this fit into their deployment model?", "does this fit cleanly with our software architecture?", etc. I've seen some hints at answers to these questions (and I'm not saying that I know the answers either!), but they really do need to be addressed in order to dislodge the null hypothesis.</div>
<div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><span class="HOEnZb"><font color="#888888">
<div>per<br><div><div><br></div></div></div></font></span></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 23, 2014 at 5:44 PM, Stephen Crane <span dir="ltr"><<a href="mailto:sjcrane@uci.edu" target="_blank">sjcrane@uci.edu</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>I can't really speak to the first two points besides suggesting that we have working code ready to go for a useful tool to add to users' security toolbox. However, this does lead to your third point... We've had off-list discussions with several different people who are interested in using this, assuming it fits their needs after testing, including Google and OpenBSD. As for me, I'm certainly still on board with the work (and maintenance). Julian, a collaborator of mine at UC Irvine, is also helping put the finishing touches on the patch, and Andrei is also involved as needed since he wrote a good deal of the code for this.<br>
<br></div><div>Perhaps an email to the llvmdev list resurrecting the original thread would be a good idea, since people were interested in seeing actual code. I'll go ahead and do that so perhaps we can get more input.<br>
</div>
<div>
<br></div>I agree, splitting the RNG would be a good idea.<span><font color="#888888"><br><br></font></span></div><span><font color="#888888">- stephen<br></font></span></div><div>
<div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 23, 2014 at 5:08 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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:<div>
<br><div>- 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>
</div><div><div>- 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.</div>
</div><div>- No concrete use cases. 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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Also, at the very least, adding the RNG should be split out into a separate patch.</div><span><font color="#888888"><div><br></div><div>-- Sean Silva</div></font></span></div></div><div class="gmail_extra">
<br><br><div class="gmail_quote"><div><div>On Thu, Jan 23, 2014 at 6:08 PM, Julian Lettner <span dir="ltr"><<a href="mailto:julian.lettner@gmail.com" target="_blank">julian.lettner@gmail.com</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div> 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.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.com/D1802?vs=6581&id=6621#toc</a><br>
<div><br>
Files:<br>
include/llvm/CodeGen/CommandFlags.h<br>
include/llvm/MC/MCRegisterInfo.h<br>
include/llvm/Support/RandomNumberGenerator.h<br>
include/llvm/Target/TargetOptions.h<br>
lib/CodeGen/LLVMBuild.txt<br>
</div><div> lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp<br>
lib/LTO/LTOCodeGenerator.cpp<br>
lib/LTO/LTOModule.cpp<br>
lib/Support/CMakeLists.txt<br>
lib/Support/RandomNumberGenerator.cpp<br>
lib/Target/X86/CMakeLists.txt<br>
lib/Target/X86/NOPInsertion.cpp<br>
lib/Target/X86/X86.h<br>
lib/Target/X86/X86TargetMachine.cpp<br>
test/CodeGen/X86/nop-insert-percentage.ll<br>
test/CodeGen/X86/nop-insert.ll<br>
test/CodeGen/X86/sched-rnd-test.ll<br>
</div> tools/llc/llc.cpp<br>
tools/llvm-lto/llvm-lto.cpp<br>
tools/lto/lto.cpp<br>
tools/opt/opt.cpp<br>
<br></div></div><div>_______________________________________________<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/mailman/listinfo/llvm-commits</a><br>
<br></div></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>