linux-kernel - Re: [PATCH v2 6/6] soc: qcom: socinfo: Convert to 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: <DG5H119NY68Q.TWLCK3W36CM5@kernel.org>
Date: Tue, 03 Feb 2026 17:35:24 +0100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>
Cc: "Matthew Maurer" <mmaurer@...gle.com>, "Bjorn Andersson"
 <andersson@...nel.org>, "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>, "Daniel Almeida"
 <daniel.almeida@...labora.com>, "Rafael J. Wysocki" <rafael@...nel.org>,
 "David Airlie" <airlied@...il.com>, "Simona Vetter" <simona@...ll.ch>,
 "Michal Wilczynski" <m.wilczynski@...sung.com>, "Dave Ertman"
 <david.m.ertman@...el.com>, "Ira Weiny" <ira.weiny@...el.com>, "Leon
 Romanovsky" <leon@...nel.org>, "Trilok Soni" <tsoni@...cinc.com>,
 <linux-kernel@...r.kernel.org>, <linux-arm-msm@...r.kernel.org>,
 <rust-for-linux@...r.kernel.org>, <driver-core@...ts.linux.dev>,
 <dri-devel@...ts.freedesktop.org>, <linux-pwm@...r.kernel.org>
Subject: Re: [PATCH v2 6/6] soc: qcom: socinfo: Convert to Rust

On Tue Feb 3, 2026 at 5:28 PM CET, Greg Kroah-Hartman wrote:
> On Tue, Feb 03, 2026 at 03:46:35PM +0000, Matthew Maurer wrote:
>> +impl Smem {
>> +    pub(crate) fn access<'a>(&'a self, dev: &'a Device<Bound>) -> Option<&'a Mmio> {
>> +        if *dev != *self.dev {
>
> How can this ever happen?

You are right, since this resource is local to the driver, it should not be
possible to have another devce from somewhere else (especially not a
&Device<Bound>).

However, from a Rust perspective I think not having this check would be unsound,
as the method by itself would not be able guarantee correct behavor anymore.