linux-kernel - Re: [PATCH v5 7/9] rv: Replace tss and sncid monitors with more complete sts

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250729092510._Hq3RWF_@linutronix.de>
Date: Tue, 29 Jul 2025 11:25:10 +0200
From: Nam Cao <namcao@...utronix.de>
To: Gabriele Monaco <gmonaco@...hat.com>
Cc: linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>,
	linux-trace-kernel@...r.kernel.org, linux-doc@...r.kernel.org,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Tomas Glozar <tglozar@...hat.com>, Juri Lelli <jlelli@...hat.com>,
	Clark Williams <williams@...hat.com>,
	John Kacur <jkacur@...hat.com>
Subject: Re: [PATCH v5 7/9] rv: Replace tss and sncid monitors with more
 complete sts

On Tue, Jul 29, 2025 at 10:46:51AM +0200, Gabriele Monaco wrote:
> On Mon, 2025-07-28 at 17:53 +0200, Nam Cao wrote:
> > I gave this a try on riscv64 and observed some errors:
> > 
> > [  620.696055] rv: monitor sts does not allow event sched_switch on
> > state enable_to_exit
> > [  621.047705] rv: monitor sts does not allow event sched_switch on
> > state enable_to_exit
> > [  642.440209] rv: monitor sts does not allow event sched_switch on
> > state enable_to_exit
> > 
> > I tested with two user programs:
> > 
> >     int main() { asm ("unimp"); }
> >     int main() { asm ("ebreak"); }
> > 
> > The two programs are repeatedly executed:
> > 
> >     #!/bin/bash
> >     ./test1 &
> >     ./test2 &
> >     # ... repeat lots of time
> > 
> > Any idea?
> 
> Mmh I see what you're doing here..
> Those instructions are supposed to raise some sort of exception in the
> CPU which apparently disables and enables interrupts without raising an
> interrupt handler tracepoint (the discriminator for this monitor).
> This lets the monitor believe we passed the time a switch is possible
> and complain when it actually sees one.
> 
> I still couldn't reproduce it on my VM, yet I find the timing a bit
> strange: it's alright we handle the illegal instruction like this, but
> do we really end up doing that while scheduling although it doesn't
> look like an interrupt?!
> 
> Could you share a bit more about your riscv setup? It might some
> configuration/hardware specific thing.

Kernel:
  - base: ftrace/for-next
  - config: defconfig + mod2noconfig + PREEMPT_RT + monitors

Hardware:
	qemu-system-riscv64 -machine virt \
	-kernel ../linux/arch/riscv/boot/Image \
	-append "console=ttyS0 root=/dev/vda rw" \
	-nographic \
	-drive if=virtio,format=raw,file=riscv64.img \
	-smp 4 -m 4G

	riscv64.img is a Debian trixie image from debootstrap

Test:
	echo 0 > /proc/sys/debug/exception-trace
	./testall # see attached

Download attachment "test.sh" of type "application/x-sh" (342 bytes)

View attachment "testall" of type "text/plain" (481 bytes)