Messages in this thread | | | Date | Fri, 19 Apr 2024 13:35:44 +0200 | Subject | Re: [PATCH] x86/purgatory: Switch to the position-independent small code model | From | Jiri Slaby <> |
| |
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
thanks, -- js suse labs
| |