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: <1f52fa44062e9395d54ed6733780aea0830ee6a5.camel@HansenPartnership.com>
Date: Thu, 20 Feb 2025 07:56:46 -0500
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, 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, 2025-02-19 at 22:48 -0800, Christoph Hellwig wrote:
> On Wed, Feb 19, 2025 at 11:03:28AM -0500, James Bottomley wrote:
> > > This has come up a few times, and we indeed would like to have
> > > some annotations in the C headers so that we can generate more
> > > (and to keep the information local).
> > > 
> > > For instance, it would be nice to have bindgen's `__opaque` near
> > > the C items, or being able to mark functions as `__safe`, or to
> > > have other `enum`s-related annotations, or even custom
> > > attributes, as well as "formatted-formally-enough" docs so that
> > > can be rendered properly on the Rust side, or even
> > > references/lifetimes with an eventual "Safe C"-like approach, and
> > > so on and so forth.
> > > 
> > > However, even if we automate more and even reach a point where
> > > most C APIs are e.g. "safe" (which would be great),
> > 
> > I wouldn't say C API safety would be the main goal, although it
> > might be a nice add on feature.
> 
> Why not?  Why is safety suddenly less a goal when you don't use the
> right syntactic sugar?

Well a) because of the way C works, I don't believe you can get memory
safety with just header annotations and b) even if we got safe C it
still doesn't fix the unstable API propagation to rust problem, which
is why I don't think it should be a goal in a project aiming to fix the
unstable API issue. If we got it, I'd like it, which is why I listed it
as a nice add on feature.

Regards,

James