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

Open Source and information security mailing list archives

Message-ID: <9a94446d-bc6c-6272-8101-d1adeec3d672@ghiti.fr>
Date:   Wed, 31 May 2023 13:03:26 +0200
From:   Alexandre Ghiti <alex@...ti.fr>
To:     Conor Dooley <conor@...nel.org>
Cc:     Alexandre Ghiti <alexghiti@...osinc.com>,
        Conor Dooley <conor.dooley@...rochip.com>,
        Paul Walmsley <paul.walmsley@...ive.com>,
        Palmer Dabbelt <palmer@...belt.com>,
        Albert Ou <aou@...s.berkeley.edu>,
        Andreas Schwab <schwab@...ux-m68k.org>,
        linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH -fixes] riscv: Fix relocatable kernels with early
 alternatives using -fno-pie

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@...rochip.com> # 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@...ux-m68k.org>
>>
>>
>> Thank you too for your patience and your quick answers!
>>
>> Alex
>>
>>
>>> _______________________________________________
>>> linux-riscv mailing list
>>> linux-riscv@...ts.infradead.org
>>> http://lists.infradead.org/mailman/listinfo/linux-riscv

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives