linux-kernel - Re: [PATCH] rust: device: add platdata accessors

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: <DFJ5ICRD3YFF.XCSV3CJCDORA@kernel.org>
Date: Thu, 08 Jan 2026 11:55:09 +0100
From: "Danilo Krummrich" <dakr@...nel.org>
To: "pengfuyuan" <pengfuyuan@...inos.cn>
Cc: "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>, "Rafael J . Wysocki"
 <rafael@...nel.org>, "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>,
 <rust-for-linux@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] rust: device: add platdata accessors

On Thu Jan 8, 2026 at 9:55 AM CET, pengfuyuan wrote:
> Implement generic accessors for the platform data of a device.

As Greg already mentioned, please provide provide a user for the API. Even an
RFC is fine for me as long as it is not too far from an upstreamable state and
the corresponding subsystem maintainers show willingness to take the code.

> Platform data is typically set by platform code when creating the device
> and points to platform-specific data structures. The accessor provides
> type-safe access to this data without requiring unsafe code at the call
> site.

That seems wrong; at least with the current implementation this method is unsafe
for two reasons:

  (1) The caller has to assert that T is in fact the type of the data set by the
      platform code.

  (2) T is (most likely) a C type, which does not guarantee that it is valid to
      create a reference, i.e. &T, of. For instance, it might not be properly
      initialized.

I think (1) is not fixable (at least as long as the platform code is in C), so
it unfortunately has to be unsafe.

As for (2), I'd just return an &Opaque<T> instead and then have an FFI wrapper
in the driver.

> The accessor is implemented for Device<Bound>, allowing drivers to access
> platform data during probe() and other device lifecycle callbacks. Unlike
> drvdata, platform data is managed by platform code and has a lifetime
> tied to the device itself.

I don't think this accessor has to be on Device<Bound>, as you say platform data
is always valid.

- Danilo