Re: [GIT PULL] Kernel lockdown for secure boot

[Andy Lutomirski]

On Tue, Apr 3, 2018 at 9:29 AM, Matthew Garrett <mjg59@xxxxxxxxxx> wrote:
> On Tue, Apr 3, 2018 at 8:11 AM Andy Lutomirski <luto@xxxxxxxxxx> 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.