linux-kernel - Re: [PATCH v3 2/2] selftests/riscv: Add Zicbop prefetch test

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20251030-3c0cafb066281de4dacd4000@orel>
Date: Thu, 30 Oct 2025 16:16:35 -0500
From: Andrew Jones <ajones@...tanamicro.com>
To: Yao Zihong <zihong.plct@...c.iscas.ac.cn>
Cc: alex@...ti.fr, alexghiti@...osinc.com, aou@...s.berkeley.edu, 
	cleger@...osinc.com, evan@...osinc.com, linux-kernel@...r.kernel.org, 
	linux-riscv@...ts.infradead.org, palmer@...belt.com, pjw@...nel.org, samuel.holland@...ive.com, 
	shuah@...nel.org, zhangyin2018@...as.ac.cn, zihongyao@...look.com
Subject: Re: [PATCH v3 2/2] selftests/riscv: Add Zicbop prefetch test

On Thu, Oct 23, 2025 at 11:48:18PM +0800, Yao Zihong wrote:
> > Undesired reformatting
> My bad. It will be fixed in the next version.
> 
> > Should we just unconditionally register handlers for SIGSEGV and SIGBUS?
> I think it depends on what the flags --sig{segv,ill,bus} are intended to mean:
> 
>   a) We intend to handle these faults that might be raised inside the test
>      (i.e., catch and convert them into pass/fail results without crashing the
>      test binary, rather than letting something else handle them externally).
>   b) We expect these signals to be raised as part of the test scenario and
>      handle them within the test program accordingly.
> 
> I'm not sure if (a) is appropriate, since it might mess up someone’s CI
> or other automation setups.

The intention of --sigill is to tell the test that a SIGILL is expected
and tests should be run to ensure they are raised. We should probably
allow that expectation to be extension specific though, i.e. have both a
--zicbom-raises-sigill and a --zicboz-raises-sigill

> 
> If we’re going with (b), then registering handlers for SIGSEGV and SIGBUS
> based on flags would be inconsistent with that semantics, since prefetch.*
> should never legitimately raise them. In that case, this design probably
> doesn’t make sense. Would it also make sense to rename the '--sigill' flag
> to make this clearer?

Since SIGSEGV and SIGBUS are never expected, then we could always handle
those in order to report failures, but we should narrow the time the
handlers are registered to be just around the use of instructions under
test.

Thanks,
drew