| Message ID | 20200415082922.32709-1-ardb@kernel.org (mailing list archive) |
|---|---|
| State | Mainlined |
| Commit | cfa7ede20f133cc81cef01dc3a516dda3a9721ee |
| Headers | show |
| Series | arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely | expand |
On Wed, Apr 15, 2020 at 10:29:22AM +0200, Ard Biesheuvel wrote: > TEXT_OFFSET on arm64 is a historical artifact from the early days of > the arm64 port where the boot protocol was basically 'copy this image > to the base of memory + 512k', giving us 512 KB of guaranteed BSS space > to put the swapper page tables. When the arm64 port was merged for > v3.10, the Image header already carried the actual value of TEXT_OFFSET, > to allow the bootloader to discover it dynamically rather than hardcode > it to 512 KB. Hey, we're older than that! (3.7) > Today, this memory window is not used for any particular purpose, and > it is simply handed to the page allocator at boot. The only reason it > still exists is because of the 512k misalignment it causes with respect > to the 2 MB aligned virtual base address of the kernel, which affects > the virtual addresses of all statically allocated objects in the kernel > image. > > However, with the introduction of KASLR in v4.6, we added the concept of > relocatable kernels, which rewrite all absolute symbol references at > boot anyway, and so the placement of such kernels in the physical address > space is irrelevant, provided that the minimum segment alignment is > honoured (64 KB in most cases, 128 KB for 64k pages kernels with vmap'ed > stacks enabled). This makes 0x0 and 512 KB equally suitable values for > TEXT_OFFSET on the off chance that we are dealing with boot loaders that > ignore the value passed via the header entirely. > > Considering that the distros as well as Android ship KASLR-capable > kernels today, and the fact that TEXT_OFFSET was discoverable from the > Image header from the very beginning, let's change this value to 0x0, in > preparation for removing it entirely at a later date. Can we kill CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET at the same time please? It seems less useful now than ever and it would move us closer to removing the TEXT_OFFSET definition entirely (but maybe we should wait a couple of cycles before doing that... what do you reckon?). Cheers, Will
On Wed, 15 Apr 2020 at 10:39, Will Deacon <will@kernel.org> wrote: > > On Wed, Apr 15, 2020 at 10:29:22AM +0200, Ard Biesheuvel wrote: > > TEXT_OFFSET on arm64 is a historical artifact from the early days of > > the arm64 port where the boot protocol was basically 'copy this image > > to the base of memory + 512k', giving us 512 KB of guaranteed BSS space > > to put the swapper page tables. When the arm64 port was merged for > > v3.10, the Image header already carried the actual value of TEXT_OFFSET, > > to allow the bootloader to discover it dynamically rather than hardcode > > it to 512 KB. > > Hey, we're older than that! (3.7) > Ah right. But the header field was added in v3.10 - I'll fix that in v2. All way before my time anyway :-) > > Today, this memory window is not used for any particular purpose, and > > it is simply handed to the page allocator at boot. The only reason it > > still exists is because of the 512k misalignment it causes with respect > > to the 2 MB aligned virtual base address of the kernel, which affects > > the virtual addresses of all statically allocated objects in the kernel > > image. > > > > However, with the introduction of KASLR in v4.6, we added the concept of > > relocatable kernels, which rewrite all absolute symbol references at > > boot anyway, and so the placement of such kernels in the physical address > > space is irrelevant, provided that the minimum segment alignment is > > honoured (64 KB in most cases, 128 KB for 64k pages kernels with vmap'ed > > stacks enabled). This makes 0x0 and 512 KB equally suitable values for > > TEXT_OFFSET on the off chance that we are dealing with boot loaders that > > ignore the value passed via the header entirely. > > > > Considering that the distros as well as Android ship KASLR-capable > > kernels today, and the fact that TEXT_OFFSET was discoverable from the > > Image header from the very beginning, let's change this value to 0x0, in > > preparation for removing it entirely at a later date. > > Can we kill CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET at the same time please? > It seems less useful now than ever and it would move us closer to removing > the TEXT_OFFSET definition entirely (but maybe we should wait a couple of > cycles before doing that... what do you reckon?). > The idea was to start with this patch, which can be reverted very easily if it causes any issues. Then, once we're confident that it is safe, we just rip it all out in one go. In the mean time, if we do find issues with other projects, CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET may be useful for validation, and it is off by default anyway.
On Wed, Apr 15, 2020 at 10:48:55AM +0200, Ard Biesheuvel wrote: > On Wed, 15 Apr 2020 at 10:39, Will Deacon <will@kernel.org> wrote: > > > > On Wed, Apr 15, 2020 at 10:29:22AM +0200, Ard Biesheuvel wrote: > > > TEXT_OFFSET on arm64 is a historical artifact from the early days of > > > the arm64 port where the boot protocol was basically 'copy this image > > > to the base of memory + 512k', giving us 512 KB of guaranteed BSS space > > > to put the swapper page tables. When the arm64 port was merged for > > > v3.10, the Image header already carried the actual value of TEXT_OFFSET, > > > to allow the bootloader to discover it dynamically rather than hardcode > > > it to 512 KB. > > > > Hey, we're older than that! (3.7) > > > > Ah right. But the header field was added in v3.10 - I'll fix that in > v2. All way before my time anyway :-) Hopefully nobody's running a 3.{7,8,9} kernel... (I wonder if it even boots?) > > > Today, this memory window is not used for any particular purpose, and > > > it is simply handed to the page allocator at boot. The only reason it > > > still exists is because of the 512k misalignment it causes with respect > > > to the 2 MB aligned virtual base address of the kernel, which affects > > > the virtual addresses of all statically allocated objects in the kernel > > > image. > > > > > > However, with the introduction of KASLR in v4.6, we added the concept of > > > relocatable kernels, which rewrite all absolute symbol references at > > > boot anyway, and so the placement of such kernels in the physical address > > > space is irrelevant, provided that the minimum segment alignment is > > > honoured (64 KB in most cases, 128 KB for 64k pages kernels with vmap'ed > > > stacks enabled). This makes 0x0 and 512 KB equally suitable values for > > > TEXT_OFFSET on the off chance that we are dealing with boot loaders that > > > ignore the value passed via the header entirely. > > > > > > Considering that the distros as well as Android ship KASLR-capable > > > kernels today, and the fact that TEXT_OFFSET was discoverable from the > > > Image header from the very beginning, let's change this value to 0x0, in > > > preparation for removing it entirely at a later date. > > > > Can we kill CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET at the same time please? > > It seems less useful now than ever and it would move us closer to removing > > the TEXT_OFFSET definition entirely (but maybe we should wait a couple of > > cycles before doing that... what do you reckon?). > > > > The idea was to start with this patch, which can be reverted very > easily if it causes any issues. Then, once we're confident that it is > safe, we just rip it all out in one go. Okey doke. > In the mean time, if we do find issues with other projects, > CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET may be useful for validation, and > it is off by default anyway. Works for me. Fingers crossed for no issues. Will
On Wed, Apr 15, 2020 at 10:48:55AM +0200, Ard Biesheuvel wrote: > On Wed, 15 Apr 2020 at 10:39, Will Deacon <will@kernel.org> wrote: > > > > On Wed, Apr 15, 2020 at 10:29:22AM +0200, Ard Biesheuvel wrote: > > > TEXT_OFFSET on arm64 is a historical artifact from the early days of > > > the arm64 port where the boot protocol was basically 'copy this image > > > to the base of memory + 512k', giving us 512 KB of guaranteed BSS space > > > to put the swapper page tables. When the arm64 port was merged for > > > v3.10, the Image header already carried the actual value of TEXT_OFFSET, > > > to allow the bootloader to discover it dynamically rather than hardcode > > > it to 512 KB. > > > > Hey, we're older than that! (3.7) > > > > Ah right. But the header field was added in v3.10 - I'll fix that in > v2. All way before my time anyway :-) Looks like that's the only change needed, so I'll just make it when I apply. Thanks, Will
On Wed, 15 Apr 2020 10:29:22 +0200, Ard Biesheuvel wrote: > TEXT_OFFSET on arm64 is a historical artifact from the early days of > the arm64 port where the boot protocol was basically 'copy this image > to the base of memory + 512k', giving us 512 KB of guaranteed BSS space > to put the swapper page tables. When the arm64 port was merged for > v3.10, the Image header already carried the actual value of TEXT_OFFSET, > to allow the bootloader to discover it dynamically rather than hardcode > it to 512 KB. > > [...] Applied to arm64 (for-next/misc), thanks! [1/1] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely https://git.kernel.org/arm64/c/cfa7ede20f13 Cheers,
Hi all, On Tue, 28 Apr 2020 15:49:35 +0100 Will Deacon <will@kernel.org> wrote: > On Wed, 15 Apr 2020 10:29:22 +0200, Ard Biesheuvel wrote: > > TEXT_OFFSET on arm64 is a historical artifact from the early days of > > the arm64 port where the boot protocol was basically 'copy this image > > to the base of memory + 512k', giving us 512 KB of guaranteed BSS space > > to put the swapper page tables. When the arm64 port was merged for > > v3.10, the Image header already carried the actual value of TEXT_OFFSET, > > to allow the bootloader to discover it dynamically rather than hardcode > > it to 512 KB. > > > > [...] > > Applied to arm64 (for-next/misc), thanks! > > [1/1] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely > https://git.kernel.org/arm64/c/cfa7ede20f13 This breaks a guest kernel booted with kvmtool (tested on my d05). Reverting it on top of 6929f71e46bd makes it work again. I haven't yet investigated what is happening here though. Thanks, M.
On Thu, Jun 04, 2020 at 03:41:41PM +0100, Marc Zyngier wrote: > Hi all, > > On Tue, 28 Apr 2020 15:49:35 +0100 > Will Deacon <will@kernel.org> wrote: > > > On Wed, 15 Apr 2020 10:29:22 +0200, Ard Biesheuvel wrote: > > > TEXT_OFFSET on arm64 is a historical artifact from the early days of > > > the arm64 port where the boot protocol was basically 'copy this image > > > to the base of memory + 512k', giving us 512 KB of guaranteed BSS space > > > to put the swapper page tables. When the arm64 port was merged for > > > v3.10, the Image header already carried the actual value of TEXT_OFFSET, > > > to allow the bootloader to discover it dynamically rather than hardcode > > > it to 512 KB. > > > > > > [...] > > > > Applied to arm64 (for-next/misc), thanks! > > > > [1/1] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely > > https://git.kernel.org/arm64/c/cfa7ede20f13 > > This breaks a guest kernel booted with kvmtool (tested on my d05). > Reverting it on top of 6929f71e46bd makes it work again. I haven't yet > investigated what is happening here though. Weird, that's a combination I test, just not on d05. Are you using defconfig? Can you share your full kvmtool invication please? Will
On 2020-06-04 16:01, Will Deacon wrote: > On Thu, Jun 04, 2020 at 03:41:41PM +0100, Marc Zyngier wrote: >> Hi all, >> >> On Tue, 28 Apr 2020 15:49:35 +0100 >> Will Deacon <will@kernel.org> wrote: >> >> > On Wed, 15 Apr 2020 10:29:22 +0200, Ard Biesheuvel wrote: >> > > TEXT_OFFSET on arm64 is a historical artifact from the early days of >> > > the arm64 port where the boot protocol was basically 'copy this image >> > > to the base of memory + 512k', giving us 512 KB of guaranteed BSS space >> > > to put the swapper page tables. When the arm64 port was merged for >> > > v3.10, the Image header already carried the actual value of TEXT_OFFSET, >> > > to allow the bootloader to discover it dynamically rather than hardcode >> > > it to 512 KB. >> > > >> > > [...] >> > >> > Applied to arm64 (for-next/misc), thanks! >> > >> > [1/1] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely >> > https://git.kernel.org/arm64/c/cfa7ede20f13 >> >> This breaks a guest kernel booted with kvmtool (tested on my d05). >> Reverting it on top of 6929f71e46bd makes it work again. I haven't yet >> investigated what is happening here though. > > Weird, that's a combination I test, just not on d05. Are you using > defconfig? Can you share your full kvmtool invication please? Ah, good point. Not defconfig, but one that allows me to run the same kernel on my whole zoo[1]. As for the kvmtool invocation, it is pretty basic: lkvm run -m 512 -c 4 -p earlycon -k arch/arm64/boot/Image Thanks, M. [1] http://www.loen.fr/tmp/Config-arm64-full
On Thu, 4 Jun 2020 at 17:25, Marc Zyngier <maz@kernel.org> wrote: > > On 2020-06-04 16:01, Will Deacon wrote: > > On Thu, Jun 04, 2020 at 03:41:41PM +0100, Marc Zyngier wrote: > >> Hi all, > >> > >> On Tue, 28 Apr 2020 15:49:35 +0100 > >> Will Deacon <will@kernel.org> wrote: > >> > >> > On Wed, 15 Apr 2020 10:29:22 +0200, Ard Biesheuvel wrote: > >> > > TEXT_OFFSET on arm64 is a historical artifact from the early days of > >> > > the arm64 port where the boot protocol was basically 'copy this image > >> > > to the base of memory + 512k', giving us 512 KB of guaranteed BSS space > >> > > to put the swapper page tables. When the arm64 port was merged for > >> > > v3.10, the Image header already carried the actual value of TEXT_OFFSET, > >> > > to allow the bootloader to discover it dynamically rather than hardcode > >> > > it to 512 KB. > >> > > > >> > > [...] > >> > > >> > Applied to arm64 (for-next/misc), thanks! > >> > > >> > [1/1] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely > >> > https://git.kernel.org/arm64/c/cfa7ede20f13 > >> > >> This breaks a guest kernel booted with kvmtool (tested on my d05). > >> Reverting it on top of 6929f71e46bd makes it work again. I haven't yet > >> investigated what is happening here though. > > > > Weird, that's a combination I test, just not on d05. Are you using > > defconfig? Can you share your full kvmtool invication please? > > Ah, good point. Not defconfig, but one that allows me to run the same > kernel on my whole zoo[1]. As for the kvmtool invocation, it is pretty > basic: > > lkvm run -m 512 -c 4 -p earlycon -k arch/arm64/boot/Image > OK, so my suspicions is that your config does not enable CONFIG_RANDOMIZE_BASE, and that kvmtool ignores the text offset value in the header altogether.
On Thu, 4 Jun 2020 at 17:41, Ard Biesheuvel <ardb@kernel.org> wrote: > > On Thu, 4 Jun 2020 at 17:25, Marc Zyngier <maz@kernel.org> wrote: > > > > On 2020-06-04 16:01, Will Deacon wrote: > > > On Thu, Jun 04, 2020 at 03:41:41PM +0100, Marc Zyngier wrote: > > >> Hi all, > > >> > > >> On Tue, 28 Apr 2020 15:49:35 +0100 > > >> Will Deacon <will@kernel.org> wrote: > > >> > > >> > On Wed, 15 Apr 2020 10:29:22 +0200, Ard Biesheuvel wrote: > > >> > > TEXT_OFFSET on arm64 is a historical artifact from the early days of > > >> > > the arm64 port where the boot protocol was basically 'copy this image > > >> > > to the base of memory + 512k', giving us 512 KB of guaranteed BSS space > > >> > > to put the swapper page tables. When the arm64 port was merged for > > >> > > v3.10, the Image header already carried the actual value of TEXT_OFFSET, > > >> > > to allow the bootloader to discover it dynamically rather than hardcode > > >> > > it to 512 KB. > > >> > > > > >> > > [...] > > >> > > > >> > Applied to arm64 (for-next/misc), thanks! > > >> > > > >> > [1/1] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely > > >> > https://git.kernel.org/arm64/c/cfa7ede20f13 > > >> > > >> This breaks a guest kernel booted with kvmtool (tested on my d05). > > >> Reverting it on top of 6929f71e46bd makes it work again. I haven't yet > > >> investigated what is happening here though. > > > > > > Weird, that's a combination I test, just not on d05. Are you using > > > defconfig? Can you share your full kvmtool invication please? > > > > Ah, good point. Not defconfig, but one that allows me to run the same > > kernel on my whole zoo[1]. As for the kvmtool invocation, it is pretty > > basic: > > > > lkvm run -m 512 -c 4 -p earlycon -k arch/arm64/boot/Image > > > > OK, so my suspicions is that your config does not enable > CONFIG_RANDOMIZE_BASE, and that kvmtool ignores the text offset value > in the header altogether. arm/aarch64/include/kvm/kvm-arch.h:#define ARM_KERN_OFFSET(kvm) ((kvm)->cfg.arch.aarch32_guest ? \ arm/aarch64/include/kvm/kvm-arch.h- 0x8000 : \ arm/aarch64/include/kvm/kvm-arch.h- 0x80000)
On 2020-06-04 16:48, Ard Biesheuvel wrote: > On Thu, 4 Jun 2020 at 17:41, Ard Biesheuvel <ardb@kernel.org> wrote: >> >> On Thu, 4 Jun 2020 at 17:25, Marc Zyngier <maz@kernel.org> wrote: >> > >> > On 2020-06-04 16:01, Will Deacon wrote: >> > > On Thu, Jun 04, 2020 at 03:41:41PM +0100, Marc Zyngier wrote: >> > >> Hi all, >> > >> >> > >> On Tue, 28 Apr 2020 15:49:35 +0100 >> > >> Will Deacon <will@kernel.org> wrote: >> > >> >> > >> > On Wed, 15 Apr 2020 10:29:22 +0200, Ard Biesheuvel wrote: >> > >> > > TEXT_OFFSET on arm64 is a historical artifact from the early days of >> > >> > > the arm64 port where the boot protocol was basically 'copy this image >> > >> > > to the base of memory + 512k', giving us 512 KB of guaranteed BSS space >> > >> > > to put the swapper page tables. When the arm64 port was merged for >> > >> > > v3.10, the Image header already carried the actual value of TEXT_OFFSET, >> > >> > > to allow the bootloader to discover it dynamically rather than hardcode >> > >> > > it to 512 KB. >> > >> > > >> > >> > > [...] >> > >> > >> > >> > Applied to arm64 (for-next/misc), thanks! >> > >> > >> > >> > [1/1] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely >> > >> > https://git.kernel.org/arm64/c/cfa7ede20f13 >> > >> >> > >> This breaks a guest kernel booted with kvmtool (tested on my d05). >> > >> Reverting it on top of 6929f71e46bd makes it work again. I haven't yet >> > >> investigated what is happening here though. >> > > >> > > Weird, that's a combination I test, just not on d05. Are you using >> > > defconfig? Can you share your full kvmtool invication please? >> > >> > Ah, good point. Not defconfig, but one that allows me to run the same >> > kernel on my whole zoo[1]. As for the kvmtool invocation, it is pretty >> > basic: >> > >> > lkvm run -m 512 -c 4 -p earlycon -k arch/arm64/boot/Image >> > >> >> OK, so my suspicions is that your config does not enable >> CONFIG_RANDOMIZE_BASE, and that kvmtool ignores the text offset value >> in the header altogether. > > arm/aarch64/include/kvm/kvm-arch.h:#define ARM_KERN_OFFSET(kvm) > ((kvm)->cfg.arch.aarch32_guest ? \ > arm/aarch64/include/kvm/kvm-arch.h- 0x8000 > : \ > arm/aarch64/include/kvm/kvm-arch.h- > 0x80000) Yeah, nice catch. I'll try and fix the sucker. Thanks, M.
Hi, Just want to add that this patch also broke booting my arm64 kernel (CONFIG_RANDOMIZE_BASE=n). This is on a recent qualcomm board.
On Tue, 9 Jun 2020 at 14:35, Jonathan Marek <jonathan@marek.ca> wrote: > > Hi, > > Just want to add that this patch also broke booting my arm64 kernel > (CONFIG_RANDOMIZE_BASE=n). This is on a recent qualcomm board. Which bootloader does it use? I take it reverting the patch and enabling CONFIG_RANDOMIZE_TEXT_OFFSET makes it fail as well?
On 6/9/20 8:37 AM, Ard Biesheuvel wrote: > On Tue, 9 Jun 2020 at 14:35, Jonathan Marek <jonathan@marek.ca> wrote: >> >> Hi, >> >> Just want to add that this patch also broke booting my arm64 kernel >> (CONFIG_RANDOMIZE_BASE=n). This is on a recent qualcomm board. > > Which bootloader does it use? > abl/edk2 (https://source.codeaurora.org/quic/la/abl/tianocore/edk2/tree/?h=LA.UM.8.12.r1-11700-sm8250.0) Just looking at it quickly (I am no bootloader expert), I think this may have something to do with it: https://source.codeaurora.org/quic/la/abl/tianocore/edk2/tree/QcomModulePkg/QcomModulePkg.dec?h=LA.UM.8.12.r1-11700-sm8250.0#n149 > I take it reverting the patch and enabling > CONFIG_RANDOMIZE_TEXT_OFFSET makes it fail as well? > Yes, CONFIG_RANDOMIZE_TEXT_OFFSET also makes it fail.
On Tue, Jun 09, 2020 at 08:52:42AM -0400, Jonathan Marek wrote: > On 6/9/20 8:37 AM, Ard Biesheuvel wrote: > > On Tue, 9 Jun 2020 at 14:35, Jonathan Marek <jonathan@marek.ca> wrote: > > > > > > Hi, > > > > > > Just want to add that this patch also broke booting my arm64 kernel > > > (CONFIG_RANDOMIZE_BASE=n). This is on a recent qualcomm board. > > > > Which bootloader does it use? > > abl/edk2 (https://source.codeaurora.org/quic/la/abl/tianocore/edk2/tree/?h=LA.UM.8.12.r1-11700-sm8250.0) > > Just looking at it quickly (I am no bootloader expert), I think this may > have something to do with it: https://source.codeaurora.org/quic/la/abl/tianocore/edk2/tree/QcomModulePkg/QcomModulePkg.dec?h=LA.UM.8.12.r1-11700-sm8250.0#n149 > For others following, the relevant lines are: | [PcdsFixedAtBuild.common] | # linuxloadercommon | gqcomtokenspaceguid.kernelloadaddress|0x00080000|uint32|0x00015000 ... which means this is using the dodgy built-in Linux loader rather than booting Linux as an EFI application. It's disappointing that's still being used. :( Mark.
On Wed, 10 Jun 2020 at 10:57, Mark Rutland <mark.rutland@arm.com> wrote: > > On Tue, Jun 09, 2020 at 08:52:42AM -0400, Jonathan Marek wrote: > > On 6/9/20 8:37 AM, Ard Biesheuvel wrote: > > > On Tue, 9 Jun 2020 at 14:35, Jonathan Marek <jonathan@marek.ca> wrote: > > > > > > > > Hi, > > > > > > > > Just want to add that this patch also broke booting my arm64 kernel > > > > (CONFIG_RANDOMIZE_BASE=n). This is on a recent qualcomm board. > > > > > > Which bootloader does it use? > > > > abl/edk2 (https://source.codeaurora.org/quic/la/abl/tianocore/edk2/tree/?h=LA.UM.8.12.r1-11700-sm8250.0) > > > > Just looking at it quickly (I am no bootloader expert), I think this may > > have something to do with it: https://source.codeaurora.org/quic/la/abl/tianocore/edk2/tree/QcomModulePkg/QcomModulePkg.dec?h=LA.UM.8.12.r1-11700-sm8250.0#n149 > > > > For others following, the relevant lines are: > > | [PcdsFixedAtBuild.common] > | # linuxloadercommon > | gqcomtokenspaceguid.kernelloadaddress|0x00080000|uint32|0x00015000 > > ... which means this is using the dodgy built-in Linux loader rather than > booting Linux as an EFI application. It's disappointing that's still being used. :( > Yeah. So one way we might deal with this is to make CONFIG_RELOCATABLE default to y (unless CONFIG_EXPERT?), independently of CONFIG_RANDOMIZE_BASE, so that even if you decide to disable KASLR, you still get the metadata you need to apply the relocations. This uses a bit more space, but I think it is a reasonable compromise between support for broken bootloaders such as this one, and having the ability to trim down your kernel if you want to.
diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile index 85e4149cc5d5..8e9445faa8ac 100644 --- a/arch/arm64/Makefile +++ b/arch/arm64/Makefile @@ -118,7 +118,7 @@ TEXT_OFFSET := $(shell awk "BEGIN {srand(); printf \"0x%06x\n\", \ int(2 * 1024 * 1024 / (2 ^ $(CONFIG_ARM64_PAGE_SHIFT)) * \ rand()) * (2 ^ $(CONFIG_ARM64_PAGE_SHIFT))}") else -TEXT_OFFSET := 0x00080000 +TEXT_OFFSET := 0x0 endif ifeq ($(CONFIG_KASAN_SW_TAGS), y)
TEXT_OFFSET on arm64 is a historical artifact from the early days of the arm64 port where the boot protocol was basically 'copy this image to the base of memory + 512k', giving us 512 KB of guaranteed BSS space to put the swapper page tables. When the arm64 port was merged for v3.10, the Image header already carried the actual value of TEXT_OFFSET, to allow the bootloader to discover it dynamically rather than hardcode it to 512 KB. Today, this memory window is not used for any particular purpose, and it is simply handed to the page allocator at boot. The only reason it still exists is because of the 512k misalignment it causes with respect to the 2 MB aligned virtual base address of the kernel, which affects the virtual addresses of all statically allocated objects in the kernel image. However, with the introduction of KASLR in v4.6, we added the concept of relocatable kernels, which rewrite all absolute symbol references at boot anyway, and so the placement of such kernels in the physical address space is irrelevant, provided that the minimum segment alignment is honoured (64 KB in most cases, 128 KB for 64k pages kernels with vmap'ed stacks enabled). This makes 0x0 and 512 KB equally suitable values for TEXT_OFFSET on the off chance that we are dealing with boot loaders that ignore the value passed via the header entirely. Considering that the distros as well as Android ship KASLR-capable kernels today, and the fact that TEXT_OFFSET was discoverable from the Image header from the very beginning, let's change this value to 0x0, in preparation for removing it entirely at a later date. Signed-off-by: Ard Biesheuvel <ardb@kernel.org> --- arch/arm64/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)