linux-kernel - Re: [PATCH] init/do_mounts.c: Add root="fstag:<tag>" syntax for root device

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: <YMCPPCbjbRoPAEcL@stefanha-x1.localdomain>
Date:   Wed, 9 Jun 2021 10:51:56 +0100
From:   Stefan Hajnoczi <stefanha@...hat.com>
To:     Vivek Goyal <vgoyal@...hat.com>
Cc:     linux-fsdevel@...r.kernel.org, virtio-fs@...hat.com,
        linux kernel mailing list <linux-kernel@...r.kernel.org>,
        Miklos Szeredi <miklos@...redi.hu>,
        David Howells <dhowells@...hat.com>, viro@...iv.linux.org.uk,
        Richard Weinberger <richard.weinberger@...il.com>,
        dgilbert@...hat.com, Dominique Martinet <asmadeus@...ewreck.org>,
        v9fs-developer@...ts.sourceforge.net
Subject: Re: [PATCH] init/do_mounts.c: Add root="fstag:<tag>" syntax for root
 device

On Tue, Jun 08, 2021 at 11:35:24AM -0400, Vivek Goyal wrote:
> We want to be able to mount virtiofs as rootfs and pass appropriate
> kernel command line. Right now there does not seem to be a good way
> to do that. If I specify "root=myfs rootfstype=virtiofs", system
> panics.
> 
> virtio-fs: tag </dev/root> not found
> ..
> ..
> [ end Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) ]
> 
> Basic problem here is that kernel assumes that device identifier
> passed in "root=" is a block device. But there are few execptions
> to this rule to take care of the needs of mtd, ubi, NFS and CIFS.
> 
> For example, mtd and ubi prefix "mtd:" or "ubi:" respectively.
> 
> "root=mtd:<identifier>" or "root=ubi:<identifier>"
> 
> NFS and CIFS use "root=/dev/nfs" and CIFS passes "root=/dev/cifs" and
> actual root device details come from filesystem specific kernel
> command line options.
> 
> virtiofs does not seem to fit in any of the above categories. In fact
> we have 9pfs which can be used to boot from but it also does not
> have a proper syntax to specify rootfs and does not fit into any of
> the existing syntax. They both expect a device "tag" to be passed
> in a device to be mounted. And filesystem knows how to parse and
> use "tag".
> 
> So this patch proposes that we add a new prefix "fstag:" which specifies
> that identifier which follows is filesystem specific tag and its not
> a block device. Just pass this tag to filesystem and filesystem will
> figure out how to mount it.
> 
> For example, "root=fstag:<tag>".
> 
> In case of virtiofs, I can specify "root=fstag:myfs rootfstype=virtiofs"
> and it works.
> 
> I think this should work for 9p as well. "root=fstag:myfs rootfstype=9p".
> Though I have yet to test it.
> 
> This kind of syntax should be able to address wide variety of use cases
> where root device is not a block device and is simply some kind of
> tag/label understood by filesystem.

"fstag" is kind of virtio-9p/fs specific. The intended effect is really
to specify the file system source (like in mount(2)) without it being
interpreted as a block device.

In a previous discussion David Gilbert suggested detecting file systems
that do not need a block device:
https://patchwork.kernel.org/project/linux-fsdevel/patch/20190906100324.8492-1-stefanha@redhat.com/

I never got around to doing it, but can do_mounts.c just look at struct
file_system_type::fs_flags FS_REQUIRES_DEV to detect non-block device
file systems?

That way it would know to just mount with root= as the source instead of
treating it as a block device. No root= prefix would be required and it
would handle NFS, virtiofs, virtio-9p, etc without introducing the
concept of a "tag".

  root=myfs rootfstype=virtiofs rootflags=...

I wrote this up quickly after not thinking about the topic for 2 years,
so the idea may not work at all :).

Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)