linux-kernel - Re: [RFC PATCH 1/5] misc: introduce FDBox

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: <20250318145707.GX9311@nvidia.com>
Date: Tue, 18 Mar 2025 11:57:07 -0300
From: Jason Gunthorpe <jgg@...dia.com>
To: Christian Brauner <brauner@...nel.org>
Cc: Pratyush Yadav <ptyadav@...zon.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, Jonathan Corbet <corbet@....net>,
	Eric Biederman <ebiederm@...ssion.com>,
	Arnd Bergmann <arnd@...db.de>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Alexander Viro <viro@...iv.linux.org.uk>, Jan Kara <jack@...e.cz>,
	Hugh Dickins <hughd@...gle.com>, Alexander Graf <graf@...zon.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	David Woodhouse <dwmw2@...radead.org>,
	James Gowans <jgowans@...zon.com>, Mike Rapoport <rppt@...nel.org>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Pasha Tatashin <tatashin@...gle.com>,
	Anthony Yznaga <anthony.yznaga@...cle.com>,
	Dave Hansen <dave.hansen@...el.com>,
	David Hildenbrand <david@...hat.com>,
	Matthew Wilcox <willy@...radead.org>,
	Wei Yang <richard.weiyang@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-fsdevel@...r.kernel.org, linux-doc@...r.kernel.org,
	linux-mm@...ck.org, kexec@...ts.infradead.org
Subject: Re: [RFC PATCH 1/5] misc: introduce FDBox

On Tue, Mar 18, 2025 at 03:25:25PM +0100, Christian Brauner wrote:

> > It is not really a stash, it is not keeping files, it is hardwired to
> 
> Right now as written it is keeping references to files in these fdboxes
> and thus functioning both as a crippled high-privileged fdstore and a
> serialization mechanism. 

I think Pratyush went a bit overboard on that, I can see it is useful
for testing, but really the kho control FD should be in either
serializing or deserializing mode and it should not really act as an
FD store.

However, edge case handling makes this a bit complicated. 

Once a FD is submitted to be serialized that FD has to be frozen and
can't be allowed to change anymore.

If the kexec process aborts then we need to unwind all of this stuff
and unfreeze all the FDs.

It sure would be nice if the freezing process could be managed
generically somehow.

One option for freezing would have the kernel enforce that userspace
has closed and idled the FD everywhere (eg check the struct file
refcount == 1). If userspace doesn't have access to the FD then it is
effectively frozen.

In this case the error path would need to bring the FD back out of the
fdbox.

Jason