linux-kernel - Re: [PATCH 3/3] rv: Add explicit lockdep context for reactors

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: <87a50ukvjy.fsf@yellow.woof>
Date: Mon, 10 Nov 2025 11:53:53 +0100
From: Nam Cao <namcao@...utronix.de>
To: Thomas Weißschuh <thomas.weissschuh@...utronix.de>,
 Gabriele Monaco
 <gmonaco@...hat.com>
Cc: Steven Rostedt <rostedt@...dmis.org>, Masami Hiramatsu
 <mhiramat@...nel.org>, Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 linux-trace-kernel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 3/3] rv: Add explicit lockdep context for reactors

Thomas Weißschuh <thomas.weissschuh@...utronix.de> writes:
> On Tue, Oct 14, 2025 at 04:50:18PM +0200, Gabriele Monaco wrote:
>> I don't mean to really sacrifice accuracy, DA monitors are disabled after a
>> reaction. This comes from the assumption that the model becomes invalid, so
>> whatever comes after might be meaningless. Monitors restart as soon as we are
>> sure we reached the initial state.
>> In this case, it already doesn't make sense to monitor events triggered by
>> reactors.

I can get behind this idea. I would even suspend tracepoints entirely
during tracepoint handling. Currently there is nothing protecting LTL's
internal data if multiple CPUs touch it internally. It needs a (raw)
spin lock, but cannot use it because spin locks step on some
tracepoints.

Suspending tracepoints during tracepoint handling would make lots of
things accessible to RV.

>> LTL is a bit more complex, so it might make sense to continue monitoring just
>> after a reaction, but I'm not sure how useful that is.
>
> Ack.
>
> It is still possible to manually re-enable all monitors through sysfs, correct?
> That is needed for the kind of testing I have in mind.
>
> Do we still consider these hypothetical tracepoint loops a blocker for this
> patch series? In my opinion the usage of lockdep does not exacerbate the risk.

Gabriele, if you want to take these patches:

Acked-by: Nam Cao <namcao@...utronix.de>

as the lockdep's tracepoints are not used by RV at the moment, so it
should be fine. And the patch does help with RV development.

But we need to investigate further into suspending monitor or suspending
tracepoints. If that is not feasible, we can revert this patch in the
future.

Nam