diff options
author | Will Deacon <will@kernel.org> | 2020-07-09 21:48:41 +0100 |
---|---|---|
committer | Will Deacon <will@kernel.org> | 2020-07-13 14:08:07 +0100 |
commit | 7c116db24d944ff04a67c8bd89cb32c5cd0894ff (patch) | |
tree | 901caa2cc1ab9b3144e3a31e36e3a3d812c45f56 /crypto/gcm.c | |
parent | 5679b28142193a62f6af93249c0477be9f0c669b (diff) |
efi/libstub/arm64: Retain 2MB kernel Image alignment if !KASLR
Since commit 82046702e288 ("efi/libstub/arm64: Replace 'preferred' offset
with alignment check"), loading a relocatable arm64 kernel at a physical
address which is not 2MB aligned and subsequently booting with EFI will
leave the Image in-place, relying on the kernel to relocate itself early
during boot. In conjunction with commit dd4bc6076587 ("arm64: warn on
incorrect placement of the kernel by the bootloader"), which enables
CONFIG_RELOCATABLE by default, this effectively means that entering an
arm64 kernel loaded at an alignment smaller than 2MB with EFI (e.g. using
QEMU) will result in silent relocation at runtime.
Unfortunately, this has a subtle but confusing affect for developers
trying to inspect the PC value during a crash and comparing it to the
symbol addresses in vmlinux using tools such as 'nm' or 'addr2line';
all text addresses will be displaced by a sub-2MB offset, resulting in
the wrong symbol being identified in many cases. Passing "nokaslr" on
the command line or disabling "CONFIG_RANDOMIZE_BASE" does not help,
since the EFI stub only copies the kernel Image to a 2MB boundary if it
is not relocatable.
Adjust the EFI stub for arm64 so that the minimum Image alignment is 2MB
unless KASLR is in use.
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: David Brazdil <dbrazdil@google.com>
Acked-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Will Deacon <will@kernel.org>
Diffstat (limited to 'crypto/gcm.c')
0 files changed, 0 insertions, 0 deletions