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] [day] [month] [year] [list]

Message-ID: <CAFJgqgSCW9XbVYr7yTa47Miax+LGM9jNNE5Yuw1xQE2BZ9gkTQ@mail.gmail.com>
Date: Mon, 24 Feb 2025 02:08:45 -0700
From: Ventura Jack <venturajack85@...il.com>
To: comex <comexk@...il.com>
Cc: Piotr Masłowski <piotr@...lowski.xyz>, 
	Martin Uecker <uecker@...raz.at>, 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 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.  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.

Best, VJ.