linux-kernel - Re: [PATCH 2/4] rust: helpers: #define __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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <875x9diqwj.fsf@t14s.mail-host-address-is-not-set>
Date: Wed, 07 Jan 2026 12:49:32 +0100
From: Andreas Hindborg <a.hindborg@...nel.org>
To: Alice Ryhl <aliceryhl@...gle.com>, Miguel Ojeda <ojeda@...nel.org>
Cc: Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
 Björn
 Roy Baron <bjorn3_gh@...tonmail.com>, Benno Lossin <lossin@...nel.org>,
 Trevor Gross <tmgross@...ch.edu>, Danilo Krummrich <dakr@...nel.org>,
 Alexandre Courbot <acourbot@...dia.com>, Will Deacon <will@...nel.org>,
 Peter Zijlstra <peterz@...radead.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, Alice Ryhl <aliceryhl@...gle.com>
Subject: Re: [PATCH 2/4] rust: helpers: #define __rust_helper

Alice Ryhl <aliceryhl@...gle.com> writes:

> From: Gary Guo <gary@...yguo.net>
>
> Because of LLVM inling checks, it's generally not possible to inline a C
> helper into Rust code, even with LTO:
>
> * LLVM doesn't want to inline functions compiled with
>   `-fno-delete-null-pointer-checks` with code compiled without. The C
>   CGUs all have this enabled and Rust CGUs don't. Inlining is okay since
>   this is one of the hardening features that does not change the ABI,
>   and we shouldn't have null pointer dereferences in these helpers.
>
> * LLVM doesn't want to inline functions with different list of builtins. C
>   side has `-fno-builtin-wcslen`; `wcslen` is not a Rust builtin, so
>   they should be compatible, but LLVM does not perform inlining due to
>   attributes mismatch.
>
> * clang and Rust doesn't have the exact target string. Clang generates
>   `+cmov,+cx8,+fxsr` but Rust doesn't enable them (in fact, Rust will
>   complain if `-Ctarget-feature=+cmov,+cx8,+fxsr` is used). x86-64
>   always enable these features, so they are in fact the same target
>   string, but LLVM doesn't understand this and so inlining is inhibited.
>   This can be bypassed with `--ignore-tti-inline-compatible`, but this
>   is a hidden option.
>
> To fix this, we can add __always_inline on every helper, which skips
> these LLVM inlining checks. For this purpose, introduce a new
> __rust_helper macro that needs to be added to every helper.
>
> The actual additions of __rust_helper can happen in separate patches. A
> "flag day" change is not required since missing annotations do not lead
> to anything worse than missing inlining.
>
> Signed-off-by: Gary Guo <gary@...yguo.net>
> Signed-off-by: Alice Ryhl <aliceryhl@...gle.com>

Reviewed-by: Andreas Hindborg <a.hindborg@...nel.org>


Best regards,
Andreas Hindborg