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: <20250219170623.GB1789203@mit.edu>
Date: Wed, 19 Feb 2025 12:06:23 -0500
From: "Theodore Ts'o" <tytso@....edu>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: James Bottomley <James.Bottomley@...senpartnership.com>,
        Christoph Hellwig <hch@...radead.org>,
        rust-for-linux <rust-for-linux@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Greg KH <gregkh@...uxfoundation.org>, David Airlie <airlied@...il.com>,
        linux-kernel@...r.kernel.org, ksummit@...ts.linux.dev
Subject: Re: Rust kernel policy

On Wed, Feb 19, 2025 at 05:44:16PM +0100, Miguel Ojeda wrote:
> Hmm... I am not sure exactly what you mean here. Are you referring to
> Wedson's FS slides from LSF/MM/BPF? i.e are you referring to Rust
> signatures?
> 
> If yes, those signatures are manually written, they are not the
> generated bindings. We typically refer to those as "abstractions", to
> differentiate from the generated stuff.

The problem with the bindings in Wedson's FS slides is that it's
really unreasonable to expect C programmers to understand them.  In my
opinion, it was not necessarily a wise decision to use bindings as
hyper-complex as a way to convince C developers that Rust was a net
good thing.

I do understand (now) what Wedson was trying to do, was to show off
how expressive and powerful Rust can be, even in the face of a fairly
complex interface.  It turns out there were some good reasons for why
the VFS handles inode creation, but in general, I'd encourage us to
consider whether there are ways to change the abstractions on the C
side so that:

   (a) it makes it easier to maintain the Rust bindings, perhaps even
       using automatically generation tools,
   (b) it allows Rust newbies having at least some *hope* of updating
       the manually maintained bindings,
   (c) without causing too much performance regressions, especially
       on hot paths, and
   (d) hopefully making things easier for new C programmers from
       understanding the interface in question.

So it might not be that increasing C safety isn't the primary goal, in
general, one of the ways that we evaluate a particular patchset is
whether addresses multiple problems at the same time.  If it does,
that's a signal that perhaps it's the right direction for us to go.

Cheers,

						- Ted