[LLVMdev] Adding diversity for security (and testing)

[Nick Kledzik]

On Aug 29, 2013, at 3:29 PM, Stephen Crane <sjcrane at uci.edu> wrote:
> On 08/28/2013 02:37 PM, Nick Lewycky wrote:
>> 1. I'm concerned about the deployment problem. I realize that being in the compiler means you can transform the program in more exciting ways, but it gives you a much worse deployment story than something which modifies the program on disk like "prelink".
> 
> Yes, definitely. Deployment is an issue which users will need to consider when deciding whether to use compiler-based diversity. However there are certainly use-cases which could benefit, especially in small deployments. Additionally, the benefits may outweigh the increase in deployment costs for larger deployments.

I also find the prelink approach interesting, particularly if the OS is already doing prelinking.   The idea is that the compiler always generates one binary, but it makes a record of permutation that could be made at prelink time.  For instance, register r5 is restored in the epilog, but  it is only used in three other instructions, so prelinking could switch them all to use r6.  Or here is how to slide a block of code within a function.  The end result of these recorded potential randomizations is to alter the ROP gadget.  

This would allow you to generate one golden binary and release it, then on each machine where it is installed, the prelinking would apply some random permutations to the code.  You get your diversity across machines, but only need to ship one binary.

-Nick