[PATCH] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely

[PATCH] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely

[Ard Biesheuvel]

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(-)

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)
-- 
2.17.1


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely

[Will Deacon]

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely

[Ard Biesheuvel]

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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely

[Will Deacon]

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely

[Will Deacon]

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely

[Will Deacon]

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,
-- 
Will

https://fixes.arm64.dev
https://next.arm64.dev

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely

[Marc Zyngier]

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.
-- 
Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely

[Will Deacon]

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

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely

[Marc Zyngier]

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
-- 
Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely

[Ard Biesheuvel]

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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely

[Ard Biesheuvel]

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)

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely

[Marc Zyngier]

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.
-- 
Jazz is not dead. It just smells funny...

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely

[Jonathan Marek]

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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely

[Ard Biesheuvel]

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?

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely

[Jonathan Marek]

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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely

[Mark Rutland]

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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely

[Ard Biesheuvel]

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.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel