On Tue, Oct 15, 2024 at 6:05 PM Jessica Clarke <jrtc27@xxxxxxxxxx> wrote: > > On 9 Oct 2024, at 08:27, Alexandre Ghiti <alexghiti@xxxxxxxxxxxx> 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@xxxxxxxxxx> > > Closes: https://lore.kernel.org/linux-riscv/CAJD_bPJes4QhmXY5f63GHV9B9HFkSCoaZjk-qCT2NGS7Q9HODg@xxxxxxxxxxxxxx/ [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@xxxxxxxxxxxxxxx > > Signed-off-by: Alexandre Ghiti <alexghiti@xxxxxxxxxxxx> > > 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 >
