[PATCH] Adding diversity for security

[Sean Silva]

On Fri, Jan 24, 2014 at 4:16 AM, Nick Lewycky <nicholas at mxc.ca> wrote:

> Sean Silva wrote:
>
>> 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:
>>
>> - 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.
>> - 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.
>> - 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.
>>
>> 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.
>>
>
> It wasn't clear from the email thread, but Geremy Condra represents a
> customer of this patch who is also doing review, but from a security
> standpoint not from an llvm code review standpoint. As for concrete users,
> I'll simply say that his interest is not academic, and let him say more if
> he wants to.
>

Cool, this is exactly the sort of "feedback loop" of usage that I was
really interested in seeing. I think it would be really great for Geremy to
contribute to the evaluation of this code.

-- Sean Silva


>
> My own concerns about the level of security it provides are simply because
> I'm not trained in the area. For an analogy, I feel like I'm asking "why
> does RSA work? why doesn't somebody just figure out an algorithm for
> factoring large numbers efficiently? what makes you think that would be so
> hard?". It's a great line of questioning, but it requires a whole lot more
> explaining than belong on llvm-dev or a patch review thread.
>
> While we're here, I want to point out something fun:
>
> https://media.blackhat.com/us-13/US-13-Quynh-OptiROP-
> Hunting-for-ROP-Gadgets-in-Style-Slides.pdf
> That's a paper from a blackhat presentation on a system for creating ROP
> gadgets, which in turn is based on LLVM. Being the attackers, I don't think
> we ever got any patches from them. This patch under review adds protection
> from those ROP gadgets. We're now in the middle, "funding" code and
> infrastructure for both sides of the ROP exploit arms race. Whee!
>
> Nick
>
>  Also, at the very least, adding the RNG should be split out into a
>> separate patch.
>>
>> -- Sean Silva
>>
>>
>> On Thu, Jan 23, 2014 at 6:08 PM, Julian Lettner
>> <julian.lettner at gmail.com <mailto:julian.lettner at gmail.com>> wrote:
>>
>>        Move patch forward to ToT.
>>
>>     Hi rinon, ahomescu,
>>
>>     http://llvm-reviews.chandlerc.com/D1802
>>
>>     CHANGE SINCE LAST DIFF
>>     http://llvm-reviews.chandlerc.com/D1802?vs=6581&id=6621#toc
>>     <http://llvm-reviews.chandlerc.com/D1802?vs=6581&id=6621#toc>
>>
>>     Files:
>>        include/llvm/CodeGen/CommandFlags.h
>>        include/llvm/MC/MCRegisterInfo.h
>>        include/llvm/Support/RandomNumberGenerator.h
>>        include/llvm/Target/TargetOptions.h
>>        lib/CodeGen/LLVMBuild.txt
>>        lib/CodeGen/SelectionDAG/ScheduleDAGRRList.cpp
>>        lib/LTO/LTOCodeGenerator.cpp
>>        lib/LTO/LTOModule.cpp
>>        lib/Support/CMakeLists.txt
>>        lib/Support/RandomNumberGenerator.cpp
>>        lib/Target/X86/CMakeLists.txt
>>        lib/Target/X86/NOPInsertion.cpp
>>        lib/Target/X86/X86.h
>>        lib/Target/X86/X86TargetMachine.cpp
>>        test/CodeGen/X86/nop-insert-percentage.ll
>>        test/CodeGen/X86/nop-insert.ll
>>        test/CodeGen/X86/sched-rnd-test.ll
>>        tools/llc/llc.cpp
>>        tools/llvm-lto/llvm-lto.cpp
>>        tools/lto/lto.cpp
>>        tools/opt/opt.cpp
>>
>>     _______________________________________________
>>     llvm-commits mailing list
>>     llvm-commits at cs.uiuc.edu <mailto:llvm-commits at cs.uiuc.edu>
>>     http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>>
>>
>>
>>
>> _______________________________________________
>> llvm-commits mailing list
>> llvm-commits at cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140124/9c3c4c24/attachment.html>