[lkml]   [2018]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [GIT PULL] Kernel lockdown for secure boot
On Wed, Apr 4, 2018 at 11:39 AM, Andy Lutomirski <> wrote:
> On Wed, Apr 4, 2018 at 9:22 AM, Matthew Garrett <> wrote:
>> On Wed, Apr 4, 2018 at 6:52 AM Theodore Y. Ts'o <> wrote:
>>> On Wed, Apr 04, 2018 at 02:33:37PM +0100, David Howells wrote:
>>> > Theodore Y. Ts'o <> wrote:
>>> >
>>> > > Whoa. Why doesn't lockdown prevent kexec? Put another away, why
>>> > > isn't this a problem for people who are fearful that Linux could be
>>> > > used as part of a Windows boot virus in a Secure UEFI context?
>>> >
>>> > Lockdown mode restricts kexec to booting an authorised image (where the
>>> > authorisation may be by signature or by IMA).
>>> If that's true, then Matthew's assertion that lockdown w/o secure boot
>>> is insecure goes away, no?
>> If you don't have secure boot then an attacker with root can modify your
>> bootloader or kernel, and on next boot lockdown can be silently disabled.
> This has been rebutted over and over and over. Secure boot is not the
> only verified boot mechanism in the world. Other, better, much more
> auditable, and much simpler mechanisms have been around for a long,
> long time.
That is certainly the case, and one of the main reasons for the
secureboot patchset being split out and lockdown taking a different
name. The problem is, right now, secure boot is the only thing using
lockdown. I certainly wouldn't go through any effort to tie into it
with any other mechanism knowing that this patch set has been delayed
upstream for years. I would hope and expect that once lockdown is in
mainline, other verified boot mechanisms would leverage it as well.

>>> 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.
> And that's a giant hack. The actual feature should be that a user
> proves physical presence and thus disables lockdown *without*
> disabling verification.
> --Andy

 \ /
  Last update: 2018-04-04 18:47    [W:0.110 / U:0.496 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site