Message-ID: <b9a5de64fe1ded2ad3111763f35af9901bd81cc4.camel@tugraz.at>
Date: Thu, 20 Feb 2025 16:40:02 +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 15:53 +0100 schrieb Greg KH:
> On Thu, Feb 20, 2025 at 09:57:29AM +0100, Martin Uecker wrote:
> > 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.
> 
> Sorry, I was referring to the kernel work happening here by Kees and
> Gustavo and others.  Not ISO C stuff, I don't know of any company that
> wants to fund that :(

My point is that the kernel work could probably benefit from better
compiler support and also ISO C work to get proper language extensions,
because otherwise it ends up as adhoc language extensions wrapped in
macros.  For example, we now can do today

#define __counted_by(len) __attribute__((counted_by(len)))
struct foo {
  int len;
  char buf[] __counted_by(len);
}; 

in GCC / clang, but what we are thinking about having is

struct foo {
  int len;
  char buf[.len];
}; 

or

struct bar {
 char (*ptr)[.len];
 int len;
};

For a transitional period you may need the macros anyway, but in the
long run I think nice syntax would help a lot.

It would be sad if nobody wants to fund such work, because this would
potentially have a very high impact, not just for the kernel. 
(I am happy to  collaborate if somebody wants to work on or fund this).

> > > 
...
> > > > 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.
> 
> What do you mean by "memory safe" when it comes to C?  Any pointers to
> that (pun intended)?

I mean "memory safe" in the sense that you can not have an OOB access
or use-after-free or any other UB.  The idea would be to mark certain
code regions as safe, e.g.

#pragma MEMORY_SAFETY STATIC
unsigned int foo(unsigned int a, unsigned int b)
{
  return a * b;
}

static int foo(const int a[static 2])
{
  int r = 0;
  if (ckd_mul(&r, a[0], a[1]))
    return -1;
  return r;
}

static int bar(int x)
{
  int a[2] = { x, x };
  return foo(a);
}


and the compiler would be required to emit a diagnostic when there
is any operation that could potentially cause UB.

I would also have a DYNAMIC mode that traps for UB detected at
run-time (but I understand that this is not useful for the kernel). 

Essentially, the idea is that we can start with the existing subset
of C that is already memory safe but very limited, and incrementally
grow this subset.   From a user perspectice, you would do the
same:  You would start by making certain critical code regions
safe by turning on the safe mode and refactoring the code, and you
can then be sure that inside this region there is no memory safety
issue left.  Over time and with more and more language support,
one could increase these safe regions.

My preliminary proposal is here:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3211.pdf

(temporal memory safety would need addressing, but here we can
learn from Cyclone / Rust)

There also different initiatives such as Clang's bounds checking
and GCC's analyzer and others that I hope we can build on here
to increase the scope of these safe regions.

> 
> > 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.
> 
> We have a string type in the kernel much like this, it's just going to
> take some work in plumbing it up everywhere.  Christoph touched on that
> in one of his emails in this thread many messages ago.  Just grinding
> out those patches is "all" that is needed, no need for us to wait for
> any standard committee stuff.
> 
> > Even more important than ISO C proposals would be compiler extensions
> > that can be tested before standardization.
> 
> We support a few already for gcc, and I don't think we've refused
> patches to add more in the past, but I might have missed them.

Do you mean patches to the kernel for using them?  I would like help with
developing such features in GCC.  I added a couple of warnings (e.g.
-Wzero-as-null-pointer-constant or -Walloc-size) recently, but more
complex features quickly exceed the time I can use for this.  But knowing
the GCC FE and also C, I see many low-hanging fruits here.

Martin

Powered by blists - more mailing lists