[PATCH 8/9] x86/kexec: Cope with relocate_kernel() not being at the start of the page

[Ard Biesheuvel]

On Tue, 17 Dec 2024 at 10:17, David Woodhouse <dwmw2 at infradead.org> wrote:
>
> On 17 December 2024 09:47:36 CET, Ard Biesheuvel <ardb at kernel.org> wrote:
> >On Tue, 17 Dec 2024 at 00:37, David Woodhouse <dwmw2 at infradead.org> wrote:
> >>
> >> From: David Woodhouse <dwmw at amazon.co.uk>
> >>
> >> A few places in the kexec control code page make the assumption that the
> >> first instruction of relocate_kernel is at the very start of the page.
> >>
> >> To allow for Clang CFI information to be added to relocate_kernel(), as
> >> well as the general principle of removing unwarranted assumptions, fix
> >> them to use the external __relocate_kernel_start symbol that the linker
> >> adds. This means using a separate addq and subq for calculating offsets,
> >> as the assembler can no longer calculate the delta directly for itself
> >> and relocations aren't that versatile.
> >>
> >
> >You can still avoid the absolute relocations though, ...
> ...
> >> +       addq    $identity_mapped, %rsi
> >> +       subq    $__relocate_kernel_start, %rsi
> >
> >... if you turn this into
> >
> >0:     addq    $identity_mapped - 0b, %rsi
> >       subq    $__relocate_kernel_start - 0b, %rsi
>
> Is there any benefit to doing so? Are absolute relocations problematic?

Every absolute relocation produces an entry in the relocation table
that needs to be applied at every boot when KASLR is in effect. Beyond
that, it doesn't matter.

I've looked into PIC codegen/PIE linking for the core kernel, which is
why this caught my eye. If that effort ever advances, I'll need to
revisit this code as well and apply the change I suggested.