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: <CANiq72nDcXrSo79-nsM_Cu-npoVirksiRpPYJiPrcsB5OEVQag@mail.gmail.com>
Date: Fri, 21 Feb 2025 00:47:12 +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 Thu, Feb 20, 2025 at 5:03 PM James Bottomley
<James.Bottomley@...senpartnership.com> wrote:
>
> OK, this is just a terminology difference.  I think of bindings as the
> glue that sits between two pieces of code trying to interact.  In your
> terms that's both the abstractions and the bindgen bindings.

Ah, got it, thanks. I was confused by the "headers" bit, because I
didn't know if you were referring to the C ones or the Rust "headers".

> You say that like it's easy ... I think most people who work in the
> kernel wouldn't know how to do this.

Yeah, in the general case, one needs to know Rust and how the safe
abstraction is designed. I only meant in simple cases like the "gains
a parameter" I was giving as an example.

> I'm under no illusion that this would be easy, but if there were a way
> of having all the information required in the C code in such a way that
> something like an extended sparse could check it (so if you got the
> annotations wrong you'd notice) and an extended bindgen could generate
> both the bindings and the abstractions from it, it would dramatically
> reduce the friction the abstractions cause in kernel API updates.

Yeah, it would definitely be amazing to have. Nevertheless, I think
annotating C headers is still something we should do as much as
reasonably possible, even if it does not lead to full generation. Even
if Rust was not a thing, it would also be helpful for the C side on
its own.

> Yes, I think it does, thanks.

You're welcome!

Cheers,
Miguel