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:   Thu, 25 May 2017 16:13:33 +1000
From:   Michael Ellerman <mpe@...erman.id.au>
To:     Rob Landley <rob@...dley.net>,
        Yury Norov <ynorov@...iumnetworks.com>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>,
        Prarit Bhargava <prarit@...hat.com>,
        Yang Shi <yang.shi@...aro.org>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Kees Cook <keescook@...omium.org>,
        Emese Revfy <re.emese@...il.com>,
        Petr Mladek <pmladek@...e.com>,
        Fabian Frederick <fabf@...net.be>
Subject: Re: Patch 0727d35de ("Make initramfs honor CONFIG_DEVTMPFS_MOUNT") breaks boot

Hi Rob,

This is breaking a bunch of my powerpc boxes, for the exact same reason,
they use a config that has DEVTMPFS_MOUNT=y and that trips up the
initramfs.

Rob Landley <rob@...dley.net> writes:
> On 05/23/2017 03:01 AM, Yury Norov wrote:
>> On Mon, May 22, 2017 at 09:07:54PM -0500, Rob Landley wrote:
>>> Your userspace mounted a tmpfs over /dev when it couldn't mount a second
>>> identical instance of devtmpfs over itself. If you had a static /dev in
>>> initramfs but didn't configure _in_ devtmpfs to your kernel, your broken
>>> error path would have taken that out too with a pointless tmpfs mount.
>> 
>> CONFIG_DEVTMPFS_MOUNT is enabled on my machine, so I think your
>> suggestion is correct. But I didn't do that specifically - I run
>> almost default kernel based on Ubuntu 14.04 config and environment.
>
> I.E. ubuntu has a bug: they enabled CONFIG_DEVTMPFS_MOUNT and then
> launchd an initramfs instead (which didn't do the automount they
> requested so why request it), but if CONFIG_DEVTMPFS_MOUNT actually
> starts working in initramfs they have an insane error path that breaks
> the system, and does nothing _except_ break the system.

Sure. But prior to your patch the only reason mounting devtmpfs could
fail was because of something being broken, it was never automatically
mounted. So we've changed the set of possibilities out from under the
initramfs scripts.

I agree it's not the greatest error handling ever, but it's pretty rude
to break booting on existing working setups. If nothing else it makes
bisection a nightmare.

>> So the proper way is to remove broken
>> config option and introduce new one. BTW, I see it is used once in
>> drivers/base/devtmpfs.c.
>
> How does removing the broken config option (or renaming it to
> CONFIG_DEFTMPFS_UBUNTU_IS_BROKEN) _not_ impact systems that were
> previously happily using it in the contexts where it already worked?

I don't think that's what Yury's suggesting, and indeed it wouldn't work.

What would work, is to add a new config option, perhaps
CONFIG_DEVTMPFS_MOUNT_INITRAMFS, which is 'default n'. Then existing
setups continue to work, and people who want it mounted in the initramfs
can enable the new option.

cheers

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ