[PATCH v2 5/9] riscv: mm: Log potential KASAN shadow alias
Alexandre Ghiti
alex at ghiti.fr
Tue Nov 5 05:44:25 PST 2024
Hi Samuel,
On 22/10/2024 03:57, Samuel Holland wrote:
> When KASAN is enabled, shadow memory is allocated and mapped for all
> legitimate kernel addresses, but not for the entire address space. As a
> result, the kernel can fault when accessing a shadow address computed
> from a bogus pointer. This can be confusing, because the shadow address
> computed for (e.g.) NULL looks nothing like a NULL pointer. To assist
> debugging, if the faulting address might be the result of a KASAN shadow
> memory address computation, report the range of original memory
> addresses that would map to the faulting address.
>
> Signed-off-by: Samuel Holland <samuel.holland at sifive.com>
> ---
>
> Changes in v2:
> - New patch for v2
>
> arch/riscv/mm/fault.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/arch/riscv/mm/fault.c b/arch/riscv/mm/fault.c
> index a9f2b4af8f3f..dae1131221b7 100644
> --- a/arch/riscv/mm/fault.c
> +++ b/arch/riscv/mm/fault.c
> @@ -8,6 +8,7 @@
>
>
> #include <linux/mm.h>
> +#include <linux/kasan.h>
> #include <linux/kernel.h>
> #include <linux/interrupt.h>
> #include <linux/perf_event.h>
> @@ -30,6 +31,8 @@ static void die_kernel_fault(const char *msg, unsigned long addr,
> pr_alert("Unable to handle kernel %s at virtual address " REG_FMT "\n", msg,
> addr);
>
> + kasan_non_canonical_hook(addr);
> +
> bust_spinlocks(0);
> die(regs, "Oops");
> make_task_dead(SIGKILL);
That's nice, I used to do that by hand :)
Reviewed-by: Alexandre Ghiti <alexghiti at rivosinc.com>
Thanks,
Alex
More information about the linux-riscv
mailing list