netdev - Re: [PATCHSET][RFC] struct fd and memory safety

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: <20240806185628.GR5334@ZenIV>
Date: Tue, 6 Aug 2024 19:56:28 +0100
From: Al Viro <viro@...iv.linux.org.uk>
To: Jason Gunthorpe <jgg@...pe.ca>
Cc: linux-fsdevel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Christian Brauner <brauner@...nel.org>, bpf@...r.kernel.org,
	Amir Goldstein <amir73il@...il.com>, kvm@...r.kernel.org,
	cgroups@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCHSET][RFC] struct fd and memory safety

On Tue, Aug 06, 2024 at 02:58:59PM -0300, Jason Gunthorpe wrote:
> On Tue, Jul 30, 2024 at 06:09:27AM +0100, Al Viro wrote:
> 
> > 	* ib_uverbs_open_xrcd().  FWIW, a closer look shows that the
> > damn thing is buggy - it accepts _any_ descriptor and pins the associated
> > inode.  mount tmpfs, open a file there, feed it to that, unmount and
> > watch the show...
> 
> What happens? There is still an igrab() while it is in the red black
> tree?

... which does not render the mount busy.

> > AFAICS, that's done for the sake of libibverbs and
> > I've no idea how it's actually used - all examples I'd been able to
> > find use -1 for descriptor here.  Needs to be discussed with infiniband
> > folks (Sean Hefty?).  For now, leave that as-is.
> 
> The design seems insane, but it is what it is from 20 years ago..
> 
> Userspace can affiliate this "xrc domain" with a file in the
> filesystem. Any file. That is actually a deliberate part of the API.
> 
> This is done as some ugly way to pass xrc domain object from process A
> to process B. IIRC the idea is process A will affiliate the object
> with a file and then B will be able to access the shared object if B
> is able to open the file.
> 
> It looks like the code keeps a red/black tree of this association, and
> holds an igrab while the inode is in that tree..

You need a mount (or file) reference to prevent fs destruction by umount.
igrab() pins an _inode_, but the caller must arrange for the hosting
filesystem to stay alive.