linux-kernel - Re: [PATCH 0/3] Revert "revocable: Revocable resource management"

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: <20260203-lyrical-taipan-of-enhancement-df5615@houat>
Date: Tue, 3 Feb 2026 10:10:57 +0100
From: Maxime Ripard <mripard@...nel.org>
To: Laurent Pinchart <laurent.pinchart@...asonboard.com>
Cc: Danilo Krummrich <dakr@...nel.org>, Jason Gunthorpe <jgg@...dia.com>, 
	Bartosz Golaszewski <bartosz.golaszewski@....qualcomm.com>, Johan Hovold <johan@...nel.org>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, "Rafael J . Wysocki" <rafael@...nel.org>, 
	Tzung-Bi Shih <tzungbi@...nel.org>, Linus Walleij <linusw@...nel.org>, 
	Jonathan Corbet <corbet@....net>, Shuah Khan <shuah@...nel.org>, 
	Wolfram Sang <wsa+renesas@...g-engineering.com>, Simona Vetter <simona.vetter@...ll.ch>, 
	Dan Williams <dan.j.williams@...el.com>, linux-doc@...r.kernel.org, linux-kselftest@...r.kernel.org, 
	linux-kernel@...r.kernel.org, Bartosz Golaszewski <brgl@...nel.org>, 
	maarten.lankhorst@...ux.intel.com, tzimmermann@...e.de
Subject: Re: [PATCH 0/3] Revert "revocable: Revocable resource management"

Hi,

On Fri, Jan 30, 2026 at 11:10:49AM +0200, Laurent Pinchart wrote:
> On Thu, Jan 29, 2026 at 11:29:03PM +0100, Danilo Krummrich wrote:
> > (Cc: Maxime, Thomas, Maarten)
> > 
> > On Thu Jan 29, 2026 at 2:08 AM CET, Laurent Pinchart wrote:
> > > That's what I've been advocating for. The best way to ensure that driver
> > > code will not accessed data freed at .remove() time is to prevent the
> > > code to run at all.
> > 
> > With this we are in full agreement, I think that'd be best too. But, I also
> > think that sometimes this isn't possible. For instance, DRM has such a case with
> > atomic mode setting.
> 
> I don't see why it would be impossible there.

I'm not quite sure what you have in mind there, but DRM always allowed
the DRM driver to stick around longer than its device to accomodate the
fact that userspace might still have an open fd to it.

If userspace has an open fd, it can still call ioctl so preventing to
run any code is going to be difficult.

Maxime

Download attachment "signature.asc" of type "application/pgp-signature" (274 bytes)