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

Message-ID: <CAGSQo03+pVhjyfSLGHHcr=w1-3=C5AcEKJf-GbcEvfJ6NTid7g@mail.gmail.com>
Date: Tue, 16 Dec 2025 14:13:08 -0800
From: Matthew Maurer <mmaurer@...gle.com>
To: Bjorn Andersson <andersson@...nel.org>
Cc: 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>, 
	Danilo Krummrich <dakr@...nel.org>, 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 Tue, Dec 16, 2025 at 1:53 PM Bjorn Andersson <andersson@...nel.org> wrote:
>
> On Tue, Dec 16, 2025 at 12:53:28PM -0800, Matthew Maurer wrote:
> > On Tue, Dec 16, 2025 at 12:49 PM Bjorn Andersson <andersson@...nel.org> wrote:
> > >
> > > On Sat, Dec 13, 2025 at 12:36:00AM +0000, Matthew Maurer wrote:
> > > > Re-implements qcom-socinfo driver in Rust, using `Scoped`-based DebugFS
> > > > bindings.
> > >
> > > Okay, but why?
> > >
> > > https://docs.kernel.org/process/submitting-patches.html#describe-your-changes
> > >
> > > [..]
> >
> > I'll move more of the text from the cover letter into the commit
> > message, but the short version is that it's intended to be a low-risk
> > driver to pilot vendor drivers in Android.
> >
>
> The answers I'm looking for isn't in your cover letter either. I want to
> know what benefits Rust provides in this particular case.
>

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.

The primary intention of converting this driver is to be a low risk
trial for GKI's ABI stability for vendor modules and a first Rust
vendor module (we have platform modules already for binder and ashmem)
on Android. This was discussed informally with Trilok (a long time
ago) to act as an example for other vendor drivers and encourage usage
of Rust for new drivers or those where memory safety has been a
problem in the past, but nothing was ever formally committed to.
Trying to apply Rust to more significant existing modules (where it
would provide a greater benefit) raises concern about whether they
will operate identically. Socinfo in particular can be more thoroughly
tested for equivalency, as aside from the runtime DSP information
modification that was mentioned in this discussion, the output of the
socinfo driver is static and can just be checked. This means that a
socinfo driver swap will essentially have the language change be the
*only* significant thing about the change, keeping the risk to a
minimum.

Part of the reason for the RFC prefix on this patch is to solicit your
feedback on whether you are open to this. If you have somewhere else
you'd prefer we try this, I'd be open to that as well.

> > >
> > > > ---
> > > > base-commit: 4b31c90f86768367c84cc6e99e1deee0ec55197b
> > > > change-id: 20251029-qcom-socinfo-d8387c7fdb1c
> > > > prerequisite-change-id: 20251029-soc-bindings-9b0731bcdbed:v1
> > > > prerequisite-patch-id: e4da423ddabec93bd9a64004691266f9b740e0c5
> > > > prerequisite-patch-id: 5097ff622f8cb1d38354674cf70c1c946ac87f6c
> > > > prerequisite-change-id: 20251029-add-entropy-f57e12ebe110:v1
> > > > prerequisite-patch-id: 657de204912d2c5efff9898d3f4c51e52684d8e6
> > > > prerequisite-change-id: 20251212-transmute-8ab6076700a8:v1
> > > > prerequisite-patch-id: 4f5f7cb002d02d232083ab5c3ce6b3cb90650bd6
> > > > prerequisite-patch-id: 01a1f3d727e549c173dd142180741f5b6a3c866e
> > > > prerequisite-patch-id: ff801a7ae439876b1554b4d1132d94c825bbe74f
> > >
> > > So, it doesn't work on a clean v6.19-rc1 tree?
> >
> > Correct. Those other patchsets are patchsets I'm landing which add
> > bindings used in this one.
> >
>
> Okay, please make that explicit when submitting patches, so that the
> maintainers know that your patch(es) can't be merged.

I thought that was what I had done by using the combination of "RFC"
and putting the prerequisite change IDs from b4, but I will include a
statement to that effect in my cover letter in the future.

>
> Regards,
> Bjorn
>
> > >
> > > Regards,
> > > Bjorn
> > >
> > > >
> > > > Best regards,
> > > > --
> > > > Matthew Maurer <mmaurer@...gle.com>
> > > >