Messages in this thread | | | From | Ard Biesheuvel <> | Date | Thu, 18 Apr 2024 17:59:53 +0200 | 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@google.com> wrote: > > On Thu, Apr 18, 2024 at 4:15 AM Borislav Petkov <bp@alien8.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.
| |