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 15:05:18 +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 06:46:10AM -0800, Jeremiah Mahler wrote:
> --- a/init/main.c
> +++ b/init/main.c
> @@ -1026,16 +1026,17 @@ 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);
> -               }
>         }
> +       {
> +       /* 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);
> +       }
> +
>  
>         /*
>          * Ok, we have completed the initial bootup, and
> 
> 
> And it still behaves the same.  Below is the dmesg output.

> [    2.281438] iwlwifi 0000:03:00.0: Direct firmware load for iwlwifi-6000g2a-6.ucode failed with error -2
> [    2.281451] iwlwifi 0000:03:00.0: Direct firmware load for iwlwifi-6000g2a-5.ucode failed with error -2
> [    2.281453] iwlwifi 0000:03:00.0: request for firmware file 'iwlwifi-6000g2a-5.ucode' failed.
> [    2.281521] iwlwifi 0000:03:00.0: no suitable firmware found!

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...
--
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/