On Thu, Feb 26, 2015 at 4:11 PM, Kees Cook <keescook@xxxxxxxxxxxx> wrote: > On Thu, Feb 26, 2015 at 4:06 PM, Andrew Morton > <akpm@xxxxxxxxxxxxxxxxxxxx> wrote: >> On Thu, 26 Feb 2015 15:37:37 -0800 Kees Cook <keescook@xxxxxxxxxxxx> wrote: >> >>> Agh, no, please let's avoid the CONFIG addition. >> >> That is precisely how we do this. >> >>> Hector mentioned in private mail that he was looking at an alternative >>> that adds exec_base to struct mm which would avoid all this insanity. >>> >>> Can't we do something like: >>> >>> #ifndef mmap_rnd >>> # define mmap_rnd 0 >>> #endif >> >> Sure, and sprinkle >> >> #define mmap_rnd mmap_rnd >> >> in five arch header files where nobody thinks to look. >> >> For better or for worse, we are consolidating such things into arch/*/Kconfig. > > Okay, fair enough. Even with your configs (though shouldn't they be > ARCH_HAS or just HAVE?) I've now stumbled over the issue that we can't > put randomize_et_dyn in binfmt_elf because it conflicts with linking > against compat_binfmt_elf. Instead of all this, how about we rework the existing CONFIG and just change around how s390 does this to match the other architectures and remove the ifdef in binfmt_elf.c at the same time? Let me work something up... -Kees -- Kees Cook Chrome OS Security