linux-kernel - Re: [RFC PATCH 2/2] kbuild: 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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20240612172623.5876d0ad@eugeo>
Date: Wed, 12 Jun 2024 17:26:22 +0100
From: Gary Guo <gary@...yguo.net>
To: Matthew Maurer <mmaurer@...gle.com>
Cc: Masahiro Yamada <masahiroy@...nel.org>, Nathan Chancellor
 <nathan@...nel.org>, Nicolas Schier <nicolas@...sle.eu>, Andrew Morton
 <akpm@...ux-foundation.org>, Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor
 <alex.gaynor@...il.com>, Wedson Almeida Filho <wedsonaf@...il.com>, Boqun
 Feng <boqun.feng@...il.com>, Björn Roy Baron
 <bjorn3_gh@...tonmail.com>, Benno Lossin <benno.lossin@...ton.me>, Andreas
 Hindborg <a.hindborg@...sung.com>, Alice Ryhl <aliceryhl@...gle.com>, Nick
 Desaulniers <ndesaulniers@...gle.com>, Bill Wendling <morbo@...gle.com>,
 Justin Stitt <justinstitt@...gle.com>, linux-kbuild@...r.kernel.org,
 linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org,
 llvm@...ts.linux.dev
Subject: Re: [RFC PATCH 2/2] kbuild: rust: provide an option to inline C
 helpers into Rust

On Fri, 7 Jun 2024 07:40:45 -0700
Matthew Maurer <mmaurer@...gle.com> wrote:

> The LLVM `.ll` textual bitcode representation may change from version
> to version, which makes using `sed` to edit it potentially fragile.
> Would it be possible to attach similar attributes without this? (Or
> other attributes that can accomplish something similar, see the second
> part.)

I agree that text editing is fragile and should be avoided, but I'm not
aware of a way to achieve this without text editing.

> Would it be possible to use a Rust-only-LTO (actual LTO) flag rather
> than a `llvm-link`? It seems likely that someone that wants to use a
> synced `clang` and `rustc` to allow helpers to be inlined would be
> unlikely to object to thin LTO of Rust. This would avoid introducing a
> new tool.

There's no way for rustc to actually perform the LTO, since the crate
type that we use is rlib rather than staticlibs or cdylibs, Rust does
not take care of the linking.

> As one possible route around editing the `.ll` file, we could consider
> *not* hiding these symbols, just marking them as "good idea to inline
> if possible", and then masking any symbol that ends up in the final
> `.o` via `objcopy --localize-symbol=blah`. If we're doing full-kernel
> LTO rather than rust-only LTO, we'd need to use `llvm-objcopy`
> instead, but the same process would follow - a postprocessing step on
> the final crate object that localizes the symbol, with LTO giving the
> compiler the option (but not requirement) to inline these functions if
> it seems like a good idea.

This was one of the approach that I considered, but IIUC objcopy
require you to supply it a list of exact-match symbols rather than
patterns, so we have to get all helper symbols and then feed it to
objcopy. I really want to avoid having a script or host program to do
this step.

Best,
Gary