linux-kernel - Re: Rust kernel policy

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20250221124304.5dec31b2@gandalf.local.home>
Date: Fri, 21 Feb 2025 12:43:04 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Martin Uecker <uecker@...raz.at>
Cc: Dan Carpenter <dan.carpenter@...aro.org>, Greg KH
 <gregkh@...uxfoundation.org>, 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

On Fri, 21 Feb 2025 17:28:30 +0100
Martin Uecker <uecker@...raz.at> wrote:

> > 
> > This kind of #pragma is basically banned in the kernel.  It's used
> > in drivers/gpu/drm but it disables the Sparse static checker.  
> 
> Why is this?

Because they are arcane and even the gcc documentation recommends avoiding
them.

 "Note that in general we do not recommend the use of pragmas"
 https://gcc.gnu.org/onlinedocs/gcc/Pragmas.html

> 
> >   
> > > 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'm less convinced by the static analysis parts of this...  The kernel
> > disables checking for unsigned less than zero by default because there
> > are too many places which do:
> > 
> > 	if (x < 0 || x >= 10) {
> > 
> > That code is perfectly fine so why is the compiler complaining?  But at
> > the same time, being super strict is the whole point of Rust and people
> > love Rust so maybe I have misread the room.  
> 
> What is a bit weird is that on the one side there are people
> who think we absolutely need  compiler-ensured memory safety
> and this might be even worth rewriting code from scratch and
> on the other side there are people who think that dealing with
> new false positives in existing code when adding new warnings
> is already too much of a burden.

Actually, I would be perfectly fine with fixing all locations that have
x < 0 where x is unsigned, even if it's in a macro or something. Those
could be changed to:

	if ((signed)x < 0 || x >= 10) {

If they want to allow unsigned compares.

> 
> > > 
> > > 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).   
> > 
> > No, this absolutely is useful.  This is what UBSan does now.
> >   
> 
> Yes, it is similar to UBSan. The ideas to make sure that in the
> mode there is *either* a compile-time warning *or* run-time
> trap for any UB.  So if you fix all warnings, then any remaining
> UB is trapped at run-time.

As long as we allow known UB. We have code that (ab)uses UB behavior in gcc
that can't work without it. For instance, static calls. Now if the compiler
supported static calls, it would be great if we can use that.

What's a static call?

It's a function call that can be changed to call other functions without
being an indirect function call (as spectre mitigations make that horribly
slow). We use dynamic code patching to update the static calls.

It's used for functions that are decided at run time. For instance, are we
on AMD or Intel to decide which functions to implement KVM.

What's the UB behavior? It's calling a void function with no parameters
that just returns where the caller is calling a function with parameters.
That is:

	func(a, b, c)

where func is defined as:

	void func(void) { return ; }

> 
> >   You're
> > basically talking about exception handling.  How could that not be
> > the most useful thing ever?  
> 
> At the moment, I wasn't thinking about a mechanism to catch those
> exceptions, but just to abort the program directly (or just emit
> a diagnostic and continue.  

Aborting the kernel means crashing the system.

-- Steve