linux-kernel - Re: [PATCH 0/2] x86/purgatory: Avoid kexec runtime warning with LLVM 18

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMj1kXH+rNU4pa0ywcgkohXBu4G+iCXML_s9WVJW03ZRwtwW-w@mail.gmail.com>
Date: Thu, 18 Apr 2024 17:59:53 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Nick Desaulniers <ndesaulniers@...gle.com>
Cc: Borislav Petkov <bp@...en8.de>, Arthur Eubanks <aeubanks@...gle.com>, 
	Nathan Chancellor <nathan@...nel.org>, tglx@...utronix.de, mingo@...hat.com, 
	dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com, morbo@...gle.com, 
	justinstitt@...gle.com, song@...nel.org, ribalda@...omium.org, 
	linux-kernel@...r.kernel.org, llvm@...ts.linux.dev, patches@...ts.linux.dev, 
	ns <0n-s@...rs.noreply.github.com>, Fangrui Song <maskray@...gle.com>
Subject: Re: [PATCH 0/2] x86/purgatory: Avoid kexec runtime warning with LLVM 18

On Thu, 18 Apr 2024 at 17:44, Nick Desaulniers <ndesaulniers@...gle.com> wrote:
>
> On Thu, Apr 18, 2024 at 4:15 AM Borislav Petkov <bp@...en8.de> wrote:
> > How much of this silliness should we expect now for other parts of the kernel?
>
> Looks like ARCH=powerpc sets -mcmodel=large for modules and ARCH=um
> does for the whole kernel. So that LLVM change may have implications
> for those 2 other architectures.  Not sure we've had any bug reports
> or breakage in CI yet, like we have for x86+kexec.
>
> > Can we turn this off?
>
> Maybe we need to revisit
> commit e16c2983fba0 ("x86/purgatory: Change compiler flags from
> -mcmodel=kernel to -mcmodel=large to fix kexec relocation errors")
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e16c2983fba0fa6763e43ad10916be35e3d8dc05
>
> at least the -mcmodel=kernel addition (since that patch added a few
> additional compiler flags that still LGTM).
>
..

> + Fangrui, Ard, who might know of alternative solutions to
> -mcmodel=large for e16c2983fba0.
>

I think it would be better to use -mcmodel=small -fpic. As Nick
explains, the large code model is really more suitable for executables
that span a large memory range. The issue with the purgatory seems to
be that it can be placed anywhere in memory, not that it is very big.

-mcmodel=small -fpic is what user space typically uses, so it is much
less likely to create problems.

Note that I have been looking into whether we can build the entire
kernel with -fpic (for various reasons). There are some issues to
resolve there, mostly related to per-CPU variables and the per-CPU
stack protector, but beyond that, things work happily and the number
of boot time relocations drops dramatically, due to the use of
RIP-relative references. So for the purgatory, I wouldn't expect too
many surprises.

> Otherwise, I think the dedicated linker script is the way to go. We
> really want tight control over what is or is not in the purgatory
> image.

Linker scripts are a bit tedious when it comes to maintenance,
especially with weird executables such as this one and needing to
support different linkers. So I'd prefer to avoid this.