[PATCH] Adding diversity for security

Alp Toker alp at nuanti.com
Thu Jan 23 19:07:17 PST 2014


On 24/01/2014 01:08, 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.

It's a killer feature for anyone who has to support copy protection 
mechanisms in commercial software.

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.

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.

> 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.

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.


>
> 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.

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.

>
> Also, at the very least, adding the RNG should be split out into a 
> separate patch.

Why? We usually land supporting facilities together with the first use 
for ease of review and testing.

I think this is ready to go once we hear from the developers that 
there's a commitment to supporting the new scheduler.

Alp.


>
> -- 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
>
>     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

-- 
http://www.nuanti.com
the browser experts




More information about the llvm-commits mailing list