On Tue, Oct 15, 2024 at 6:05 PM Jessica Clarke jrtc27@jrtc27.com wrote:
On 9 Oct 2024, at 08:27, Alexandre Ghiti alexghiti@rivosinc.com wrote:
Early code designates the code executed when the MMU is not yet enabled, and this comes with some limitations (see Documentation/arch/riscv/boot.rst, section "Pre-MMU execution").
FORTIFY_SOURCE must be disabled then since it can trigger kernel panics as reported in [1].
Reported-by: Jason Montleon jmontleo@redhat.com Closes: https://lore.kernel.org/linux-riscv/CAJD_bPJes4QhmXY5f63GHV9B9HFkSCoaZjk-qCT... [1] Fixes: a35707c3d850 ("riscv: add memory-type errata for T-Head") Fixes: 26e7aacb83df ("riscv: Allow to downgrade paging mode from the command line") Cc: stable@vger.kernel.org Signed-off-by: Alexandre Ghiti alexghiti@rivosinc.com
Is the problem in [1] not just that the early boot path uses memcpy on the result of ALT_OLD_PTR, which is a wildly out-of-bounds pointer from the compiler’s perspective? If so, it would seem better to use unsafe_memcpy for that one call site rather than use the big __NO_FORTIFY hammer, surely?
I can add that replacing memcpy with unsafe_memcpy did also work for me. Once it was narrowed down, this is what I originally did in order to boot.
Jason
Presumably the non-early path is just as bad to the compiler, but works because patch_text_nosync isn’t instrumented, so that would just align the two.
Getting the implementation to not be silent on failure during early boot would also be a good idea, but it’s surely better to have FORTIFY_SOURCE enabled with no output for positives than disable the checking in the first place and risk uncaught corruption.
Jess