linux-kernel - Re: [RFC PATCH 09/17] verification/rvgen: Allow spaces in and events strings

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: <a87d09f61a873778fe9f737ea4ab7c62dc43e950.camel@redhat.com>
Date: Thu, 21 Aug 2025 15:22:23 +0200
From: Gabriele Monaco <gmonaco@...hat.com>
To: Nam Cao <namcao@...utronix.de>
Cc: linux-kernel@...r.kernel.org, Steven Rostedt <rostedt@...dmis.org>, 
	linux-trace-kernel@...r.kernel.org, Tomas Glozar <tglozar@...hat.com>, Juri
 Lelli <jlelli@...hat.com>, Clark Williams <williams@...hat.com>, John Kacur
 <jkacur@...hat.com>
Subject: Re: [RFC PATCH 09/17] verification/rvgen: Allow spaces in and
 events strings

On Thu, 2025-08-21 at 14:22 +0200, Nam Cao wrote:
> On Thu, Aug 14, 2025 at 05:08:01PM +0200, Gabriele Monaco wrote:
> > Currently the automata parser assumes event strings don't have any
> > space, this stands true for event names, but can be a wrong
> > assumption
> > if we want to store other information in the event strings (e.g.
> > constraints for hybrid automata).
> > 
> > Adapt the parser logic to allow spaces in the event strings.
> 
> The current parser does have a few problems. Not all valid .dot files
> are accepted.
> 
> I have a patch buried somewhere which removes the custom parser and
> instead uses a library. But then it adds a new dependency, so I'm not
> sure if it is worth..

Yeah it isn't really robust, I tried to improve it a bit but sure
something is still failing it.
We don't need full dot capabilities, but just extract some keywords,
I'd avoid pulling in a dependency for that.

I'm imagining users would either generate graphs from the
Waters/Supremica tool [1] or copy/edit existing ones, so I'm not sure
they can go that far.
Still that's hacky because some things are just lightly implied by the
code (e.g. initial/final states, edges labels, etc.), so one day we
should at the very least say what DOT is valid and what not.

Do you have specific examples of what doesn't work?

Thanks,
Gabriele

[1] - https://github.com/robimalik/Waters/releases