[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <5857ef047402c3ded29d4c024f8fdc32608f1696.camel@infradead.org>
Date: Wed, 18 Dec 2024 10:44:25 +0100
From: David Woodhouse <dwmw2@...radead.org>
To: Josh Poimboeuf <jpoimboe@...nel.org>
Cc: Nathan Chancellor <nathan@...nel.org>, kexec@...ts.infradead.org, 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>, "Kirill A. Shutemov"
<kirill.shutemov@...ux.intel.com>, Kai Huang <kai.huang@...el.com>, Nikolay
Borisov <nik.borisov@...e.com>, linux-kernel@...r.kernel.org, Simon Horman
<horms@...nel.org>, Dave Young <dyoung@...hat.com>, Peter Zijlstra
<peterz@...radead.org>, bsz@...zon.de
Subject: Re: [PATCH v5 07/20] x86/kexec: Invoke copy of relocate_kernel()
instead of the original
On Wed, 2024-12-18 at 01:03 -0800, Josh Poimboeuf wrote:
> On Tue, Dec 17, 2024 at 01:03:07PM +0100, David Woodhouse wrote:
> > I've dropped this for now and just posted the __nocfi thing as the
> > regression fix. I think we *should* provide the CFI information in
> > relocate_kernel_64.S though, so I've left these commits in my tree at
> > https://git.infradead.org/?p=users/dwmw2/linux.git;a=shortlog;h=refs/heads/kexec-debug
> >
> > I'd really appreciate some help in getting objtool to stop whining
> > about them, for *both* Clang and GCC builds at the same time :)
>
> Hm, I can't fetch for some reason:
>
> $ git fetch https://git.infradead.org/users/dwmw2/linux.git kexec-debug
> fatal: https://git.infradead.org/users/dwmw2/linux.git/info/refs not valid: could not determine hash algorithm; is this a git repository?
>
The https URL is just gitweb. You can fetch from
git://git.infradead.org/users/dwmw2/linux.git
> At some point we had discussed placing the code in .rodata, was it the
> alternative preventing that?
No, the alternative seems to be fine, and it's all in the .data section
now (since the kernel does write some variables there which are then
accessed %rip-relative from the code itself).
The problem is when I use SYM_TYPED_FUNC_START for relocate_kernel
itself, objtool starts to whine that the first instruction of
relocate_kernel is unreachable (presumably) because it is never jumped
to directly, but copied into the control page and then called via a
calculated function pointer).
There's also an objtool warning about loading the stack pointer. I seem
to get different warnings from objtool for Clang and GCC builds, and
can't find a set of hints which will make them both shut up at the same
time.
Download attachment "smime.p7s" of type "application/pkcs7-signature" (5965 bytes)
Powered by blists - more mailing lists