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

[Alexandre Ghiti]

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!
> >
> > Alex
> >
> >
> > > _______________________________________________
> > > linux-riscv mailing list
> > > linux-riscv@xxxxxxxxxxxxxxxxxxx
> > > http://lists.infradead.org/mailman/listinfo/linux-riscv