On Fri, 27 Mar 2020 at 14:19, Jonathan Cameron <Jonathan.Cameron@xxxxxxxxxx> wrote: > > On Thu, 26 Mar 2020 17:59:03 +0100 > Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > Update the relocation logic in the EFI stub for arm64 so it runs the > > kernel in place if it was loaded by firmware at an address which allows > > doing so. Then, update the PE/COFF header metadata and increase the > > section alignment to force the UEFI image loader to honour the minimal > > alignment requirement imposed by the kernel proper. > > > > Ard Biesheuvel (2): > > efi/libstub/arm64: avoid copying the kernel unnecessarily > > efi/arm64: increase the PE/COFF alignment so the kernel can run in > > place > > > > arch/arm64/kernel/efi-header.S | 2 +- > > arch/arm64/kernel/image-vars.h | 7 +++++++ > > drivers/firmware/efi/libstub/arm64-stub.c | 9 +++++++++ > > 3 files changed, 17 insertions(+), 1 deletion(-) > > > Hi Ard. > > Seems sensible to me so I decided to give it a quick test. > As things stand RELOCATABLE is only selectable by selecting > RANDOMIZE_BASE. Probably want to be able to configure it > separately (needs some help text, or a specific option to > select CONFIG_RELOCATABLE). > The idea is really that KASLR kernels that were booted without a seed (or with 'nokaslr' on the command line) take this path. But in fact, I realized that the same logic applies to non-relocatable kernels, just with an alignment of 2 MB rather than 64 KB or 128 KB. So I will be sending a v2 that looks slightly different. (Another thing that I realized is that /if/ the KASLR path fails for any reason, we could still take this path instead of doing the allocation) > Otherwise, superficially seems to work good for me doing a > boot via pxe/grub on a Kunpeng 920 with some prints added to > make sure it's taking the right paths. > Excellent! Thanks for testing, and I will be cc'ing you on v2.
