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]

Date:	Tue, 16 Dec 2014 16:27:16 +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 07:26:26AM -0800, Jeremiah Mahler wrote:

> > No such errors happen on the normal boot, presumably?
> > 
> > > [    2.392117] EXT4-fs (sda5): mounting ext2 file system using the ext4 subsystem
> > > [    2.393920] EXT4-fs (sda5): mounted filesystem without journal. Opts: (null)
> > 
> > Wait a minute. So that happens _before_ /dev/sda5 mount?  Could you post dmesg
> > from the normal boot (e.g. just prior to the buggy commit)?
> > 
> > I really don't get it - there's nothing for init_fs.root to point to other
> > than initramfs by that point, CLONE_FS or no CLONE_FS.  We simply don't
> > have anything else mounted yet.  Do you get another failing bunch of
> > request_firmware later?  And what does dmesg look like on the working
> > kernel - either you have that firmware on initramfs image (in which case
> > it ought to have been picked by both kernels), or you do not, in which case
> > neither kernel would've managed to load it until after mounting the real
> > root...
> 
> I compiled this kernel with the commit just before the bug was introduced
> (93fe74b2e2b5d266d630f0c3f8287efcbe6ecd10).  Wireless comes up without
> any issue.  Here is the dmesg output.

OK, so the root is on sda6, it's been mounted before those attempts to
load firmware and init has been chrooted into it, while init_fs got left
behind.  And that "chrooted into" has happened without pivot_root(2) (or
it would've been caught by chroot_fs_refs() in sys_pivot_root()) and
not from the "no /init on initramfs" codepath (you do have it there).

OK, it's probably unsalvagable, then.  Pity, since it means that PID 1 and
kernel threads _must_ share ->fs, for the sake of usable ->fs->root, which
is asking for trouble.  And it means that we still need a sane solution for
nfsd folks...

Anyway, dropped that stuff from for-next (and for-linus, obviously), with
apologies all around.
--
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/