[PATCH] Adding diversity for security

[Stephen Crane]

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.

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.

I agree, splitting the RNG would be a good idea.

- stephen


On Thu, Jan 23, 2014 at 5:08 PM, Sean Silva <silvas at purdue.edu> 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.
>
> 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>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
>>
>> 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
>> 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/20140123/23165f05/attachment.html>