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: <20250821151520.nc0hALIW@linutronix.de>
Date: Thu, 21 Aug 2025 17:15:20 +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,
	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, Aug 21, 2025 at 03:22:23PM +0200, Gabriele Monaco wrote:
> 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.

When I tried out the DA monitor, I edited the .dot files directly.

> 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.

We could also rewrite the parser using ply with a well-defined grammar and
tokenizer, like how the LTL parser is implemented. Doing it this way would
be easier to validate as well, because the grammar would be mostly
copy-pasted from the specification.

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

Two things that I can remember:

  - breaking long lines

  - C-style and C++-style comments

Not really relevant if you do not edit the .dot files directly like I did.
But these things are valid according to https://graphviz.org/doc/info/lang.html

Nam