From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756686AbeDDASU (ORCPT ); Tue, 3 Apr 2018 20:18:20 -0400 Received: from mail-ot0-f193.google.com ([74.125.82.193]:43114 "EHLO mail-ot0-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756161AbeDDASR (ORCPT ); Tue, 3 Apr 2018 20:18:17 -0400 X-Google-Smtp-Source: AIpwx49yzvYCa20/24WU+e7uBLmN589lboxFlPGGnDPyIwNT0j++qX7bWt0rCQLoR1OntQPmXffboHC537GBNnxTABg= MIME-Version: 1.0 In-Reply-To: References: <4136.1522452584@warthog.procyon.org.uk> <186aeb7e-1225-4bb8-3ff5-863a1cde86de@kernel.org> <30459.1522739219@warthog.procyon.org.uk> <9758.1522775763@warthog.procyon.org.uk> <13189.1522784944@warthog.procyon.org.uk> <9349.1522794769@warthog.procyon.org.uk> From: Jann Horn Date: Wed, 4 Apr 2018 02:17:55 +0200 Message-ID: Subject: Re: [GIT PULL] Kernel lockdown for secure boot To: Linus Torvalds Cc: Matthew Garrett , Andrew Lutomirski , David Howells , Ard Biesheuvel , James Morris , Alan Cox , Greg Kroah-Hartman , Linux Kernel Mailing List , Justin Forbes , linux-man , joeyli , LSM List , Linux API , Kees Cook , linux-efi Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 4, 2018 at 2:06 AM, Linus Torvalds wrote: > On Tue, Apr 3, 2018 at 4:59 PM, Matthew Garrett wrote: >> >> Ok. So we can build distribution kernels that *always* have this on, and to >> turn it off you have to disable Secure Boot and install a different kernel. > > Bingo. > > Exactly like EVERY OTHER KERNEL CONFIG OPTION. > > Just like all the ones that I've mentioned several times. > > 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. > > Again, in no case does it make sense to tie it into "how did we boot". > Because that's just inconvenient for everybody. Without taking a stance regarding whether I think that kernel lockdown makes sense, I think Matthew's point is this: If you don't have lockdown, secure boot doesn't provide a benefit, since an attacker could just modify the init binary instead of messing with your kernel. If you have secure boot, you want lockdown to prevent chainloading into a backdoored version of the real OS.