[PATCH] Adding diversity for security
Sean Silva
silvas at purdue.edu
Thu Jan 23 19:49:47 PST 2014
On Thu, Jan 23, 2014 at 10:07 PM, Alp Toker <alp at nuanti.com> wrote:
>
> 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.
>
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 <
http://www.darpa.mil/Our_Work/I2O/Programs/Clean-slate_design_of_Resilient_Adaptive_Secure_Hosts_(CRASH).aspx>
and <
http://www.darpa.mil/Our_Work/I2O/Programs/Mission-oriented_Resilient_Clouds_(MRC).aspx>
which have no connection with copy protection.
> 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.
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?
>
> 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.
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.
>
>
> 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.
Maybe such a feature doesn't belong in an open-source project then ;)
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
code-reuse attacks such as return-oriented-programming (ROP) by
denying the attacker information about the exact code layout."
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?
>
>
>
>
>> 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.
>
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.
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.
> I think this is ready to go once we hear from the developers that there's
> a commitment to supporting the new scheduler.
>
This definitely needs more discussion. Please hold back.
-- Sean Silva
>
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140123/f66343ca/attachment.html>
More information about the llvm-commits
mailing list