linux-kernel - Re: [RFC PATCH 2/2] kbuild: rust: use klint to provide CONFIG_FRAME

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] [day] [month] [year] [list]

Message-Id: <DG0NZIBS97TA.1C8VH8IUQGR3B@garyguo.net>
Date: Thu, 29 Jan 2026 00:59:13 +0000
From: "Gary Guo" <gary@...yguo.net>
To: "Nathan Chancellor" <nathan@...nel.org>, "Gary Guo" <gary@...yguo.net>
Cc: "Alexandre Courbot" <acourbot@...dia.com>, "Gary Guo" <gary@...nel.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>, "Alice
 Ryhl" <aliceryhl@...gle.com>, "Trevor Gross" <tmgross@...ch.edu>, "Danilo
 Krummrich" <dakr@...nel.org>, "Nicolas Schier" <nsc@...nel.org>,
 Thomas Weißschuh <linux@...ssschuh.net>, "Masahiro Yamada"
 <masahiroy@...nel.org>, "Kees Cook" <kees@...nel.org>,
 <rust-for-linux@...r.kernel.org>, <linux-kbuild@...r.kernel.org>,
 <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH 2/2] kbuild: rust: use klint to provide
 CONFIG_FRAME_WARN

On Wed Jan 28, 2026 at 10:02 PM GMT, Nathan Chancellor wrote:
> On Wed, Jan 28, 2026 at 01:14:27AM +0000, Gary Guo wrote:
>> It might be possible to do more detailed analysis by checking what is using the
>> stack (e.g. perhaps recovery variable -> stack slots using DWARF if full
>> debuginfo is enabled, or find out the instruction that first touches the
>
> Yeah Nick wrote a Python script to use debug info to give a better idea
> of stack usage to help us debug these warnings from clang:
>
>   https://github.com/ClangBuiltLinux/frame-larger-than

Tried to run this on nova-core.o, but it didn't print anything apart from
function name.

I've made this change to allow it to recognize mangled names but this doesn't
seem to be sufficient:

---
@@ -58,7 +58,9 @@
 
 
 def get_name(DIE):
-    if 'DW_AT_name' in DIE.attributes:
+    if 'DW_AT_linkage_name' in DIE.attributes:
+        return DIE.attributes['DW_AT_linkage_name'].value.decode('UTF-8')
+    elif 'DW_AT_name' in DIE.attributes:
         return DIE.attributes['DW_AT_name'].value.decode('UTF-8')
     else:
         return '{anonymous}'
---

Looking at the LoC it doesn't seem to be too complicated so I could potentially
integrate some similar into klint. But as you said, it's hacky.

>
> It is rather hacky and feels like there are a number of corner cases
> where things don't look quite right but it is better than nothing.
>
>> specific stack location and map it back like that), but doing so is quite tricky
>> and the marginal benefit is less than pointing out there's an issue to be
>> investigated in the first place.
>
> Does Rust have the equivalent of '-Rpass-analysis' from clang? There was
> '-Rpass-analysis=stack-frame-layout' that was added in LLVM 16:

No, Rust doesn't expose such mechanism. As a matter of fact, klint is backend
agnostic so in theory it is supposed to work with rustc_codegen_gcc, too.

So far I don't have plan on adding LLVM specific analyses as doing so is quite
tricky with the modular backend design in Rust (I would effectively need to
replace the entire codegen backend with a patched rustc_codegen_llvm).

Best,
Gary

>
>   https://github.com/llvm/llvm-project/commit/557a5bc336ffb9b03c53d4d13fd8f0bc9418ec96
>
> I assume that could be used from Rust as well since it is in the LLVM
> backend? It does not necessarily show exactly where the stack usage
> comes from aside from variables and spills but still, some information
> (especially accurate information at this level) is better than nothing.
>
> Cheers,
> Nathan