[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 04 Apr 2018 16:26:43 +0000
From: Matthew Garrett <mjg59@...gle.com>
To: oiaohm@...il.com
Cc: Linus Torvalds <torvalds@...ux-foundation.org>, luto@...nel.org,
David Howells <dhowells@...hat.com>,
Ard Biesheuvel <ard.biesheuvel@...aro.org>, 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>,
jforbes@...hat.com, linux-man@...r.kernel.org, jlee@...e.com,
LSM List <linux-security-module@...r.kernel.org>,
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 11:56 PM Peter Dolding <oiaohm@...il.com> wrote:
> On Wed, Apr 4, 2018 at 11:13 AM, Matthew Garrett <mjg59@...gle.com> 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.
Powered by blists - more mailing lists