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: <CANiq72=O+sz0mU-urYmviCm55GL0jWzsbjAJviJpT+3MLmQSCA@mail.gmail.com>
Date: Fri, 21 Feb 2025 00:40:57 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: "Theodore Ts'o" <tytso@....edu>
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 6:06 PM Theodore Ts'o <tytso@....edu> wrote:
>
> 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.

Thanks for saying that.

> 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:

Definitely -- improving the C side (not just for Rust callers, but
also for C ones) would be great, whether that is with extra
annotations/extensions or redesigns.

In the beginning (pre-merge), we tried hard not to require changes on
the C side, because we wanted to show that it is possible to use Rust
(i.e. create safe abstractions for C APIs) even with minimal or no
changes to C headers. We thought it was a useful property.

But then we got C maintainers that welcomed improvements that would
benefit both sides, which was nice to see, and opens up some doors --
as a simple example, Greg added made some APIs `const`-correct so that
we got the right pointer type on the Rust bindings.

So, yeah, anything in that direction (that either improves the C side
and/or simplifies the Rust bindings/abstractions) would be great.

Cheers,
Miguel