On Thu, 2021-07-22 at 12:26 +0200, Ard Biesheuvel wrote:
> Commit 82046702e288 ("efi/libstub/arm64: Replace 'preferred' offset with
> alignment check") simplified the way the stub moves the kernel image
> around in memory before booting it, given that a relocatable image does
> not need to be copied to a 2M aligned offset if it was loaded on a 64k
> boundary by EFI.
>
> Commit d32de9130f6c ("efi/arm64: libstub: Deal gracefully with
> EFI_RNG_PROTOCOL failure") inadvertently defeated this logic by
> overriding the value of efi_nokaslr if EFI_RNG_PROTOCOL is not
> available, which was mistaked by the loader logic as an explicit request
> on the part of the user to disable KASLR and any associated relocation
> of an Image not loaded on a 2M boundary.
>
> So let's reinstate this functionality, by capturing the value of
> efi_nokaslr at function entry to choose the minimum alignment.
>
> Fixes: d32de9130f6c ("efi/arm64: libstub: Deal gracefully with EFI_RNG_PROTOCOL failure")
> Cc: Benjamin Herrenschmidt <benh@xxxxxxxxxxxxxxxxxxx>
> Signed-off-by: Ard Biesheuvel <ardb@xxxxxxxxxx>
> ---
> This fixes the regression that was discussed in [0], but given that it
> is very likely to break Ben's use case again, I'll sit on it for the
> time being.
The bug is in the version of grub carried by some distros actually. The
stricter alignment forces the stub to reallocate the image in ways that
manages to generally avoid it (but it's all luck). Long story short:
those grubs don't allocate room for the kernel bss (and don't zero it),
thus there's a chance for it to overlap other pre-boot allocations such
as EFI runtime services, the initrd, fdt, whatever else...
So the kernel will break more often with this patch until grub is fixed
in those distros (working on it ...).
Note: If you work on a distro and you carry the grub2 patch that takes
out LoadImage/StartImage from grub-core/loader/arm64/linux.c in favor
of the shim lock protocol, poke me, I have a patch for you :)
Cheers,
Ben.
