summaryrefslogtreecommitdiff
path: root/crypto/gcm.c
diff options
context:
space:
mode:
authorWill Deacon <will@kernel.org>2020-07-09 21:48:41 +0100
committerWill Deacon <will@kernel.org>2020-07-13 14:08:07 +0100
commit7c116db24d944ff04a67c8bd89cb32c5cd0894ff (patch)
tree901caa2cc1ab9b3144e3a31e36e3a3d812c45f56 /crypto/gcm.c
parent5679b28142193a62f6af93249c0477be9f0c669b (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