From: Gabriele Monaco <gmonaco@redhat.com>
To: Steven Rostedt <rostedt@goodmis.org>,
Tobias Schaffner <tobias.schaffner@siemens.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
linux-trace-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
rpm@xenomai.org, jan.kiszka@siemens.com
Subject: Re: [PATCH v2 0/3] rv: per-edge dwell-time statistics for per-cpu monitors
Date: Tue, 13 Oct 2026 09:53:14 +0200 [thread overview]
Message-ID: <8ba6ca530f6f35c04ce7147ad601eee6bca2d792.camel@redhat.com> (raw)
In-Reply-To: <20261012152129.4c57786c@gandalf.local.home>
On Mon, 2026-10-12 at 15:21 -0400, Steven Rostedt wrote:
> This brings back memories of conversations I had with Daniel. When asked
> about how this is being used in formal verification of safety critical
> systems, he told me that only the RV verifier itself needed to be verified
> and to show what it is verifying can be verified via it. For example,
> running Linux in autonomous vehicles handling critical systems the watchdog
> had to be verified that it could catch lockups. As the watchdog would
> trigger fail-safe mode if something went wrong. RV would be monitoring the
> watchdog and if RV detected something it would panic the machine, which
> would immediately force the vehicle into fail-safe mode (stop lots of
> features and only keep those that can stop the vehicle safely).
Yeah I talked to the same people working on that project, eventually there were
more problems like verifying RV can't be affected by the code it's verifying.
This is still an open problem though.
> Can using BPF as the RV verifier be formally verified? As verification for
> RV monitors did look at the binary. Is BPF optimized to machine language
> before it enters the kernel? If not, can we formally verify the BPF
> verifier created the correct binary? Maybe, I don't know.
As far as I understand, verifying the BPF verifier would take an insane amount
of work, the go-to approach is manually validating only the code you know you
are running. Let's say up to a point where you can realistically say it behaves
like you want it to.
In short, having a verifier doesn't add much value here, at least until someone
verifies that too.
Then there are the levels of indirection, BPF C code gets compiled to BPF
bytecode and that gets JIT compiled inside the kernel. Now it's machine code.
If people are normally not validating clang/gcc produce machine code consistent
to the verified source code, this case should be equivalent, but I'm just
speculating here.
Gabriele
next prev parent reply other threads:[~2026-10-13 7:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-11 12:34 [PATCH v2 0/3] rv: per-edge dwell-time statistics for per-cpu monitors Tobias Schaffner
2026-09-11 12:34 ` [PATCH v2 1/3] rv: add per-edge dwell-time statistics primitive Tobias Schaffner
2026-09-24 7:21 ` Gabriele Monaco
2026-09-11 12:34 ` [PATCH v2 2/3] rv: add per-monitor edge-stat facility and stats file Tobias Schaffner
2026-09-24 7:47 ` Gabriele Monaco
2026-10-13 11:43 ` Gabriele Monaco
2026-09-11 12:34 ` [PATCH v2 3/3] rv: collect per-edge dwell time for per-cpu DA/HA monitors Tobias Schaffner
2026-09-24 7:18 ` Gabriele Monaco
2026-10-12 11:47 ` [PATCH v2 0/3] rv: per-edge dwell-time statistics for per-cpu monitors Gabriele Monaco
2026-10-12 16:18 ` Tobias Schaffner
2026-10-12 19:21 ` Steven Rostedt
2026-10-13 7:53 ` Gabriele Monaco [this message]
2026-10-13 7:26 ` Gabriele Monaco
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8ba6ca530f6f35c04ce7147ad601eee6bca2d792.camel@redhat.com \
--to=gmonaco@redhat.com \
--cc=corbet@lwn.net \
--cc=jan.kiszka@siemens.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=rostedt@goodmis.org \
--cc=rpm@xenomai.org \
--cc=skhan@linuxfoundation.org \
--cc=tobias.schaffner@siemens.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox