[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <46458788-54e1-4b4e-b7ef-852d9fb09ca6@starfivetech.com>
Date: Wed, 28 May 2025 05:38:37 +0000
From: JiaJie Ho <jiajie.ho@...rfivetech.com>
To: Samuel Holland <samuel.holland@...ive.com>, Palmer Dabbelt
<palmer@...belt.com>, "linux-riscv@...ts.infradead.org"
<linux-riscv@...ts.infradead.org>, Andrey Ryabinin <ryabinin.a.a@...il.com>,
Alexander Potapenko <glider@...gle.com>, Andrey Konovalov
<andreyknvl@...il.com>, Dmitry Vyukov <dvyukov@...gle.com>, Vincenzo Frascino
<vincenzo.frascino@....com>, "kasan-dev@...glegroups.com"
<kasan-dev@...glegroups.com>
CC: "llvm@...ts.linux.dev" <llvm@...ts.linux.dev>, Catalin Marinas
<catalin.marinas@....com>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
Alexandre Ghiti <alexghiti@...osinc.com>, Will Deacon <will@...nel.org>,
Evgenii Stepanov <eugenis@...gle.com>, Andrew Morton
<akpm@...ux-foundation.org>, "linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v2 0/9] kasan: RISC-V support for KASAN_SW_TAGS using
pointer masking
On 22/10/2024 9:57 am, Samuel Holland wrote:
> This series implements support for software tag-based KASAN using the
> RISC-V pointer masking extension[1], which supports 7 and/or 16-bit
> tags. This implementation uses 7-bit tags, so it is compatible with
> either hardware mode. Patch 4 adds supports for KASAN_SW_TAGS with tag
> widths other than 8 bits.
>
> Pointer masking is an optional ISA extension, and it must be enabled
> using an SBI call to firmware on each CPU. If the SBI call fails on the
> boot CPU, KASAN is globally disabled. Patch 2 adds support for boot-time
> disabling of KASAN_SW_TAGS, and patch 3 adds support for runtime control
> of stack tagging.
>
> Patch 1 is an optimization that could be applied separately. It is
> included here because it affects the selection of KASAN_SHADOW_OFFSET.
>
> This implementation currently passes the KASAN KUnit test suite:
>
> # kasan: pass:64 fail:0 skip:9 total:73
> # Totals: pass:64 fail:0 skip:9 total:73
> ok 1 kasan
>
> One workaround is required to pass the vmalloc_percpu test. I have to
> shrink the initial percpu area to force the use of a KASAN-tagged percpu
> area in the test (depending on .config, this workaround is also needed
> on arm64 without this series applied, so it is not a new issue):
>
> masking, the kernel still boots successfully:
>
> kasan: test: Can't run KASAN tests with KASAN disabled
> # kasan: # failed to initialize (-1)
> not ok 1 kasan
>
> This series can be tested by applying patch series to LLVM[2] and
> QEMU[3], and using the master branch of OpenSBI[4].
>
> [1]: https://github.com/riscv/riscv-j-extension/raw/d70011dde6c2/zjpm-spec.pdf
> [2]: https://github.com/SiFiveHolland/llvm-project/commits/up/riscv64-kernel-hwasan
> [3]: https://lore.kernel.org/qemu-devel/20240511101053.1875596-1-me@deliversmonkey.space/
> [4]: https://github.com/riscv-software-src/opensbi/commit/1cb234b1c9ed
>
Hi Samuel,
I noticed vector instructions failing with sw tag-based kasan enabled.
E.g. running the rvv_memcpy example from
https://github.com/riscv-non-isa/rvv-intrinsic-doc/tree/main
Error log:
# ./rvv_memcpy.elf
[ 354.145633] Unable to handle kernel paging request at virtual address ff7ac00001078410
[ 354.146334] Oops [#6]
[ 354.146511] Modules linked in:
[ 354.146791] CPU: 2 UID: 0 PID: 134 Comm: rvv_memcpy.elf Tainted: G D 6.12.19-00023-g6ec23f450118-dirty #200
[ 354.147771] Tainted: [D]=DIE
[ 354.148350] Hardware name: riscv-virtio,qemu (DT)
[ 354.148888] epc : arch_exit_to_user_mode_prepare+0x32/0x80
[ 354.149334] ra : irqentry_exit_to_user_mode+0x1e/0x9a
[ 354.149659] epc : ffffffff801b8836 ra : ffffffff8213db8c sp : ff200000007b7e90
[ 354.150173] gp : ffffffff82c2bbc8 tp : 9560000080c56600 t0 : 0000000000000001
[ 354.150709] t1 : fef0001000000000 t2 : 9560000080c56600 s0 : ff200000007b7ea0
[ 354.151082] s1 : ff200000007b7ee0 a0 : ff200000007b7ee0 a1 : 9560000080c56dff
[ 354.151658] a2 : bd60000083c20800 a3 : 0000000000000600 a4 : 0000000000000100
[ 354.153212] a5 : fff5ffff080c5661 a6 : fff60000080c5660 a7 : fff5ffff080c5660
[ 354.154668] s2 : 0000000000000001 s3 : 00000000c22026f3 s4 : 0000000000000002
[ 354.158327] s5 : 00007fffaac623e0 s6 : 000055555eec6de0 s7 : 00007fffaac8fcb0
[ 354.159481] s8 : 00007fffaac90008 s9 : 0000000000000000 s10: 00005555844b1bd4
[ 354.162673] s11: 00005555844b1b48 t3 : 000000000000004a t4 : 408a03c3cac3a788
[ 354.164378] t5 : 40659b6a3963f6d4 t6 : 4083e9c60c55738c
[ 354.165117] status: 8000000200000700 badaddr: ff7ac00001078410 cause: 000000000000000d
[ 354.166137] [<ffffffff801b8836>] arch_exit_to_user_mode_prepare+0x32/0x80
[ 354.167201] [<ffffffff8213db8c>] irqentry_exit_to_user_mode+0x1e/0x9a
[ 354.169119] [<ffffffff8213d4cc>] do_trap_insn_illegal+0x5a/0x92
[ 354.171989] [<ffffffff82156bf8>] handle_exception+0x148/0x156
[ 354.174056] Code: 0593 7ff2 b603 4615 0693 6000 a073 1006 7757 0c30 (0007) 0206
[ 354.175524] ---[ end trace 0000000000000000 ]---
[ 354.177344] note: rvv_memcpy.elf[134] exited with irqs disabled
Segmentation fault
Thanks
Jia Jie
Powered by blists - more mailing lists