[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 3 Apr 2018 17:02:46 -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 4:47 PM, Matthew Garrett <mjg59@...gle.com> wrote:
>> Another way of looking at this: if lockdown is a good idea to enable
>> when you booted using secure boot, then why isn't it a good idea when
>> you *didn't* boot using secure boot?
>
> Because it's then trivial to circumvent and the restrictions aren't worth
> the benefit.
Bullshit.
If there those restrictions cause problems, they need to be fixed regardless.
In fact, from a debuggability standpoint, you want to find the
problems early, on those kernel development machines that had secure
boot explicitly turned off because it's such a pain.
And if they can't be fixed, then the user is going to disable lockdown
regardless of how he booted the machine.
In no situation is "depending on how you booted" a good choice.
Either you can enable it or you can't. If you can, good. And if you
can't, it has nothing to do with secure boot.
Linus
Powered by blists - more mailing lists