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: <636f5758062a5ba930e8a73454e15f2fe29fdccf.camel@tugraz.at>
Date: Mon, 24 Feb 2025 19:03:24 +0100
From: Martin Uecker <uecker@...raz.at>
To: Ventura Jack <venturajack85@...il.com>, comex <comexk@...il.com>
Cc: Piotr Masłowski <piotr@...lowski.xyz>, 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 Montag, dem 24.02.2025 um 02:08 -0700 schrieb Ventura Jack:
> On Sun, Feb 23, 2025 at 4:32 PM comex <comexk@...il.com> wrote:
> > 
> > > On Feb 22, 2025, at 3:42 PM, Piotr Masłowski <piotr@...lowski.xyz> wrote:
> > > 
> > > I'm sure you already know this, but the idea of safety in Rust isn't
> > > just about making elementary language constructs safe. Rather, it is
> > > primarily about designing types and code in such a way one can't "use
> > > them wrong”.
> > 
> > And importantly, it’s very hard to replicate this approach in C, even
> > in a hypothetical ‘C + borrow checker’, because C has no generic types.  
> > 

One can have generic types in C.  Here is an example
for Option<T> (I called it "maybe").  I don't think
it is too bad (although still an experiment): 

https://godbolt.org/z/YxnsY7Ted

(The example can also be be proven safe statically)

Here is an example for a vector type (with bounds
checking):

https://godbolt.org/z/7xPY6Wx1T

> > Not all abstractions need generics, but many do.
> 
> True, a more expressive and complex language like Rust, C++, Swift,
> Haskell, etc. will typically have better facilities for creating good
> abstractions. That expressiveness has its trade-offs. I do think the
> costs of expressive and complex languages can very much be worth it
> for many different kinds of projects. A rule of thumb may be that a
> language that is expressive and complex, may allow writing programs
> that are simpler relative to if those programs were written in a
> simpler and less expressive language. But one should research and be
> aware that there are trade-offs for a language being expressive and
> complex. In a simplistic view, a language designer will try to
> maximize the benefits from expressiveness of a complex language, and
> try to minimize the costs of that expressiveness and complexity.
> 
> Rust stands out due to its lifetimes and borrow checker, in addition
> to it being newer and having momentum.
> 
> What are the trade-offs of a more complex language? One trade-off is
> that implementing a compiler for the language can be a larger and more
> difficult undertaking than if the language was simpler. As an example,
> to date, there is only one major Rust compiler, rustc, while gccrs is
> not yet ready. Another example is that it can be more difficult to
> ensure high quality of a compiler for a complex language than for a
> simpler language.

I also point out that the way Rust and C++ implement generics
using monomorphization has a substantial cost in terms of
compile time and code size.

Martin