linux-kernel - Re: [PATCH v3 0/3] 9p: add support for root file systems

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:   Mon, 14 Jun 2021 18:01:44 +0900
From:   Dominique Martinet <asmadeus@...ewreck.org>
To:     Josh Triplett <josh@...htriplett.org>
Cc:     Changbin Du <changbin.du@...il.com>,
        Eric Van Hensbergen <ericvh@...il.com>,
        Latchesar Ionkov <lucho@...kov.net>,
        linux-kernel@...r.kernel.org, v9fs-developer@...ts.sourceforge.net
Subject: Re: [PATCH v3 0/3] 9p: add support for root file systems

Josh Triplett wrote on Mon, Jun 14, 2021 at 01:57:54AM -0700:
> On Mon, Jun 07, 2021 at 07:09:19AM +0800, Changbin Du wrote:
> > Just like cifs and nfs, this short series enables rootfs support for 9p.
> > Bellow is an example which mounts v9fs with tag 'r' as rootfs in qemu
> > guest via virtio transport.
> > 
> >   $ qemu-system-x86_64 -enable-kvm -cpu host -m 1024 \
> >         -virtfs local,path=$rootfs_dir,mount_tag=r,security_model=passthrough,id=r \
> >         -kernel /path/to/linux/arch/x86/boot/bzImage -nographic \
> >         -append "root=/dev/v9fs v9fsroot=r,trans=virtio rw console=ttyS0 3"
> 
> Rather than inventing a pseudo-device /dev/v9fs for this, would it
> potentially work to use the existing rootfstype and rootflags options
> for this? rootfstype already determines what filesystem should be used
> to mount the root, and rootflags already provides options for that
> filesystem.
> 
> For instance, for the above example:
> rootfstype=9p root=r rootflags=trans=virtio
> 
> That would require a bit of fiddling to make rootfstype=9p allow a root
> that's just the mount_tag. If that isn't an option, then even with
> root=/dev/v9fs I think it still makes sense to use the existing
> rootflags for "trans=virtio" rather than creating a new "v9fsroot"
> option for that.

This doesn't work as is because of the way the code is written, if
there's no block device associated with a root=x option right now it
will lead to kernel panic.

I replied with folks in Cc but there's another thread on linux-fsdevel@
with a more generic approach that will build a list of filesystems which
don't require such a block device (either hardcoded with virtiofs and 9p
or based on FS_REQUIRES_DEV), thread started there but there's a second
patch hidden an more discussion below:
https://lore.kernel.org/linux-fsdevel/20210608153524.GB504497@redhat.com/


My preferred approach right now would be to go with their approach, and
adjust the documentation Changbin Du wrote here, to have the best of
both worlds.

-- 
Dominique