| Message ID | 20200326165905.2240-1-ardb@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | efi/arm64: execute the kernel in place if possible | expand |
On Thu, 26 Mar 2020 17:59:03 +0100 Ard Biesheuvel <ardb@kernel.org> 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). 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. Thanks, Jonathan
On Fri, 27 Mar 2020 at 14:19, Jonathan Cameron <Jonathan.Cameron@huawei.com> wrote: > > On Thu, 26 Mar 2020 17:59:03 +0100 > Ard Biesheuvel <ardb@kernel.org> 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.
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(-)