Re: [PATCH v5 07/20] x86/kexec: Invoke copy of relocate_kernel() instead of the original

[David Woodhouse <dwmw2@infradead.org>]

[-- Attachment #1: Type: text/plain, Size: 1794 bytes --]

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.




[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5965 bytes --]