Message-ID: <1d43700546b82cf035e24d192e1f301c930432a3.camel@tugraz.at>
Date: Thu, 20 Feb 2025 09:57:29 +0100
From: Martin Uecker <uecker@...raz.at>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: Boqun Feng <boqun.feng@...il.com>, "H. Peter Anvin" <hpa@...or.com>, 
 Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, Christoph Hellwig
 <hch@...radead.org>, rust-for-linux <rust-for-linux@...r.kernel.org>, Linus
 Torvalds <torvalds@...ux-foundation.org>,  David Airlie
 <airlied@...il.com>, linux-kernel@...r.kernel.org, ksummit@...ts.linux.dev
Subject: Re: Rust kernel policy

Am Donnerstag, dem 20.02.2025 um 08:10 +0100 schrieb Greg KH:
> On Thu, Feb 20, 2025 at 08:03:02AM +0100, Martin Uecker wrote:
> > Am Mittwoch, dem 19.02.2025 um 06:39 +0100 schrieb Greg KH:
> > > On Tue, Feb 18, 2025 at 07:04:59PM -0800, Boqun Feng wrote:
> > > > On Tue, Feb 18, 2025 at 04:58:27PM -0800, H. Peter Anvin wrote:
> > > > [...]
> > > > > > > 
> > ...
> > > 
> > > 
> > > I'm all for moving our C codebase toward making these types of problems
> > > impossible to hit, the work that Kees and Gustavo and others are doing
> > > here is wonderful and totally needed, we have 30 million lines of C code
> > > that isn't going anywhere any year soon.  That's a worthy effort and is
> > > not going to stop and should not stop no matter what.
> > 
> > It seems to me that these efforts do not see nearly as much attention
> > as they deserve.
> 
> What more do you think needs to be done here?  The LF, and other
> companies, fund developers explicitly to work on this effort.  Should we
> be doing more, and if so, what can we do better?

Kees communicates with the GCC side and sometimes this leads to
improvements, e.g. counted_by (I was peripherily involved in the
GCC implementation). But I think much much more could be done,
if there was a collaboration between compilers, the ISO C working
group, and the kernel community to design and implement such
extensions and to standardize them in ISO C.

> 
> > I also would like to point out that there is not much investments
> > done on C compiler frontends (I started to fix bugs in my spare time
> > in GCC because nobody fixed the bugs I filed), and the kernel 
> > community also is not currently involved in ISO C standardization.
> 
> There are kernel developers involved in the C standard committee work,
> one of them emails a few of us short summaries of what is going on every
> few months.  Again, is there something there that you think needs to be
> done better, and if so, what can we do?
> 
> But note, ISO standards work is really rough work, I wouldn't recommend
> it for anyone :)

I am a member of the ISO C working group. Yes it it can be painful, but
it is also interesting and people a generally very nice.

There is currently no kernel developer actively involved, but this would
be very helpful.

(Paul McKenney is involved in C++ regarding atomics and Miguel is
also following what we do.)

> 
> > I find this strange, because to me it is very obvious that a lot more
> > could be done towards making C a lot safer (with many low hanging fruits),
> > and also adding a memory safe subset seems possible.
> 
> Are there proposals to C that you feel we should be supporting more?

There are many things.

For example, there is an effort to remove cases of UB.  There are about
87 cases of UB in the core language (exlcuding preprocessor and library)
as of C23, and we have removed 17 already for C2Y (accepted by WG14 into
the working draft) and we have concrete propsoals for 12 more.  This
currently focusses on low-hanging fruits, and I hope we get most of the
simple cases removed this year to be able to focus on the harder issues.

In particulary, I have a relatively concrete plan to have a memory safe
mode for C that can be toggled for some region of code and would make
sure there is no UB or memory safety issues left (I am experimenting with
this in the GCC FE).  So the idea is that one could start to activate this
for certain critical regions of code to make sure there is no signed
integer overflow or OOB access in it.   This is still in early stages, but
seems promising. Temporal memory safety is harder and it is less clear
how to do this ergonomically, but Rust shows that this can be done.


I also have a proposal for a length-prefixed string type and for 
polymorhic types / genericity, but this may not be so relevant to the
kernel at this point.

Even more important than ISO C proposals would be compiler extensions
that can be tested before standardization.


Martin

Powered by blists - more mailing lists