[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAMj1kXF5C8TF02obuNrd6tZBZg0_Yz_VskGuNMnmoqyjLRAVRg@mail.gmail.com>
Date: Tue, 17 Dec 2024 10:25:56 +0100
From: Ard Biesheuvel <ardb@...nel.org>
To: David Woodhouse <dwmw2@...radead.org>
Cc: Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
"H. Peter Anvin" <hpa@...or.com>, Eric Biederman <ebiederm@...ssion.com>,
David Woodhouse <dwmw@...zon.co.uk>, Sourabh Jain <sourabhjain@...ux.ibm.com>,
Hari Bathini <hbathini@...ux.ibm.com>, Michael Ellerman <mpe@...erman.id.au>,
Thomas Zimmermann <tzimmermann@...e.de>, Andrew Morton <akpm@...ux-foundation.org>,
Baoquan He <bhe@...hat.com>, Yuntao Wang <ytcoode@...il.com>, David Kaplan <david.kaplan@....com>,
Tao Liu <ltao@...hat.com>, "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Kai Huang <kai.huang@...el.com>, Josh Poimboeuf <jpoimboe@...nel.org>,
Breno Leitao <leitao@...ian.org>, Wei Yang <richard.weiyang@...il.com>, Rong Xu <xur@...gle.com>,
Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
linux-kernel@...r.kernel.org, kexec@...ts.infradead.org,
Simon Horman <horms@...nel.org>, Dave Young <dyoung@...hat.com>,
Peter Zijlstra <peterz@...radead.org>, bsz@...zon.de, nathan@...nel.org
Subject: Re: [PATCH 8/9] x86/kexec: Cope with relocate_kernel() not being at
the start of the page
On Tue, 17 Dec 2024 at 10:17, David Woodhouse <dwmw2@...radead.org> wrote:
>
> On 17 December 2024 09:47:36 CET, Ard Biesheuvel <ardb@...nel.org> wrote:
> >On Tue, 17 Dec 2024 at 00:37, David Woodhouse <dwmw2@...radead.org> wrote:
> >>
> >> From: David Woodhouse <dwmw@...zon.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.
Powered by blists - more mailing lists