Re: [PATCH v2 0/9] kasan: RISC-V support for KASAN_SW_TAGS using pointer masking

From: JiaJie Ho <jiajie.ho@starfivetech.com>
To: Samuel Holland <samuel.holland@sifive.com>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	"linux-riscv@lists.infradead.org"
	<linux-riscv@lists.infradead.org>,
	Andrey Ryabinin <ryabinin.a.a@gmail.com>,
	Alexander Potapenko <glider@google.com>,
	Andrey Konovalov <andreyknvl@gmail.com>,
	Dmitry Vyukov <dvyukov@google.com>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	"kasan-dev@googlegroups.com" <kasan-dev@googlegroups.com>
Cc: "llvm@lists.linux.dev" <llvm@lists.linux.dev>,
	Catalin Marinas <catalin.marinas@arm.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	Alexandre Ghiti <alexghiti@rivosinc.com>,
	Will Deacon <will@kernel.org>,
	Evgenii Stepanov <eugenis@google.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2 0/9] kasan: RISC-V support for KASAN_SW_TAGS using pointer masking
Date: Wed, 28 May 2025 05:38:37 +0000	[thread overview]
Message-ID: <46458788-54e1-4b4e-b7ef-852d9fb09ca6@starfivetech.com> (raw)
In-Reply-To: <20241022015913.3524425-1-samuel.holland@sifive.com>

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