Re: [TECH TOPIC] Improving kernel security & integrity by generalizing ad-hoc safety mechanisms

["Chuck Wolber" <chuck@wolber.net>]

On Wed, Sep 9, 2026, at 9:40 AM, igor.stoppa@gmail.com wrote:

[...]

> And the safety problem is too complex for affording any form of NIH-ism

Safety is deterministic behavior within a specified range of conditions.

Outside of specific industries, the word "bug" is used to describe
behavior that violates expectations.

The safety case is just a desire to make Linux more deterministic so
that it can be used in places where failure has a greater cost.

The payback is more deterministic behavior under all conditions.


> It is a limitation that - as expected - comes from trying to adapt a
> tool that was
> born with a different purpose in mind.
> The idea of leveraging the existing ftrace infrastructure often bubbles up in
> FuSa circles. It's undoubtedly tempting.

Both RV and ftrace are excellent tools, but they are only part of the
story. Deterministic behavior in a safety critical context requires an
answer for when those tools detect non-conformance.

That is why pruning the potential state space (e.g. your fences
proposal), is almost certainly worthwhile. Even non-safety critical
contexts should benefit from it.


> This is perhaps one of my favourite pet peeves with the approach taken by
> many functional safety initiatives.
> They start looking for a tool that might solve the problem, but skip
> what should be
> instead a mandatory entry vetting:

My pet peeve goes even further back than that.

The case for safety is just a version of what we all expect from any
software - something that does not violate our expectations.

It makes little difference that our expectation is to not die when we
are ensconced in a tin can at 40,000 feet.

The safety case is just finding a way to make software work the way we
expect under some pretty hostile conditions.

If we can make it work on an airplane or an F1 car, your cloud server
and desktop experience is going to be significantly improved in the
process.


> Is the tool immune from the type of interference it should monitor?
> In other words, is it qualifiable?
> If not, can it be made compliant with FFI requirements?

Qualifiable == evidence of deterministic behavior under specified
conditions. It is no more complex than that.

Every industry has specific means-of-compliance, but all roads lead to
"works as expected when operated the way the designers intended".

That statement is also the hope that is wrapped up in every single
kernel release.


> From this perspective, safety is worse than security, because security usually
> lets you plan your defences so that you can use anything available, to
> prevent an attack.
> Because the core system is assumed to be trusted, usually.

I presented on this at OSSNA in 2024. I characterized it as the
"Cinderblock Problem".

https://www.youtube.com/watch?v=c8KCZFvIA2s


..Ch:W..