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: <20141216150518.GD22149@ZenIV.linux.org.uk>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ