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: <DFZTOMSDPOQM.3QW4TZ52N4MKZ@garyguo.net>
Date: Wed, 28 Jan 2026 01:14:27 +0000
From: "Gary Guo" <gary@...yguo.net>
To: "Alexandre Courbot" <acourbot@...dia.com>, "Gary Guo" <gary@...nel.org>
Cc: "Miguel Ojeda" <ojeda@...nel.org>, "Boqun Feng" <boqun.feng@...il.com>,
 "Gary Guo" <gary@...yguo.net>, 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>,
 "Nathan Chancellor" <nathan@...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 12:31 AM GMT, Alexandre Courbot wrote:
> On Wed Jan 28, 2026 at 2:11 AM JST, Gary Guo wrote:
>> From: Gary Guo <gary@...yguo.net>
>>
>> klint is able to analyze frame size and warn on frames that are too big.
>>
>> With `register_tool(klint)` support, we can simply instruct rust to turn on
>> `klint::stack_frame_too_large`. This is a no-op if normal rustc (or Clippy)
>> is invoked, but will perform the check if klint is used.
>>
>> This is an example of a bug caught using this option:
>>
>> warning: stack size of `gsp::cmdq::Cmdq::new` is 8216 bytes, exceeds the 2048-byte limit
>>    --> drivers/gpu/nova-core/gsp/cmdq.rs:453:5
>>     |
>> 453 |     pub(crate) fn new(dev: &device::Device<device::Bound>) -> Result<Cmdq> {
>>     |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>     |
>>     = note: the stack size is inferred from instruction `sub $0x2018,%rsp` at .text+32778
>
> Initially this error puzzled me a bit since the objects directly built
> by Cmdq::new are not larger than ~40 bytes, but then I dug into the
> constructors it called and found that `PteArray`, a large struct, is
> built on the stack! We need to convert it to an `Init` I guess.
>
> Super valuable tool!

Yeah, I've already created a Zulip which mentions that the PTE array is likely
the root cause. This specific lint only concerns the final stack size and is not
aware of what's creating them.

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
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.

Best,
Gary