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. -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
