From mboxrd@z Thu Jan 1 00:00:00 1970 From: Matthew Garrett Subject: Re: [GIT PULL] Kernel lockdown for secure boot Date: Wed, 04 Apr 2018 16:26:43 +0000 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org To: oiaohm@gmail.com Cc: Linus Torvalds , luto@kernel.org, David Howells , Ard Biesheuvel , jmorris@namei.org, Alan Cox , Greg Kroah-Hartman , Linux Kernel Mailing List , jforbes@redhat.com, linux-man@vger.kernel.org, jlee@suse.com, LSM List , linux-api@vger.kernel.org, Kees Cook , linux-efi List-Id: linux-api@vger.kernel.org On Tue, Apr 3, 2018 at 11:56 PM Peter Dolding wrote: > On Wed, Apr 4, 2018 at 11:13 AM, Matthew Garrett wrote: > > There are four cases: > > > > Verified Boot off, lockdown off: Status quo in distro and mainline kernels > > Verified Boot off, lockdown on: Perception of security improvement that's > > trivially circumvented (and so bad) > > Verified Boot on, lockdown off: Perception of security improvement that's > > trivially circumvented (and so bad), status quo in mainline kernels > > Verified Boot on, lockdown on: Security improvement, status quo in distro > > kernels > > > > Of these four options, only two make sense. The most common implementation > > of Verified Boot on x86 platforms is UEFI Secure Boot, > Stop right there. Verified boot does not have to be UEFI secureboot. > You could be using a uboot verified boot or > https://www.coreboot.org/git-docs/Intel/vboot.html google vboot. > Neither of these provide flags to kernel to say they have been > performed. They can be modified to set the appropriate bit in the bootparams - the reason we can't do that in the UEFI case is that Linux can be built as a UEFI binary that the firmware execute directly, and so the firmware has no way to set that flag. > Now Verified Boot on, lockdown off. Insanely this can be required in > diagnostic on some embedded platform because EFI secureboot does not > have a off switch. These are platforms where they don't boot if > they don't have a PK and KEK set installed. Yes some of these is jtag > the PK and KEK set in. > The fact that this Verified Boot on, lockdown off causes trouble > points to a clear problem. User owns the hardware they should have > the right to defeat secureboot if they wish to. Which is why Shim allows you to disable validation if you prove physical user presence.