[PATCH] Adding diversity for security

[Stephen Crane]

First, we expect that an entire build would use a single random seed for a determinism in case debugging is needed later. Therefore, there may be the possibility of leakage of some but not all files from the same build, which would then leak the seed and therefore the layout of all binaries from the same build. We also are trying to prevent small, limited leakage to a remote attacker (for example leakage of a few pointers) from compromising the seed and therefore the rest of the binary layout. While this would admittedly be difficult, we were thinking we want to be sure that compromise of the layout is limited to leakage of the entire binary.

Of course, ultimately the decision should still be up to the user (or packager) regarding whether they wish to compile against OpenSSL.

Thanks,
- stephen

On Oct 15, 2013, at 13:51 , Nadav Rotem <nrotem at apple.com> wrote:
> Hi Stephen, 
> 
> Thanks for submitting the patch.  I have a few questions.  It is not clear to me why you need cryptographically strong randomization at *compile* time.  You absolutely do need this kind of randomization when distributing the binary, not when compiling it.  To the best of my understanding in order to predict a safe jump location you need to read the binary data anyway, so using a strong crypto is not better than any pseudo random number generator.  
> 
> Thanks,
> Nadav