linux-kernel - Re: [PATCH RFC] soc: qcom: socinfo: Re-implement in 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] [day] [month] [year] [list]

Message-Id: <DF0PIORGZZ4L.30S2XEKT9V1D4@kernel.org>
Date: Wed, 17 Dec 2025 19:35:18 +0100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Bjorn Andersson" <andersson@...nel.org>
Cc: "Matthew Maurer" <mmaurer@...gle.com>, "Konrad Dybcio"
 <konradybcio@...nel.org>, "Satya Durga Srinivasu Prabhala"
 <satyap@...cinc.com>, "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>, "Trilok
 Soni" <tsoni@...cinc.com>, <linux-kernel@...r.kernel.org>,
 <linux-arm-msm@...r.kernel.org>, <rust-for-linux@...r.kernel.org>
Subject: Re: [PATCH RFC] soc: qcom: socinfo: Re-implement in Rust

On Wed Dec 17, 2025 at 12:13 AM CET, Bjorn Andersson wrote:
> On Tue, Dec 16, 2025 at 02:13:08PM -0800, Matthew Maurer wrote:
>> Rust likely does not provide any significant benefits for the socinfo
>> driver itself, aside from having caught the slight disconnect
>> (mentioned on the other thread) where it should probably be an
>> auxiliary device because it assumes that the `qcom-smem` device will
>> remain active as long as it does.

I want to highlight that this is an existing issue in the C driver that has been
caught in Rust by the language itself.

However, a Rust implementation of this driver ensures correctness for much more
potential pitfalls. For instance, the C debugfs infrastructure requires the user
to ensure that the exported data remains alive for the duration it is exposed
via debugfs. In Rust, it is not possible to violate this lifetime relationship
without producing a compile time error.

This is just one example, and I assume there are many more (I haven't read the
full patch). Maybe Matthew can chime in again and give some more examples.

Again I haven't read the full patch in detail, but it is obvious that is a
fairly trivial driver. Yet I think there is room bugs / mistakes that can be
caught by a Rust implementation.

>> 
>
> Yes, this isn't unique to Rust.

The auxiliary bus and the corresponding lifetime guarantees are not unique to
Rust. However, with Rust's type system and the corresponding implementation of
the driver model in Rust we can ensure (at compile time) that driver
implementations remain within the given boundaries of those lifetime guarantees.

This is a siginificant advantage -- violations of drivers using device resources
after device / driver unbind is a very common source of mistakes. Most of them
we can catch at compile time in Rust drivers.

- Danilo