Re: [PATCH -fixes] riscv: Fix relocatable kernels with early alternatives using -fno-pie

From: Alexandre Ghiti
Date: Wed May 31 2023 - 07:04:05 EST

On 31/05/2023 11:32, Conor Dooley wrote:
On Wed, May 31, 2023 at 09:26:27AM +0200, Alexandre Ghiti wrote:
On 30/05/2023 22:22, Conor Dooley wrote:
On Tue, May 30, 2023 at 08:04:17PM +0200, Alexandre Ghiti wrote:
Ahah, I think we found the culprit!

With CONFIG_RELOCATABLE, vmlinux is actually stripped from all the
relocations (so that it can be shipped) and vmlinux.relocs is what you
should use instead, since it is just a copy of vmlinux before the
removal of the relocations!
That probably makes us both eejits for not realising sooner...
Ahah, TIL a new word, thanks :)

Tested-by: Conor Dooley <conor.dooley@xxxxxxxxxxxxx> # booted on nezha & unmatched

Thanks for your patience here Alex.
So I checked again if the -fno-pie should be applied to mm/dma-noncoherent.c
as I suggested, but actually no: errata/thead/errata.c never reaches
riscv_noncoherent_supported() in early boot (you can see how 'fragile' it is
though and why something needs to be done...).
I did make sure to check this patch itself, without the additional bit,
to see if it was needed.
But yeah, it is going to be super fragile - do you have any ideas about
how to circumvent that?

Yes, I was thinking about multiple solutions:

- All the early code could go into kernel/pi: all the dependencies of the early code is built in its own way (the symbols are actually 'duplicated'). I see that a bit like the EFI stub. My first try failed with !CONFIG_RELOCATABLE, I have to dig further.

- Simply do a physical relocation before any early code, execute the early code, and then do the virtual relocation. But that does not solve the issue fixed by kernel/pi which allows to recompile standard functions (like the string ones) without any instrumentation and have the versions with the instrumentation for normal execution.

- Compile relocatable kernels without -fPIE (why can't we just use medany actually?). That won't fix certain types of situations where we need relocations, but that will limit the number of outliers that need to be compiled with -fno-pie and it will be easier to spot (we'll still have to be very careful though)

- Be very strict about what can/cannot be done in this pre-mmu stage, and document that...

The best solution would be the first I guess. Any other ideas welcome :)

Oh and I realized that I forgot the Reported-by from Andreas and the Fixes
tags, so here they are:

Fixes: 39b33072941f ("riscv: Introduce CONFIG_RELOCATABLE")
Reported-by: Andreas Schwab <schwab@xxxxxxxxxxxxxx>

Thank you too for your patience and your quick answers!


linux-riscv mailing list