Re: [PATCH 2/2] arm64: efi: kaslr: Fix boot failure if efi_random_alloc() fails

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

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.

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.

Note (in case this is relevant): This was all tested/debugged on 5.10.y

Cheers,
Ben.