On Tue, 20 Jul 2021 at 16:25, Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, 2021-07-20 at 16:10 +0200, Ard Biesheuvel wrote: > > > > > My patch simply ensures that this is also true when KASLR fails to > > > randomize the kernel address. > > > > > > > Fair enough. > > > > The history here is that passing nokaslr on the command line would > > force 2M alignment even if KASLR was not enabled to begin with, > > without affecting the alignment policy of KASLR capable kernels if > > KASLR was not explicitly disabled, but not available on the platform. > > > > I realize now that my commit d32de9130f6c7 has interfered with this: > > efi_nokaslr is set to true there so the later code does not complain > > about the EFI_RNG_PROTOCOL being unavailable, but it has the side > > effect of affecting the alignment policy in the remainder of the > > function. > > > > So what I would prefer here is to capture efi_nokaslr at entry, and > > use that to decide the alignment. That way, efi_nokaslr can be set to > > true without affecting the subsequent allocation logic. > > So interestingly, the bug I am trying to fix with this patch seems to > indicate that this doesn't work (though I would need to debug further > as to why) on my systems (EC2 c6g.metal instances). > > IE, in my case what happens is: > > - kernel has CONFIG_RANDOMIZE_BASE and CONFIG_RELOCATABLE both enabled > - RNG protocol exists, it gets a random seed, but due to the other > bug, efi_random_alloc() fails. It thus falls back to the "normal" > alignment check & relocation case (the big if (status != EFI_SUCCESS)) > - That alignment check uses 64K and not 2M however. In my case it > passes (_text is already 64K aligned) and we boot... > - And nothing happens. IE, it dies somewhere in/after exit boot > services, I haven't had a chance to figure out in more details why, > those machines take 20mn to reboot. > > So *something* is wrong when we stick to a 64K alignment and don't > randomize the kernel base. > Interesting. Could this be related to caching? If EFI loads Image and it remains in place, we boot the image that we are executing from, and if your ExitBootServices() implementation plays tricks with [non-architected] caches, this could cause problems, I suppose. Just guessing ... > Interestingly we don't set nokaslr in that case, so we should still be > hitting all the kaslr path in the main kernel. The problem could relate > to running from that initial address. I'll have to debug further, maybe > try a repro-case in qemu. > > In the meantime, please apply patch 1 which solves the main issue and > I'll continue digging. > OK > Note (in case this is relevant): This was all tested/debugged on 5.10.y > > Cheers, > Ben. > >
