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: <20260203135955.GB12013@killaraus>
Date: Tue, 3 Feb 2026 15:59:55 +0200
From: Laurent Pinchart <laurent.pinchart@...asonboard.com>
To: Maxime Ripard <mripard@...nel.org>
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"

On Tue, Feb 03, 2026 at 10:10:57AM +0100, Maxime Ripard wrote:
> 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.

Preventing new ioctls (and other fops) from being called isn't
difficult, they can be blocked at the entry point, outside of the
driver. In-progress ioctls running in other threads can also be forced
to complete before .remove() frees all memory. I think this is the right
thing to do.

The only fop that we can't completely prevent from running is
.release(), as we can't wait until userspace closes all file handles and
unmaps all memory before .remove() completes. There are solutions for
that.

-- 
Regards,

Laurent Pinchart