lkml.org 
[lkml]   [2018]   [Apr]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [GIT PULL] Kernel lockdown for secure boot
    On Tue, Apr 3, 2018 at 5:17 PM, Jann Horn <jannh@google.com> wrote:
    > On Wed, Apr 4, 2018 at 2:06 AM, Linus Torvalds
    > <torvalds@linux-foundation.org> wrote:
    >> On Tue, Apr 3, 2018 at 4:59 PM, Matthew Garrett <mjg59@google.com> 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.

    I don't think that's the argument here. Secure boot can be used to
    protect initramfs, since initramfs comes from the secure boot-verified
    bootloader. That verified initramfs can protect the init binary.

    As far as I can tell, what's really going on here is that there's a
    significant contingent here that wants to prevent Linux from
    chainloading something that isn't Linux. (There doesn't seem to be a
    real benefit to preventing Linux from chainloading Linux, since the
    chainloaded Linux is unlikely to let the attacker do much that the
    original rooted Linux kernel wouldn't have allowed.) In particular,
    Microsoft, which de facto controls most of the secure boot key
    ecosystem, doesn't want Windows to be chainloaded without having its
    signature verified.

    I admit I'm not quite sure why Microsoft considers this important.
    They already require a TPM for all new systems, and any important
    secrets can be sealed by the TPM such that a maliciously chainloaded
    Windows kernel couldn't access those secrets. But secure boot
    predates the WHQL TPM requirement if I remember correctly, and I
    suspect that we're seeing leftover requirements from
    secure-boot-but-no-TPM era.

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