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: <CANiq72nnnOsGZDrPDm8iWxYn2FL=wJqx-P8aS63dFYez3_FEOg@mail.gmail.com>
Date: Wed, 19 Feb 2025 16:08:30 +0100
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: James Bottomley <James.Bottomley@...senpartnership.com>
Cc: 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 3:05 PM James Bottomley
<James.Bottomley@...senpartnership.com> wrote:
>
> So here's a proposal to fix this: could we not annotate the C headers
> with the API information in such a way that a much improved rust
> bindgen can simply generate the whole cloth API binding from the C
> code?  We would also need an enhanced sparse like tool for C that
> checked the annotations and made sure they got updated.  Something like
> this wouldn't solve every unintentional rust build break, but it would
> fix quite a few of them.  And more to the point, it would allow non-
> rust developers to update the kernel API with much less fear of
> breaking rust.

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), it wouldn't prevent
breakage -- the C APIs would still need to be stable enough so that
you don't break callers, including C ones. It would still be great to
have that information formally expressed, though, of course, and it
would help maintain the Rust side.

We have also discussed at times is documenting the C side more, e.g.
the pre/post/invariants we use on the Rust side. That would be useful
for the C side to know something is being relied upon from Rust (and
other C callers) and for the Rust side to document why something is
sound. Of course, it is a lot of work, and the more we can express as
code instead of as documentation, the better.

Cheers,
Miguel