linux-kernel - Re: [PATCH 4/4] build: rust: provide an option to inline C helpers into Rust

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAGSQo01Am_rNeZqnqZU3hY7SwWG=dTHtzcksPSHUTiasgex+cA@mail.gmail.com>
Date: Thu, 4 Dec 2025 11:29:13 -0800
From: Matthew Maurer <mmaurer@...gle.com>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Alice Ryhl <aliceryhl@...gle.com>, Emilio Cobos Álvarez <emilio@...sal.io>, 
	Miguel Ojeda <miguel.ojeda.sandonis@...il.com>, Antoni Boucher <bouanto@...o.com>, 
	Arthur Cohen <arthur.cohen@...ecosm.com>, Gary Guo <gary@...yguo.net>, 
	Josh Triplett <josh@...htriplett.org>, Miguel Ojeda <ojeda@...nel.org>, 
	Boqun Feng <boqun.feng@...il.com>, Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Benno Lossin <lossin@...nel.org>, Andreas Hindborg <a.hindborg@...nel.org>, 
	Trevor Gross <tmgross@...ch.edu>, Danilo Krummrich <dakr@...nel.org>, 
	Alexandre Courbot <acourbot@...dia.com>, Will Deacon <will@...nel.org>, 
	Mark Rutland <mark.rutland@....com>, Nathan Chancellor <nathan@...nel.org>, 
	Nick Desaulniers <nick.desaulniers+lkml@...il.com>, Bill Wendling <morbo@...gle.com>, 
	Justin Stitt <justinstitt@...gle.com>, Nicolas Schier <nicolas.schier@...ux.dev>, 
	Andrew Morton <akpm@...ux-foundation.org>, Uladzislau Rezki <urezki@...il.com>, 
	rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org, 
	llvm@...ts.linux.dev, linux-kbuild@...r.kernel.org, linux-mm@...ck.org, 
	nouveau@...ts.freedesktop.org
Subject: Re: [PATCH 4/4] build: rust: provide an option to inline C helpers
 into Rust

On Thu, Dec 4, 2025 at 6:27 AM Peter Zijlstra <peterz@...radead.org> wrote:
>
> On Thu, Dec 04, 2025 at 01:15:34PM +0000, Alice Ryhl wrote:
> > On Thu, Dec 04, 2025 at 01:49:28PM +0100, Emilio Cobos Álvarez wrote:
> > > On 12/4/25 12:57 PM, Miguel Ojeda wrote:
> > > > On Thu, Dec 4, 2025 at 12:11 PM Peter Zijlstra <peterz@...radead.org> wrote:
> > > > >
> > > > > Right. Earlier I also proposed using libclang to parse the C header and
> > > > > inject that. This might be a little simpler, in that..
> > > >
> > > > Yeah, that would be closer to the `bindgen` route in that `libclang`
> > > > gets already involved.
> > >
> > > Yeah, so... there are existing tools (c2rust [0] being the actively
> > > maintained one IIUC) that in theory could do something like that (translate
> > > the bodies of the functions from C to Rust so that rustc could consume them
> > > directly rather than via LLVM LTO).
> > >
> > > I think the intended use case is more "translate a whole C project into
> > > rust", but it could be interesting to test how well / poorly it performs
> > > with the kernel helpers / with a single header translated to Rust.
> > >
> > > I personally haven't tried it because for work I need to deal with C++,
> > > which means that automatic translation to Rust is a lot harder / probably
> > > impossible in general. So for Firefox we end up relying on bindgen +
> > > cross-language LTO for this kind of thing, and it works well for us.
> > >
> > > If I'm understanding correctly, it seems the kernel needs this extra bit of
> > > help (__always_inline) to push LLVM to inline C functions into rust, which
> > > is a bit unfortunate... But this approach seems sensible to me, for now at
> > > least.
> > >
> > > FWIW Bindgen recently gained an option to generate inline functions [1],
> > > which could help avoid at least the bindgen ifdef in the patch series?
> > >
> > > Anyways, it might be interesting to give c2rust a go on the kernel helpers
> > > if nobody has done so, and see how well / poorly it works in practice? Of
> > > course probably introducing a new dependency would be kind of a pain, but
> > > could be a good data point for pushing into adding something like it built
> > > into rustc...
> >
> > I already tried c2rust as an alternative to this patch. It works okay
> > for many functions, but it's missing support for some features such as
> > asm goto, though this is fixable. But a larger issue is that some things
> > simply do not translate to Rust right now. For example:
> >
> > * Atomics use the Ir operand.
> > * static_branch uses the i operand.
> >
> > neither of which translate directly to Rust.

I took a shot at `c2rust` as well, the summary was that `c2rust` was missing:
* Asm goto support
* __builtin_types_compatible_p
* Deduced types
* __count
* _Generic

I was adding hacky implementations along the way to see if things
could be made to work, but the %l and %i missing in Rust itself that
Alice pointed out were not things that could really be worked around.

I also think that the bitcode-based approach is more future proof -
the kernel may pick up new C features that `c2rust` hasn't yet learned
about. If `clang` is in charge of generating the bitcode for the
to-be-inlined helpers, we don't risk any desync in terms of what
features are supported either by `c2rust` or by `rustc` relative to
what's in use by the rest of the kernel.

>
> Right this. AFAIK Rust simply does not have feature parity with inline
> asm. Them having picked a wildly different syntax for inline asm didn't
> help either of course. But Rust is Rust, must have terrible syntax :-)