diff options
author | Ard Biesheuvel <ardb@kernel.org> | 2023-09-12 12:00:53 +0300 |
---|---|---|
committer | Ingo Molnar <mingo@kernel.org> | 2023-09-15 12:18:40 +0300 |
commit | 7e50262229faad0c7b8c54477cd1c883f31cc4a7 (patch) | |
tree | b1fe6483c207c8cc40412a0788a0d788fe6df246 /arch/x86/boot/header.S | |
parent | 5f51c5d0e905608ba7be126737f7c84a793ae1aa (diff) | |
download | linux-7e50262229faad0c7b8c54477cd1c883f31cc4a7.tar.xz |
x86/efi: Disregard setup header of loaded image
The native EFI entrypoint does not take a struct boot_params from the
loader, but instead, it constructs one from scratch, using the setup
header data placed at the start of the image.
This setup header is placed in a way that permits legacy loaders to
manipulate the contents (i.e., to pass the kernel command line or the
address and size of an initial ramdisk), but EFI boot does not use it in
that way - it only copies the contents that were placed there at build
time, but EFI loaders will not (and should not) manipulate the setup
header to configure the boot. (Commit 63bf28ceb3ebbe76 "efi: x86: Wipe
setup_data on pure EFI boot" deals with some of the fallout of using
setup_data in a way that breaks EFI boot.)
Given that none of the non-zero values that are copied from the setup
header into the EFI stub's struct boot_params are relevant to the boot
now that the EFI stub no longer enters via the legacy decompressor, the
copy can be omitted altogether.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Link: https://lore.kernel.org/r/20230912090051.4014114-19-ardb@google.com
Diffstat (limited to 'arch/x86/boot/header.S')
0 files changed, 0 insertions, 0 deletions