linux-kernel - Re: [GIT PULL] Kernel lockdown for secure boot

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, 3 Apr 2018 17:15:09 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Matthew Garrett <mjg59@...gle.com>
Cc:     Andrew Lutomirski <luto@...nel.org>,
        David Howells <dhowells@...hat.com>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        James Morris <jmorris@...ei.org>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Justin Forbes <jforbes@...hat.com>,
        linux-man <linux-man@...r.kernel.org>, joeyli <jlee@...e.com>,
        LSM List <linux-security-module@...r.kernel.org>,
        Linux API <linux-api@...r.kernel.org>,
        Kees Cook <keescook@...omium.org>,
        linux-efi <linux-efi@...r.kernel.org>
Subject: Re: [GIT PULL] Kernel lockdown for secure boot

On Tue, Apr 3, 2018 at 5:10 PM, Matthew Garrett <mjg59@...gle.com> wrote:
>
>> Exactly like EVERY OTHER KERNEL CONFIG OPTION.
>
> So your argument is that we should make the user experience worse? Without
> some sort of verified boot mechanism, lockdown is just security theater.
> There's no good reason to enable it unless you have some mechanism for
> verifying that you booted something you trust.

Wow. Way to snip the rest of the email where I told you what the
solution was. Let me repeat it here, since you so conveniently missed
it and deleted it:

>> Or, like a lot of other kernel options, maybe have a way to just
>> disable it on the kernel command line, and let the user know about it.
>>
>> That would still be better than disabling secure boot entirely in your
>> world view, so it's (a) more convenient and (b) better.

Matthew, it's simply not worth continuing talking with you.

I'll just not pull this crap, and vendors that you convince to do
stupid things have only themselves to blame.

You clearly have an agenda, and are not willing to look at arguments
against your idiotic choices.

                 Linus