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

["Theodore Tso" <tytso@mit.edu>]

On Tue, Sep 08, 2026 at 01:14:48PM -0500, igor.stoppa@gmail.com wrote:
> AFAIK PREEMPT_RT was driven by specific functional needs only.
> We need to deal also with additional regulatory requirements that affect
> the shape of the code, not only its behavior.
>
> To the best of my knowledge, this aspect is perhaps a new addition to the
> typical kernel coding criteria.
> And that is what I wanted to discuss.

If the certification requires restricting and slowing down what 99% of
the other Linux developers need to do, supporting 99% of the business
value of Linux, it's not going to be something that people will be
enthusiastic about.

In practice, certification requires paying $$$$$ to a certification
agency, so realistically, the vast majority of Linux kernel releases
will not be safety certified.  So tying everyone's hands when going to
have approximately business value most of the time, and only if *all*
of your Linux "safety" patches are accepted, and you would then have
veto power over all future Linux development.... is not going to be
something that most people would consider the worthwhile just to
extend Linux's world-wide domination by 0.00001%, and where your
company would be capturing nearly all of the business value.


Worst, you're asking us to buy a pig-in-a-poke.  There are no patches,
and you want us to agree ahead of time to constrain and inconvenience
tens of thousands of kernel developers for something that won't
benefit most of them or their companies?

It may be that some of your patches will improve safety, without
actually achieving full certification.  Call that "soft" Linux safety
as opposed to "hard" Linux safety, much like "soft" vs "hard"
real-time.  If there cheap ways that we can make Linux more robust
without compromising speed (so no checks on fast paths) and without
compromising maintability, great!

Yes, it's slower, but there are no shortcuts.  The PREEMPT_RT patches
show that it is possible, however.  (But only if the business value
makes it worthwhile.  And if business value isn't strong enough, they
why should we pay the cost ahead of time, and accept a huge amount of
developer velocity and aggravation?)

Cheers,

							- Ted