linux-kernel - Re: [PATCH v3 5/6] objtool/rust: list `noreturn` Rust functions

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: <20240806202217.GZ37996@noisy.programming.kicks-ass.net>
Date: Tue, 6 Aug 2024 22:22:17 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Kees Cook <kees@...nel.org>
Cc: Miguel Ojeda <ojeda@...nel.org>, Josh Poimboeuf <jpoimboe@...nel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Masahiro Yamada <masahiroy@...nel.org>, x86@...nel.org,
	"H. Peter Anvin" <hpa@...or.com>,
	Nathan Chancellor <nathan@...nel.org>,
	Nicolas Schier <nicolas@...sle.eu>,
	Wedson Almeida Filho <wedsonaf@...il.com>,
	Alex Gaynor <alex.gaynor@...il.com>,
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
	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>, rust-for-linux@...r.kernel.org,
	linux-kernel@...r.kernel.org, patches@...ts.linux.dev
Subject: Re: [PATCH v3 5/6] objtool/rust: list `noreturn` Rust functions

On Tue, Aug 06, 2024 at 12:42:41PM -0700, Kees Cook wrote:
> On Thu, Jul 25, 2024 at 08:33:22PM +0200, Miguel Ojeda wrote:
> > Rust functions may be `noreturn` (i.e. diverging) by returning the
> > "never" type, `!`, e.g.
> > 
> >     fn f() -> ! {
> >         loop {}
> >     }
> > 
> > Thus list the known `noreturn` functions to avoid such warnings.
> > 
> > Without this, `objtool` would complain if enabled for Rust, e.g.:
> > 
> >     rust/core.o: warning: objtool:
> >     _R...9panic_fmt() falls through to next function _R...18panic_nounwind_fmt()
> > 
> >     rust/alloc.o: warning: objtool:
> >     .text: unexpected end of section
> > 
> > In order to do so, we cannot match symbols' names exactly, for two
> > reasons:
> > 
> >   - Rust mangling scheme [1] contains disambiguators [2] which we
> >     cannot predict (e.g. they may vary depending on the compiler version).
> > 
> >     One possibility to solve this would be to parse v0 and ignore/zero
> >     those before comparison.
> > 
> >   - Some of the diverging functions come from `core`, i.e. the Rust
> >     standard library, which may change with each compiler version
> >     since they are implementation details (e.g. `panic_internals`).
> > 
> > Thus, to workaround both issues, only part of the symbols are matched,
> > instead of using the `NORETURN` macro in `noreturns.h`.
> > 
> > Ideally, just like for the C side, we should have a better solution. For
> > instance, the compiler could give us the list via something like:
> > 
> >     $ rustc --emit=noreturns ...
> 
> Yeah, having added noreturns to objtool myself a few times, it'd be nice
> to have a way to make these manual lists go away some day.

So it would be fairly simple to make objtool consume a magic section
emitted by the compiler.. I think we've asked the compiler folks for
that at some point even, but I don't have clear recollections.