On 17 December 2024 10:25:56 CET, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: >On Tue, 17 Dec 2024 at 10:17, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote: >> >> On 17 December 2024 09:47:36 CET, Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: >> >On Tue, 17 Dec 2024 at 00:37, David Woodhouse <dwmw2@xxxxxxxxxxxxx> wrote: >> >> >> >> From: David Woodhouse <dwmw@xxxxxxxxxxxx> >> >> >> >> 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. Ack, I'll roll it in to the next revision if Ingo hasn't rounded this set up of fixes up already. (On which topic, since I took the easy way out of the CFO thing, this patch isn't strictly needed to fix a regression in tip/x86/boot so can be dropped for now too.) Thanks.
