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

From: Will Deacon <will@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	james.morse@arm.com,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	suzuki.poulose@arm.com
Subject: Re: [PATCH] arm64: set TEXT_OFFSET to 0x0 in preparation for removing it entirely
Date: Wed, 15 Apr 2020 10:15:48 +0100	[thread overview]
Message-ID: <20200415091548.GB12621@willie-the-truck> (raw)
In-Reply-To: <CAMj1kXFLte7R2zXRLRBxetS1WTYaGTonOC0nvyzK+be8EsfDrA@mail.gmail.com>

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