linux-kernel - Re: [linux-next] PPC Lpar fail to boot with error hid: module verification failed: signature and/or required key missing

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:   Mon, 29 May 2017 15:06:58 +1000
From:   Michael Ellerman <mpe@...erman.id.au>
To:     Rob Landley <rob@...dley.net>,
        Stephen Rothwell <sfr@...b.auug.org.au>
Cc:     Abdul Haleem <abdhalee@...ux.vnet.ibm.com>,
        linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        linux-input@...r.kernel.org, Jiri Kosina <jikos@...nel.org>,
        Benjamin Tissoires <benjamin.tissoires@...hat.com>,
        sachinp <sachinp@...ux.vnet.ibm.com>,
        Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [linux-next] PPC Lpar fail to boot with error hid: module verification failed: signature and/or required key missing - tainting kernel

Rob Landley <rob@...dley.net> writes:

> On 05/25/2017 04:24 PM, Stephen Rothwell wrote:
>> Hi Michael,
>> 
>> On Thu, 25 May 2017 23:02:06 +1000 Michael Ellerman <mpe@...erman.id.au> wrote:
>>>
>>> It'll be:
>>>
>>> ee35011fd032 ("initramfs: make initramfs honor CONFIG_DEVTMPFS_MOUNT")
>>
>> And Andrew has asked me to drop that patch from linux-next which will
>> happen today.
>
> What approach do the kernel developers suggest I take here?

Well I'm just *a* kernel developer, but rule #1 is don't break userspace.

> I would have thought letting it soak in linux-next for a release so
> people could fix userspace bugs would be the next step, but this sounds
> like that's not an option?

You say they're userspace bugs, userspace will say it's a bug that the
kernel has changed its behaviour.

> Is the behavior the patch implements wrong?

Yes, because it breaks existing setups for no particularly good reason.

If CONFIG_DEVTMPFS_MOUNT had always meant devtmpfs was mounted in the
initramfs then that would have been fine.

But because it didn't, there are now systems out there that depend on
the existing behaviour, and changing it is therefore wrong IMHO.

As I said in another mail you can avoid breaking existing setups by
adding a new config option to control mounting devtmpfs in the
initramfs. It's a pity to need yet another config option, but such is
life.

cheers