[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CA+55aFxKzxdRZthzaokaGPAsWCp3a-p3aVfJSutF+9Fp9sbaVA@mail.gmail.com>
Date: Tue, 3 Apr 2018 15:46:11 -0700
From: Linus Torvalds <torvalds@...ux-foundation.org>
To: Andy Lutomirski <luto@...nel.org>
Cc: David Howells <dhowells@...hat.com>,
Matthew Garrett <mjg59@...gle.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 3:39 PM, Andy Lutomirski <luto@...nel.org> wrote:
>
> Sure. I have no problem with having an upstream kernel have a
> lockdown feature, although I think that feature should distinguish
> between reads and writes. But I don't think the upstream kernel
> should apply a patch that ties any of this to Secure Boot without a
> genuine technical reason why it makes sense.
So this is where I violently agree with Andy.
For example, I love signed kernel modules. The fact that I love them
has absolutely zero to do with secure boot, though. There is
absolutely no linkage between the two issues: I use (self-)signed
kernel modules simply because I think it's a good thing in general.
The same thing is true of some lockdown patch. Maybe it's a good thing
in general. But whether it's a good thing is _entirely_ independent of
any secure boot issue. I can see using secure boot without it, but I
can very much also see using lockdown without secure boot.
The two things are simply entirely orthogonal. They have _zero_
overlap. I'm not seeing why they'd be linked at all in any way.
Linus
Powered by blists - more mailing lists