linux-kernel - Re: [PATCH v5 5/7] revocable: Add fops replacement

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: <009c8e5e-02d3-4017-bb84-e3a8f01b9dc9@kernel.org>
Date: Fri, 17 Oct 2025 18:29:10 +0200
From: Danilo Krummrich <dakr@...nel.org>
To: Tzung-Bi Shih <tzungbi@...nel.org>
Cc: Jason Gunthorpe <jgg@...dia.com>, Benson Leung <bleung@...omium.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 "Rafael J . Wysocki" <rafael@...nel.org>, Jonathan Corbet <corbet@....net>,
 Shuah Khan <shuah@...nel.org>, linux-doc@...r.kernel.org,
 linux-kernel@...r.kernel.org, chrome-platform@...ts.linux.dev,
 linux-kselftest@...r.kernel.org,
 Laurent Pinchart <laurent.pinchart@...asonboard.com>,
 Bartosz Golaszewski <brgl@...ev.pl>,
 Wolfram Sang <wsa+renesas@...g-engineering.com>,
 Simona Vetter <simona.vetter@...ll.ch>,
 Dan Williams <dan.j.williams@...el.com>
Subject: Re: [PATCH v5 5/7] revocable: Add fops replacement

On 10/17/25 6:07 PM, Tzung-Bi Shih wrote:
> Imagining:
> - Driver X provides the res1.
> - Driver Y provides the res2.
> - Driver Z provides the chardev /dev/zzz.  The file operations use res1
>   and res2.
> - A userspace program opened /dev/zzz.
> 
> In the approach, what is .remove() of driver X supposed to do when driver X
> is unbinding (e.g. due to device unplug)?

There are use-cases for revocable, but this example is a bit too generic:

Drivers don't just share device resources with other random drivers, they
usually have a defined relationship through a bus.

For instance, if you have a driver on the platform bus and another driver
connected through the auxiliary bus, there is a defined lifetime: The auxiliary
device has to be unbound before its parent device.

This means that as long as you are in a scope where your auxiliary device is
bound, it is safe to use a device resource from that parent without further checks.

The goal should always be to proof to be in such a scope when accessing device
resources (in Rust we can let the compiler ensure this at compile time :).

However, there are rare (yet valid) cases where such a scope can't be
guaranteed. DRM has such cases, and, unfortunately, MISC device seems to be
another one.

I know the reasons why DRM has to have this design, I'm not sure about MISC
device though. Unless there's a good reason, I think MISC device should be
"fenced" instead.