From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BA59F16EC for ; Wed, 5 Sep 2018 20:34:06 +0000 (UTC) Received: from mail-wm0-f66.google.com (mail-wm0-f66.google.com [74.125.82.66]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3390B81A for ; Wed, 5 Sep 2018 20:34:06 +0000 (UTC) Received: by mail-wm0-f66.google.com with SMTP id b19-v6so9288545wme.3 for ; Wed, 05 Sep 2018 13:34:06 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <32341.1536178494@warthog.procyon.org.uk> References: <17533.1536166384@warthog.procyon.org.uk> <32341.1536178494@warthog.procyon.org.uk> From: Justin Forbes Date: Wed, 5 Sep 2018 15:34:04 -0500 Message-ID: To: David Howells Content-Type: text/plain; charset="UTF-8" Cc: James.Bottomley@hansenpartnership.com, Peter Jones , joeyli.kernel@gmail.com, ksummit-discuss@lists.linuxfoundation.org Subject: Re: [Ksummit-discuss] [TECH TOPIC] Kernel lockdown and secure boot List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Wed, Sep 5, 2018 at 3:14 PM, David Howells wrote: > Justin Forbes wrote: > >> Lockdown is a config option on it's own, just also add a separate >> config option option to enable lockdown on UEFI secure boot. > > The patchset has that already (CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT). > > One of the issues appears to be that we're making it boot-time conditional at > all. If I understand him correctly, Linus seems to want us to make everything > locked down at compile time or not at all. > The last push attempt dropped that patch and did have the compile time (CONFIG_LOCK_DOWN_MANDATORY) as well as an option for command line enabling with lockdown=1 (CONFIG_LOCK_DOWN_KERNEL). It just didn't have an option for triggering off of UEFI Secure Boot. As a distro, running CONFIG_LOCK_DOWN_MANDATORY isn't much of an option. We ran the 4.17 development series in rawhide with CONFIG_LOCK_DOWN_KERNEL, and no one noticed that their secure boot was off. This is why it is somewhat frightening to change the behavior, users assume it is all working because things boot, and never notice they are missing some protection that they assumed was there. Before we rebased stable distros I reworked the CONFIG_LOCK_DOWN_IN_EFI_SECURE_BOOT to work with the current patch set and that is what we are carrying now. While I would love to see everything pushed as a whole, I would still be much happier than I am now if everything else pushed and we only had to carry the patch to trigger off of UEFI status. It is a minor detail that shouldn't be blocking the entire patch set at this point. If Linus agrees that it can be pushed with CONFIG_LOCK_DOWN_MANDATORY as the only option, that is fine. Still much less out of tree for us to worry about.