linux-kernel - Re: [BUG, linux-next] spawn PID 1 without CLONE

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: <20141216132821.GA22149@ZenIV.linux.org.uk>
Date:	Tue, 16 Dec 2014 13:28:21 +0000
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Jeremiah Mahler <jmmahler@...il.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-kernel@...r.kernel.org, linux-next@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [BUG, linux-next] spawn PID 1 without CLONE_FS, wireless inop

On Tue, Dec 16, 2014 at 12:56:15PM +0000, Al Viro wrote:
> On Tue, Dec 16, 2014 at 03:55:37AM -0800, Jeremiah Mahler wrote:
> > all,
> > 
> > The wireless network interface has become inoperative when running
> > linux-next 20141216 on a Lenovo Carbon X1.  It is completely
> > non-existent and `ip addr` doesn't show it.  A bisect has found that
> > the bug was introduced by the following commit.
> 
> Very interesting.  What userland are you running?  I take it, the root
> filesystem is mounted and system boot except for that interface not
> coming up, right?
> 
> Your card is normally handled by what, iwlwifi?  What happens upon
> modprobe iwlwifi (or whatever module you see loaded on the normal
> boot)?  Another interesting question is whether it manages to load
> the firmware...  What happens if you boot with debug in kernel command
> line, with working and with non-working kernels resp.?

Hmm...  OK, I think I see what might be going on.  On the testbox here
I've got pivot_root(2) done from /init on initramfs.  And that triggers
chroot_fs_refs(), which switches init_fs.{root,pwd} to the final rootfs.
In your case it apparently isn't triggered (different userland or setup,
perhaps) and init_fs is left behind on initramfs.  With some files
(firmware?) not being there...  Could you check if the following kludge
helps?  It's not intended as a solution, I just want to verify that guess
about the mechanism of the problem...

diff --git a/init/main.c b/init/main.c
index 3a169a2..36c29d6 100644
--- a/init/main.c
+++ b/init/main.c
@@ -80,6 +80,8 @@
 #include <linux/list.h>
 #include <linux/proc_ns.h>
 #include <linux/fs_struct.h>
+#include "../fs/internal.h" // HACK
+#include <linux/init_task.h> // HACK
 
 #include <asm/io.h>
 #include <asm/bugs.h>
@@ -1024,6 +1026,15 @@ static noinline void __init kernel_init_freeable(void)
 	if (sys_access((const char __user *) ramdisk_execute_command, 0) != 0) {
 		ramdisk_execute_command = NULL;
 		prepare_namespace();
+		{
+		/* HACK */
+			struct path old, new;
+			get_fs_root(current->fs, &new);
+			get_fs_root(&init_fs, &old);
+			chroot_fs_refs(&old, &new);
+			path_put(&old);
+			path_put(&new);
+		}
 	}
 
 	/*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/