Hi Nick, On Wed, Jun 19, 2019 at 05:32:42PM -0700, Nick Desaulniers wrote: > Generated via: > $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make defconfig > $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make menuconfig > <enable CONFIG_RANDOMIZE_BASE aka KASLR> > $ ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- make savedefconfig > $ mv defconfig arch/arm64/configs/defconfig
Hmm, I'm in two minds about whether we want this on by default. On the plus side, it gets us extra testing coverage, although the /vast/ majority of firmware implementations I run into either don't pass a seed or don't provide a working EFI_RNG. Perhaps that's just a chicken-and-egg problem which can be solved if we shout loud enough when we fail to randomize; we'll also eventually be in a better position when CPUs start implementing the v8.5 RNG instructions (but don't hold your breath unless you have an unusually high lung capacity). On the flip side, I worry that it could make debugging more difficult, but I don't know whether that's a genuine concern or not. I'm assuming you've debugged your fair share of crashes from KASLR-enabled kernels; how bad is it? (I'm thinking of the case where somebody mails you part of a panic log and a .config). Irrespective of the above, I know Catalin was running into issues with his automated tests where the kernel would die silently during early boot with some seeds. That's a bit rubbish if it's still the case -- Catalin? Finally, I know that (K)ASLR can be a bit controversial amongst security folks, with some seeing it as purely a smoke-and-mirrors game with no tangible benefits other than making us feel better about ourselves. Is it still the case that it can be trivially bypassed, or do you see it actually preventing some attacks in production? Sorry for the barrage of questions, but I think enabling this one by default is quite a significant thing to do and probably deserves a bit of scrutiny beforehand. Cheers, Will
