linux-kernel - Re: [PATCH v4 0/3] initramfs: add support for xattrs in the initial ram disk

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: <3d77db23-51da-be5e-b40d-a92aeb568833@landley.net>
Date:   Tue, 19 Jul 2022 09:14:39 -0500
From:   Rob Landley <rob@...dley.net>
To:     Roberto Sassu <roberto.sassu@...wei.com>,
        Jim Baxter <jim_baxter@...tor.com>,
        Eugeniu Rosca <erosca@...adit-jv.com>
Cc:     "hpa@...or.com" <hpa@...or.com>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Arvind Sankar <nivedita@...m.mit.edu>,
        Mimi Zohar <zohar@...ux.ibm.com>,
        "viro@...iv.linux.org.uk" <viro@...iv.linux.org.uk>,
        "linux-security-module@...r.kernel.org" 
        <linux-security-module@...r.kernel.org>,
        "linux-integrity@...r.kernel.org" <linux-integrity@...r.kernel.org>,
        "initramfs@...r.kernel.org" <initramfs@...r.kernel.org>,
        "linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
        "linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "bug-cpio@....org" <bug-cpio@....org>,
        "zohar@...ux.vnet.ibm.com" <zohar@...ux.vnet.ibm.com>,
        Silviu Vlasceanu <Silviu.Vlasceanu@...wei.com>,
        Dmitry Kasatkin <dmitry.kasatkin@...wei.com>,
        "takondra@...co.com" <takondra@...co.com>,
        "kamensky@...co.com" <kamensky@...co.com>,
        "arnd@...db.de" <arnd@...db.de>,
        "james.w.mcmechan@...il.com" <james.w.mcmechan@...il.com>,
        "linux-kbuild@...r.kernel.org" <linux-kbuild@...r.kernel.org>,
        Dirk Behme <dirk.behme@...bosch.com>,
        Eugeniu Rosca <roscaeugeniu@...il.com>
Subject: Re: [PATCH v4 0/3] initramfs: add support for xattrs in the initial
 ram disk

On 7/19/22 07:26, Roberto Sassu wrote:
>> P.P.S. If you want to run a command other than /init out of initramfs or initrd,
>> use the rdinit=/run/this option. Note the root= overmount mechanism is
>> completely different code and uses the init=/run/this argument instead, which
>> means nothing to initramfs. Again, specifying root= says we are NOT staying in
>> initramfs.
> 
> Sorry, it was some time ago. I have to go back and see why we needed
> a separate option.

Did I mention that init/do_mounts.c already has:

__setup("rootfstype=", fs_names_setup);

static char * __initdata root_fs_names;
static int __init fs_names_setup(char *str)
{
        root_fs_names = str;
        return 1;
}

void __init init_rootfs(void)
{
        if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
                (!root_fs_names || strstr(root_fs_names, "tmpfs")))
                is_tmpfs = true;
}

I thought I'd dealt with this back in commit 6e19eded3684? Hmmm, looks like it
might need something like:

diff --git a/init/do_mounts.c b/init/do_mounts.c
index 7058e14ad5f7..4b4e1ffa20e1 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -665,7 +665,7 @@ struct file_system_type rootfs_fs_type = {

 void __init init_rootfs(void)
 {
-       if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
-               (!root_fs_names || strstr(root_fs_names, "tmpfs")))
+       if (IS_ENABLED(CONFIG_TMPFS) && (!root_fs_names ? !saved_root_name[0] :
+               strstr(root_fs_names, "tmpfs"))
                is_tmpfs = true;
 }


> Maybe omitting root= was impacting on mounting
> the real root filesystem. Will get that information.

I know some old bootloaders hardwire in the command line so people can't
_remove_ the root=.

The reason I didn't just make rootfs always be tmpfs when CONFIG_TMPFS is
enabled is:

A) It uses very slightly more resources, and the common case is overmounting an
empty rootfs. (And then hiding it from /proc/mounts so people don't ask too many
questions.)

B) Some embedded systems use more than 50% of the system's memory for initramfs
contents, which the tmpfs defaults won't allow (fills up at 50%), and I'm not
sure I ever hooked up I don't think I ever hooked up rootflags= ala
root_mount_data to the initramfs mount? (If so, setting size= through that
should work...)

> Intuitively, given that root= is consumed for example by dracut, it seems
> a safer choice to have an option to explicitly choose the desired filesystem.

Sounds like a dracut issue. Have you used dracut in a system running from initramfs?

Lots of systems running from initramfs already DON'T have a root=, so you're
saying dracut being broken when there is no root= is something to work around
rather than fix in dracut, even though it's been easy to create a system without
a root= for a decade and a half already...

> Roberto

Rob