linux-kernel - Re: [PATCH v5 40/40] 9p: Use netfslib read/write

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]

Date: Wed, 3 Jan 2024 13:52:53 -0600
From: Eric Van Hensbergen <ericvh@...nel.org>
To: Dominique Martinet <asmadeus@...ewreck.org>
Cc: David Howells <dhowells@...hat.com>, Jeff Layton <jlayton@...nel.org>,
	Steve French <smfrench@...il.com>,
	Matthew Wilcox <willy@...radead.org>,
	Marc Dionne <marc.dionne@...istor.com>,
	Paulo Alcantara <pc@...guebit.com>,
	Shyam Prasad N <sprasad@...rosoft.com>, Tom Talpey <tom@...pey.com>,
	Ilya Dryomov <idryomov@...il.com>,
	Christian Brauner <christian@...uner.io>, linux-cachefs@...hat.com,
	linux-afs@...ts.infradead.org, linux-cifs@...r.kernel.org,
	linux-nfs@...r.kernel.org, ceph-devel@...r.kernel.org,
	v9fs@...ts.linux.dev, linux-fsdevel@...r.kernel.org,
	linux-mm@...ck.org, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org, Latchesar Ionkov <lucho@...kov.net>,
	Christian Schoenebeck <linux_oss@...debyte.com>
Subject: Re: [PATCH v5 40/40] 9p: Use netfslib read/write_iter

On Wed, Jan 03, 2024 at 04:22:29PM +0900, Dominique Martinet wrote:
> David Howells wrote on Thu, Dec 21, 2023 at 01:23:35PM +0000:
> 
> I've noticed we don't cache xattrs are all, so with the default mount
> options on a kernel built with 9P_FS_SECURITY we'll get a gazillion
> lookups for security.capabilities... But that's another problem, and
> this is still an improvement so no reason to hold back.
>

This is a big problem and already on my backlog list since some things
default to this even if the remote file system doesn't support
xattrs.  The quick fix is to disable on a mount when we detect the
host side isn't supporting them (of course this could be weird for
exports that cross file system boundries) -- at the very least we
could keep this info on an inode basis and not request as long as the
inode info is cached.  Caching the actual properties is also a step,
but given this is a security feature, I imagine we don't want to trust
our cache and will always have to ask server unless we can come up with
something clever to indicate xattr changes (haven't looked into that
much yet).

> 
> (I'd still be extremly thanksful if Christian and/or Eric would have
> time to check as well, but I won't push back to merging it this merge
> window next week if they don't have time... I'll also keep trying to run
> some more tests as time allows)
>

I'll try to run through my regression tests as well, but sure we
can fix things up after the merge window if we miss things.

    -eric