| Message ID | 1814af5c-170d-39c0-58fd-02eb7216e008@landley.net (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote: > On 01/30/2018 03:46 PM, Mimi Zohar wrote: > > Commit 16203a7a9422 ("initmpfs: make rootfs use tmpfs when CONFIG_TMPFS > > enabled") introduced using tmpfs as the rootfs filesystem. The use of > > tmpfs is limited to systems that do not specify "root=" on the boot > > command line. > > > > Without the check "!saved_root_name[0]", rootfs uses tmpfs. As there > > must be a valid reason for this check, this patch introduces a new boot > > command line option named "noramfs" to force rootfs to use tmpfs. > > > > Signed-off-by: Mimi Zohar <zohar@linux.vnet.ibm.com> > > How about just: > > diff --git a/init/do_mounts.c b/init/do_mounts.c > index 7cf4f6d..af66ede 100644 > --- a/init/do_mounts.c > +++ b/init/do_mounts.c > @@ -632,8 +632,8 @@ int __init init_rootfs(void) > if (err) > return err; > > - if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] && > - (!root_fs_names || strstr(root_fs_names, "tmpfs"))) { > + if (IS_ENABLED(CONFIG_TMPFS) && (!saved_root_name[0] || > + !strcmp(saved_root_name, "tmpfs"))) { > err = shmem_init(); > is_tmpfs = true; > } else { > > (Obviously-signed-off-by: Rob Landley <rob@landley.net>) > > I.E. if you somehow just can't stop yourself from specifying root= when > using rootfs, have "root=tmpfs" do what you want. I tried overloading "rootfstype=tmpfs", before posting this work around, but for some reason that just doesn't work. > > (The old "I configured in tmpfs and am using rootfs but I want that rootfs > to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does > it?) I must be missing something. Which systems don't specify "root=" on the boot command line. If we want to include and restore xattrs, there needs to be a way of using tmpfs. Mimi > > > --- > > Documentation/admin-guide/kernel-parameters.txt | 2 ++ > > init/do_mounts.c | 15 +++++++++++++-- > > 2 files changed, 15 insertions(+), 2 deletions(-) > > I suppose I should do a documentation update too. Lemme send a proper one > after work... > > Rob > > P.S. While I'm at it, I've meant to wire up rootflags= so you can specify > a memory limit other than 50% forever, I should do that too. And resend > my "make DEVTMPFS_MOUNT apply to initramfs" patch (with the debian bug > workaround)... > -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/31/2018 04:07 PM, Mimi Zohar wrote: > On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:>> (The old "I configured in tmpfs and am using rootfs but I want that rootfs >> to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does >> it?) > > I must be missing something. Which systems don't specify "root=" on > the boot command line. Any system using initrd or initramfs? I have one at https://github.com/landley/mkroot that doesn't, for example. It's 600 lines of bash that builds simple Linux systems for a bunch of different architectures, each with a qemu wrapper to boot it to a shell prompt. And yes, it's using tmpfs for its initramfs, you can tell because "grep rootfs /proc/mounts" gives a size. That's also where I tested the patch I sent you. The root= option specifies the filesystem to mount OVER rootfs. I.E. it's the fallback root filesystem to mount when initramfs doesn't contain an executable /init that can become PID 1. If you DO have an /init in rootfs which the kernel manages to launch as PID 1, the kernel code never reaches the part that uses the root= argument. (Look for the call to prepare_namespace() in init/main.c, notice how it's only called if it can't _already_ find "/init".) That's why the test I added for initramfs vs initmpfs was "did they specify root=", because if they did it means they're telling the kernel what to mount over rootfs, so they're not staying in rootfs. That's what that argument MEANS. They're telling init/main.c what fallback filesystem to mount over rootfs _after_ failing to find /init in rootfs, therefore they're not keeping rootfs as their root filesystem for userspace. That said, a lot of people don't understand how this works, and they set root= to things like /dev/ram when using initrd because "we must set this knob to something, this is something, therefore we must set this knob to it". The fact setting root=/dev/random would have the exact same effect doesn't seem to bother them, they had Done It and It Worked, therefore it was the Right Thing To Do. QED. The patch last message was me going "alright, if people can't NOT twiddle the knob, even when doing it breaks things in an immediate and obvious way, and a big DO NOT TOUCH sign won't dissuade them, just give the knob an explicit 'off' setting that literally does the same thing as not touching it at all would". Your solution was to add a safety catch for the knob, which is edging into Rube Goldberg territory if you ask me. > If we want to include and restore xattrs, > there needs to be a way of using tmpfs. Yes, using tmpfs for initramfs is useful, that's why I submitted patches to hook it up back in 2013. (Personally I find "cat /dev/zero > /filename" _not_ hard locking your system instantly the most compelling feature. Although I believe what motivated my initmpfs patches way back when was somebody wanting to install an rpm into intramfs and the installer failing because ramfs hasn't got a size so "df" always returns zero.) > Mimi Rob -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Jan 31, 2018 at 05:48:20PM -0600, Rob Landley wrote: > On 01/31/2018 04:07 PM, Mimi Zohar wrote: > > On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:>> (The old "I configured in tmpfs and am using rootfs but I want that > rootfs > >> to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does > >> it?) > > > > I must be missing something. Which systems don't specify "root=" on > > the boot command line. > > Any system using initrd or initramfs? > Don't a lot of initramfs setups use root= to tell the initramfs which actual root file system to switch to after early boot? -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, 2018-01-31 at 21:03 -0500, Arvind Sankar wrote: > On Wed, Jan 31, 2018 at 05:48:20PM -0600, Rob Landley wrote: > > On 01/31/2018 04:07 PM, Mimi Zohar wrote: > > > On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:>> (The old "I configured in tmpfs and am using rootfs but I want that > > rootfs > > >> to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does > > >> it?) > > > > > > I must be missing something. Which systems don't specify "root=" on > > > the boot command line. > > > > Any system using initrd or initramfs? > > > > Don't a lot of initramfs setups use root= to tell the initramfs which > actual root file system to switch to after early boot? With your patch and specifying "root=tmpfs", dracut is complaining: dracut: FATAL: Don't know how to handle 'root=tmpfs' dracut: refusing to continue Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/31/2018 10:22 PM, Mimi Zohar wrote: > On Wed, 2018-01-31 at 21:03 -0500, Arvind Sankar wrote: >> On Wed, Jan 31, 2018 at 05:48:20PM -0600, Rob Landley wrote: >>> On 01/31/2018 04:07 PM, Mimi Zohar wrote: >>>> On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:>> (The old "I configured in tmpfs and am using rootfs but I want that >>> rootfs >>>>> to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does >>>>> it?) >>>> >>>> I must be missing something. Which systems don't specify "root=" on >>>> the boot command line. >>> >>> Any system using initrd or initramfs? >>> >> >> Don't a lot of initramfs setups use root= to tell the initramfs which >> actual root file system to switch to after early boot? You mean the option that _isn't_ passed through as an environment variable (the way ROOT= would be) so you have to parse /proc/cmdline to to see if it was passed in? If you really, really, really, really, really want to double down on the "no, this is the button, it doesn't do what I thought but I will MAKE it work" obsession, sure. > With your patch and specifying "root=tmpfs", dracut is complaining: > > dracut: FATAL: Don't know how to handle 'root=tmpfs' > dracut: refusing to continue [googles]... I do not understand why this package exists. If you're switching to another root filesystem, using a tool that wikipedia[citation needed] says has no purpose but to switch to another root filesystem, (so let's reproduce the kernel infrastructure in userspace while leaving it the kernel too)... why do you need initramfs to be tmpfs? You're using it for half a second, then discarding it, what's the point of it being tmpfs? Sigh. If people are ok with having rootfs just be tmpfs whenever tmpfs is configured in, even when you're then going to overmount it with something else like you're doing, let's just _remove_ the test. If it can be tmpfs, have it be tmpfs. Rob -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, 2018-02-01 at 09:20 -0600, Rob Landley wrote: > > With your patch and specifying "root=tmpfs", dracut is complaining: > > > > dracut: FATAL: Don't know how to handle 'root=tmpfs' > > dracut: refusing to continue > > [googles]... I do not understand why this package exists. > > If you're switching to another root filesystem, using a tool that > wikipedia[citation needed] says has no purpose but to switch to another > root filesystem, (so let's reproduce the kernel infrastructure in > userspace while leaving it the kernel too)... why do you need initramfs > to be tmpfs? You're using it for half a second, then discarding it, > what's the point of it being tmpfs? Unlike the kernel image which is signed by the distros, the initramfs doesn't come signed, because it is built on the target system. Even if the initramfs did come signed, it is beneficial to measure and appraise the individual files in the initramfs. > Sigh. If people are ok with having rootfs just be tmpfs whenever tmpfs > is configured in, even when you're then going to overmount it with > something else like you're doing, let's just _remove_ the test. If it > can be tmpfs, have it be tmpfs. Very much appreciated! thanks, Mimi -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 01/31/2018 10:22 PM, Mimi Zohar wrote: > On Wed, 2018-01-31 at 21:03 -0500, Arvind Sankar wrote: >> On Wed, Jan 31, 2018 at 05:48:20PM -0600, Rob Landley wrote: >>> On 01/31/2018 04:07 PM, Mimi Zohar wrote: >>>> On Wed, 2018-01-31 at 13:32 -0600, Rob Landley wrote:>> (The old "I configured in tmpfs and am using rootfs but I want that >>> rootfs >>>>> to be ramfs, not tmpfs" code doesn't seem to be a real-world concern, does >>>>> it?) >>>> >>>> I must be missing something. Which systems don't specify "root=" on >>>> the boot command line. >>> >>> Any system using initrd or initramfs? >>> >> >> Don't a lot of initramfs setups use root= to tell the initramfs which >> actual root file system to switch to after early boot? > > With your patch and specifying "root=tmpfs", dracut is complaining: > > dracut: FATAL: Don't know how to handle 'root=tmpfs' > dracut: refusing to continue "The kernel can't break this buggy userspace package." "The kernel must give access to a new feature to this buggy userspace package". I think kernel policy asks you to pick one, but I could be wrong... Rob -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/init/do_mounts.c b/init/do_mounts.c index 7cf4f6d..af66ede 100644 --- a/init/do_mounts.c +++ b/init/do_mounts.c @@ -632,8 +632,8 @@ int __init init_rootfs(void) if (err) return err; - if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] && - (!root_fs_names || strstr(root_fs_names, "tmpfs"))) { + if (IS_ENABLED(CONFIG_TMPFS) && (!saved_root_name[0] || + !strcmp(saved_root_name, "tmpfs"))) { err = shmem_init(); is_tmpfs = true; } else {