linux-kernel - Re: [PATCH 00/17] VFS: Filesystem information and notifications [ver #17]

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: <CAJfpegu0qHBZ7iK=R4ajmmHC4g=Yz56otpKMy5w-y0UxJ1zO+Q@mail.gmail.com>
Date:   Mon, 2 Mar 2020 10:09:51 +0100
From:   Miklos Szeredi <miklos@...redi.hu>
To:     David Howells <dhowells@...hat.com>
Cc:     Christian Brauner <christian.brauner@...ntu.com>,
        James Bottomley <James.Bottomley@...senpartnership.com>,
        Steven Whitehouse <swhiteho@...hat.com>,
        Miklos Szeredi <mszeredi@...hat.com>,
        viro <viro@...iv.linux.org.uk>, Ian Kent <raven@...maw.net>,
        Christian Brauner <christian@...uner.io>,
        Jann Horn <jannh@...gle.com>,
        "Darrick J. Wong" <darrick.wong@...cle.com>,
        Linux API <linux-api@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Subject: Re: [PATCH 00/17] VFS: Filesystem information and notifications [ver #17]

On Fri, Feb 28, 2020 at 5:36 PM David Howells <dhowells@...hat.com> wrote:
>
> sysfs also has some other disadvantages for this:
>
>  (1) There's a potential chicken-and-egg problem in that you have to create a
>      bunch of files and dirs in sysfs for every created mount and superblock
>      (possibly excluding special ones like the socket mount) - but this
>      includes sysfs itself.  This might work - provided you create sysfs
>      first.

Sysfs architecture looks something like this (I hope Greg will correct
me if I'm wrong):

device driver -> kobj tree <- sysfs tree

The kobj tree is created by the device driver, and the dentry tree is
created on demand from the kobj tree.   Lifetime of kobjs is bound to
both the sysfs objects and the device but not the other way round.
I.e. device can go away while the sysfs object is still being
referenced, and sysfs can be freely mounted and unmounted
independently of device initialization.

So there's no ordering requirement between sysfs mounts and other
mounts.   I might be wrong on the details, since mounts are created
very early in the boot process...

>
>  (2) sysfs is memory intensive.  The directory structure has to be backed by
>      dentries and inodes that linger as long as the referenced object does
>      (procfs is more efficient in this regard for files that aren't being
>      accessed)

See above: I don't think dentries and inodes are pinned, only kobjs
and their associated cruft.  Which may be too heavy, depending on the
details of the kobj tree.

>  (3) It gives people extra, indirect ways to pin mount objects and
>      superblocks.

See above.

> For the moment, fsinfo() gives you three ways of referring to a filesystem
> object:
>
>  (a) Directly by path.

A path is always representable by an O_PATH descriptor.

>
>  (b) By path associated with an fd.

See my proposal about linking from /proc/$PID/fdmount/$FD ->
/sys/devices/virtual/mounts/$MOUNT_ID.

>
>  (c) By mount ID (perm checked by working back up the tree).

Check that perm on lookup of /sys/devices/virtual/mounts/$MOUNT_ID.
The proc symlink would bypass the lookup check by directly jumping to
the mountinfo dir.

> but will need to add:
>
>  (d) By fscontext fd (which is hard to find in sysfs).  Indeed, the superblock
>      may not even exist yet.

Proc symlink would work for that too.

If sysfs is too heavy, this could be proc or a completely new
filesystem.  The implementation is much less relevant at this stage of
the discussion than the interface.

Thanks,
Miklos