linux-kernel - Re: Patch 0727d35de ("Make initramfs honor CONFIG_DEVTMPFS

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: <1fb53a8c-6c17-1de2-493c-0bff403c9ff9@landley.net>
Date:   Sun, 10 Sep 2017 18:43:24 -0500
From:   Rob Landley <rob@...dley.net>
To:     Michael Ellerman <mpe@...erman.id.au>,
        Yury Norov <ynorov@...iumnetworks.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Prarit Bhargava <prarit@...hat.com>,
        Yang Shi <yang.shi@...aro.org>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Kees Cook <keescook@...omium.org>,
        Emese Revfy <re.emese@...il.com>,
        Petr Mladek <pmladek@...e.com>,
        Fabian Frederick <fabf@...net.be>
Subject: Re: Patch 0727d35de ("Make initramfs honor CONFIG_DEVTMPFS_MOUNT")
 breaks boot

Taking another stab at this old issue from last merge window...

> Rob Landley <rob@...dley.net> writes:
>> On 05/23/2017 03:01 AM, Yury Norov wrote:
>>> On Mon, May 22, 2017 at 09:07:54PM -0500, Rob Landley wrote:
>>>> Your userspace mounted a tmpfs over /dev when it couldn't mount a second
>>>> identical instance of devtmpfs over itself. If you had a static /dev in
>>>> initramfs but didn't configure _in_ devtmpfs to your kernel, your broken
>>>> error path would have taken that out too with a pointless tmpfs mount.
>>>
>>> CONFIG_DEVTMPFS_MOUNT is enabled on my machine, so I think your
>>> suggestion is correct. But I didn't do that specifically - I run
>>> almost default kernel based on Ubuntu 14.04 config and environment.
>>
>> I.E. ubuntu has a bug: they enabled CONFIG_DEVTMPFS_MOUNT and then
>> launchd an initramfs instead (which didn't do the automount they
>> requested so why request it), but if CONFIG_DEVTMPFS_MOUNT actually
>> starts working in initramfs they have an insane error path that breaks
>> the system, and does nothing _except_ break the system.

...

On 05/25/2017 01:13 AM, Michael Ellerman wrote:
> Hi Rob,
> 
> This is breaking a bunch of my powerpc boxes, for the exact same
> reason, they use a config that has DEVTMPFS_MOUNT=y and that trips
> up the initramfs.

I've continued to use this locally but should probably make another
stab at submitting upstream. The obvious workaround until debian fixes
its 100% obvious bug seems to be:

diff --git a/fs/namespace.c b/fs/namespace.c
index f8893dc..f57d5df 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -2417,7 +2417,17 @@ static int do_add_mount(struct mount *newmnt, struct path *path, int mnt_flags)
 	err = -EBUSY;
 	if (path->mnt->mnt_sb == newmnt->mnt.mnt_sb &&
 	    path->mnt->mnt_root == path->dentry)
+	{
+		if (IS_ENABLED(CONFIG_DEVTMPFS_MOUNT) &&
+		    !strcmp(path->mnt->mnt_sb->s_type->name, "devtmpfs"))
+		{
+			printk(KERN_WARNING "Debian bug workaround for devtmpfs overmount.");
+			printk(KERN_WARNING "This line doesn't output for some reason.");
+
+			err = 0;
+		}
 		goto unlock;
+	}
 
 	err = -EINVAL;
 	if (d_is_symlink(newmnt->mnt.mnt_root))

Except for the second printk line: If you boot with rdinit=/bin/hush
then the first time you mount -t devtmpfs /dev /dev after boot (with
CONFIG_DEVTMPFS_MOUNT already having mounted it), you get the 0 return
value but the last printk() doesn't output? The second and later times
you repeat it, both printk() lines are output.

What's up with printk?

(I added the second printk because the _first_ one wasn't outputting
that first time. Something is happening to flush the printk() queue
instead of writing it out? Built for x86-64, miniconfig attached for
reference. I tested commit 4dfc2788033d from yesterday.)

Rob

View attachment "x86_64.miniconf" of type "text/plain" (977 bytes)