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: <e525cd59ebec54b153f56b602b545007fc03f12a.camel@tugraz.at>
Date: Sat, 22 Feb 2025 08:20:12 +0100
From: Martin Uecker <uecker@...raz.at>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Steven Rostedt <rostedt@...dmis.org>, 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>, 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:11 -0800 schrieb Linus Torvalds:
> On Fri, 21 Feb 2025 at 11:59, Martin Uecker <uecker@...raz.at> wrote:
> > 
> > The standardized version of __attribute__(()) would look like
> > 
> > [[safety(ON)]];
> > ....
> > 
> > [[safety(OFF)]];
> > 
> > which is not bad (and what C++ seems to plan for profiles),
> > but this also does not nest and is a bit more limited to where
> > it can be used relative _Pragma.  I don't really see any advantage.
> > 
> > GCC has
> > 
> > #pragma GCC diagnostic push "-Wxyz"
> > #pragma GCC diagnostic pop
> > 
> > for nesting. Also not great.
> 
> I realize that the manual nesting model can be useful, but I do think
> the "default" should be to aim for always associating these kinds of
> things with actual code (or data), and use the normal block nesting
> rules.
> 
> If you are writing safe code - or better yet, you are compiling
> everything in safe mode, and have to annotate the unsafe code - you
> want to annotate the particular *block* that is safe/unsafe. Not this
> kind of "safe on/safe off" model.
> 
> At least with the __attribute__ model (or "[[..]]" if you prefer that
> syntax) it is very much designed for the proper nesting behavior.
> That's how attributes were designed.

There is no way to attach a GCC attribute to
a compound-statement.   For [[]] this is indeed allowed,
so you could write

void f()
{
	[[safety(DYNAMIC)]] {
	}
}

but then you also force the user to create compound-statement.
Maybe this is what we want, but it seems restrictive.  But I
will need to experiment with this anyhow to find out what works
best.

> 
> Afaik #pragma has _no_ such mode at all (but hey, most of it is
> compiler-specific random stuff, so maybe some of the #pragma uses are
> "this block only"), and I don't think _Pragma() is not any better in
> that respect (but again, since it has no real rules, again I guess it
> could be some random thing for different pragmas).

For all the STDC pragmas that already exist in ISO C, they are
effective until the end of a compund-statement.  These pragmas
are all for floating point stuff.

void f()
{
#pragma STDC FP_CONTRACT ON
}
// state is restored

but you also toggle it inside a compund-statement

void f()
{
#pragma STDC FP_CONTRACT ON
   xxx;
#pragma STDC FP_CONTRACT OFF
   yyy;
}
// state is restored

The problem with those is currently, that GCC does not 
implement them.  

I will need to think about this more.

Martin