Received-SPF: pass (google.com: domain of linux-kernel+bounces-152273-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45d1:ec00::1 as permitted sender) client-ip=2604:1380:45d1:ec00::1;
Date: Sat, 20 Apr 2024 15:17:17 +0200
From: Borislav Petkov <bp@alien8.de>
To: Jiri Slaby <jirislaby@kernel.org>, Michael Matz <matz@suse.de>
Cc: Ard Biesheuvel <ardb+git@google.com>, linux-kernel@vger.kernel.org,
	x86@kernel.org, Ard Biesheuvel <ardb@kernel.org>,
	Nathan Chancellor <nathan@kernel.org>,
	Nick Desaulniers <ndesaulniers@google.com>,
	Bill Wendling <morbo@google.com>,
	Justin Stitt <justinstitt@google.com>, Song Liu <song@kernel.org>,
	Ricardo Ribalda <ribalda@kernel.org>,
	Fangrui Song <maskray@google.com>,
	Arthur Eubanks <aeubanks@google.com>, stable@vger.kernel.org
Subject: Re: [PATCH] x86/purgatory: Switch to the position-independent small
 code model
Message-ID: <20240420131717.GAZiPAXY9EAYnHajaw@fat_crate.local>
References: <20240418201705.3673200-2-ardb+git@google.com>
 <3f23b551-4815-4a06-9217-ff5beeb80df2@kernel.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <3f23b551-4815-4a06-9217-ff5beeb80df2@kernel.org>

On Fri, Apr 19, 2024 at 01:35:44PM +0200, Jiri Slaby wrote:
> On 18. 04. 24, 22:17, Ard Biesheuvel wrote:
> > From: Ard Biesheuvel <ardb@kernel.org>
> > 
> > On x86, the ordinary, position dependent 'small' and 'kernel' code models only
> > support placement of the executable in 32-bit addressable memory, due to
> > the use of 32-bit signed immediates to generate references to global
> > variables. For the kernel, this implies that all global variables must
> > reside in the top 2 GiB of the kernel virtual address space, where the
> > implicit address bits 63:32 are equal to sign bit 31.
> > 
> > This means the kernel code model is not suitable for other bare metal
> > executables such as the kexec purgatory, which can be placed arbitrarily
> > in the physical address space, where its address may no longer be
> > representable as a sign extended 32-bit quantity. For this reason,
> > commit
> > 
> >    e16c2983fba0 ("x86/purgatory: Change compiler flags from -mcmodel=kernel to -mcmodel=large to fix kexec relocation errors")
> > 
> > switched to the 'large' code model, which uses 64-bit immediates for all
> > symbol references, including function calls, in order to avoid relying
> > on any assumptions regarding proximity of symbols in the final
> > executable.
> > 
> > The large code model is rarely used, clunky and the least likely to
> > operate in a similar fashion when comparing GCC and Clang, so it is best
> > avoided. This is especially true now that Clang 18 has started to emit
> > executable code in two separate sections (.text and .ltext), which
> > triggers an issue in the kexec loading code at runtime.
> > 
> > Instead, use the position independent small code model, which makes no
> > assumptions about placement but only about proximity, where all
> > referenced symbols must be within -/+ 2 GiB, i.e., in range for a
> > RIP-relative reference. Use hidden visibility to suppress the use of a
> > GOT, which carries absolute addresses that are not covered by static ELF
> > relocations, and is therefore incompatible with the kexec loader's
> > relocation logic.
> 
> FWIW:
> 
> Fixes: https://bugzilla.suse.com/show_bug.cgi?id=1211853

Interesting. I thought gcc doesn't have problems here yet and was
talking to Matz on Thu about it and it seems he's forgotten about his
statement too that "you should simply stop using -mcmodel=large.  Noone
should use it." :-)

Ok then, lemme queue Ard's fix.

I guess we want it in stable too but as it is pretty much the case with
toolchain fixes I'd prefer if we queued it the normal path for 6.10 and
then backport it after it sees some testing and nothing breaks. And not
rush it to Linus now.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette