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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <e850477a-6dd8-0a76-cfa0-bf78951f7281@landley.net>
Date:   Sat, 30 Jul 2022 04:39:13 -0500
From:   Rob Landley <rob@...dley.net>
To:     Jim Baxter <jim_baxter@...tor.com>,
        Roberto Sassu <roberto.sassu@...wei.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/29/22 05:37, Jim Baxter wrote:
>>>> Uhm, I guess this could be solved with:
>>>>
>>>> https://github.com/openeuler-
>>> mirror/kernel/commit/18a502f7e3b1de7b9ba0c70896ce08ee13d052da
>>>>
>>>> and adding initramtmpfs to the kernel command line. You are
>>>> probably using ramfs, which does not have xattr support.
>>>>

Oh, here's the actual tested version of the patch wiring up rootfstype=tmpfs to
force rootfs to be tmpfs even when you specify root=

diff --git a/init/do_mounts.c b/init/do_mounts.c
index 7058e14ad5f7..dedf27fe9044 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;
 }

Signed-in-triplicate-by: Rob Landley <rob@...dley.net>

No idea why nobody else has fixed that bug in the past 9 years, seems obvious?

Anyway, here's the testing I did using mkroot (ala
https://landley.net/toybox/faq.html#mkroot):

$ (cd root/x86_64; KARGS='quiet root=potato HANDOFF="/bin/head -n 1
/proc/mounts"' ./run-qemu.sh) | tail -n 3
rootfs / rootfs rw 0 0
reboot: Restarting system

$ (cd root/x86_64; KARGS='quiet HANDOFF="/bin/head -n 1 /proc/mounts"'
./run-qemu.sh) | tail -n 3
rootfs / rootfs rw,size=121828k,nr_inodes=30457 0 0
reboot: Restarting system

$ (cd root/x86_64; KARGS='quiet rootfstype=tmpfs root=potato HANDOFF="/bin/head
-n 1 /proc/mounts"' ./run-qemu.sh) | tail -n 3
rootfs / rootfs rw,size=121828k,nr_inodes=30457 0 0
reboot: Restarting system

I.E. rootfstype=tmpfs neutralized the root= so it was still tmpfs despite the
kernel being explicitly told you weren't going to stay on initramfs (which is
still what root= means). With just root= it's still ramfs, with all the "my log
file got too big and the system livelocked" and "querying available space always
returns zero" that entails.

> Can I clarify which filesystem type is supported with this patch series?
> Is it tmpfs or perhaps a ramdisk?

I believe both tmpfs and ramfs support xattrs? (I know tmpfs does, and
fs/ramfs/file-mmu.c plugs simple_getattr() into ramfs_file_operations.setattr so
it looks like that would too? Haven't tried it.)

This isn't a modification to the filesystem code (ramfs/tmpfs), this is a
modification to the boot-time loader (initramfs) that extracts a cpio.gz file
into the filesystem.

Ramdisks have supported xattrs for years: they fake up a block device out of a
chunk of memory and them format it and mount some other filesystem on it,
meaning the driver for the other filesystem handles the xattr support.

But ramdisks don't use initramfs, they load an image of the preformatted
filesystem into the ramdisk block device. Completely separate mechanism, sharing
no code with initramfs, depending on the block layer, etc.

>>> Thank you, I have tested that patch but the problem remained. Here is my
>>> command line, I wonder if there is something wrong.
>>>
>>> Kernel command line: rw rootfstype=initramtmpfs root=/dev/ram0
>>> initrd=0x500000000 rootwait
>> 
>> It is just initramtmpfs, without rootfstype=.

The above patch does not go on top of that patch, it's instead of.

Rob