Re: [GIT PULL] Kernel lockdown for secure boot
From: | Linus Torvalds <torvalds-AT-linux-foundation.org> | |
To: | Andy Lutomirski <luto-AT-kernel.org> | |
Subject: | Re: [GIT PULL] Kernel lockdown for secure boot | |
Date: | Tue, 3 Apr 2018 15:46:11 -0700 | |
Message-ID: | <CA+55aFxKzxdRZthzaokaGPAsWCp3a-p3aVfJSutF+9Fp9sbaVA@mail.gmail.com> | |
Cc: | David Howells <dhowells-AT-redhat.com>, Matthew Garrett <mjg59-AT-google.com>, Ard Biesheuvel <ard.biesheuvel-AT-linaro.org>, James Morris <jmorris-AT-namei.org>, Alan Cox <gnomes-AT-lxorguk.ukuu.org.uk>, Greg Kroah-Hartman <gregkh-AT-linuxfoundation.org>, Linux Kernel Mailing List <linux-kernel-AT-vger.kernel.org>, Justin Forbes <jforbes-AT-redhat.com>, linux-man <linux-man-AT-vger.kernel.org>, joeyli <jlee-AT-suse.com>, LSM List <linux-security-module-AT-vger.kernel.org>, Linux API <linux-api-AT-vger.kernel.org>, Kees Cook <keescook-AT-chromium.org>, linux-efi <linux-efi-AT-vger.kernel.org> |
On Tue, Apr 3, 2018 at 3:39 PM, Andy Lutomirski <luto@kernel.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