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: <59a4f3f7641c47494b53f788684aa703a02acca1.camel@tugraz.at>
Date: Fri, 21 Feb 2025 19:23:38 +0100
From: Martin Uecker <uecker@...raz.at>
To: Steven Rostedt <rostedt@...dmis.org>
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

Am Freitag, dem 21.02.2025 um 12:43 -0500 schrieb Steven Rostedt:
> 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

If you click on the link that provides the explanation, it says

"It has been found convenient to use __attribute__ to achieve a natural
attachment of attributes to their corresponding declarations, whereas
#pragma is of use for compatibility with other compilers or constructs
that do not naturally form part of the grammar. "

Regions of code do not naturally form part of the grammar, and
this is why I would like to use pragmas here.  

But I still wonder why it affects sparse?

...

> > 
> > > > 
> > > > 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 ; }

Calling a function declared in this way with arguments
would be rejected by the compiler, so I am not sure how
this works now.

If you used 

void func();

to declare the function, this is not possible anymore in C23.

But in any case, I think it is a major strength of C that you can
escape its rules when necessary. I do not intend to change this.
I just want to give people a tool to prevent unintended consequences
of UB.

Martin