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 12:03:51 -0800
From:	Jeremiah Mahler <jmmahler@...il.com>
To:	Al Viro <viro@...IV.linux.org.uk>
Cc:	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

Al Viro,

On Tue, Dec 16, 2014 at 04:27:16PM +0000, Al Viro wrote:
> 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.

On a totally different machine, an Acer C720, the sound quit working.
I bisected that one and it pointed to this same commit.  However this
one doesn't involve loading firmware or any of that stuff.  Attached
are the good/bad dmesg logs.

-- 
- Jeremiah Mahler

View attachment "dmesg.good.log" of type "text/plain" (42509 bytes)

View attachment "dmesg.bad.log" of type "text/plain" (41509 bytes)