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? 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
