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 9:29 AM, Matthew Garrett <mjg59@google.com> wrote:
    > On Tue, Apr 3, 2018 at 8:11 AM Andy Lutomirski <luto@kernel.org> wrote:
    >> Can you explain that much more clearly? I'm asking why booting via
    >> UEFI Secure Boot should enable lockdown, and I don't see what this has
    >> to do with kexec. And "someone blacklist[ing] your key in the
    >> bootloader" sounds like a political issue, not a technical issue.
    >
    > A kernel that allows users arbitrary access to ring 0 is just an
    > overfeatured bootloader. Why would you want secure boot in that case?

    To get a chain of trust. I can provision a system with some public
    keys, stored in UEFI authenticated variables, such that the system
    will only boot a signed image. That signed image, can, in turn, load
    a signed (or hashed or otherwise verfified) kernel and a verified
    initramfs. The initramfs can run a full system from a verified (using
    dm-verity or similar) filesystem, for example. Now it's very hard to
    persistently attack this system. Chromium OS does something very much
    like this, except that it doesn't use UEFI as far as I know. So does
    iOS, and so do some Android versions. None of this requires lockdown,
    or even a separation between usermode and kernelmode, to work
    correctly. One could even do this on an MMU-less system if one really
    cared to. More usefully, someone probably has done this using a
    unikernel.

    If I had to guess at a motivation that makes this patchset work, it
    would be that there is an uneasy truce between Microsoft and the
    various vendors of signed Linux bootloaders. That truce could
    conceivably require that the signed bootloaders not knowingly ship a
    system that allows a non-physically-present user to chainload Windows.
    If so, the patchset should say that loud and clear in its description
    and the parts that block bpf should go away.

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