On Thu, Feb 27, 2014 at 2:11 PM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > On Thu, Feb 27, 2014 at 2:07 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: >> On Thu, Feb 27, 2014 at 01:04:34PM -0500, Josh Boyer wrote: >>> On Wed, Feb 26, 2014 at 3:11 PM, Matthew Garrett >>> <matthew.garrett@xxxxxxxxxx> wrote: >>> > The conclusion we came to at Plumbers was that this patchset was basically >>> > fine but that Linus hated the name "securelevel" more than I hate pickled >>> > herring, so after thinking about this for a few months I've come up with >>> > "Trusted Kernel". This flag indicates that the kernel is, via some >>> > external mechanism, trusted and should behave that way. If firmware has >>> > some way to verify the kernel, it can pass that information on. If userspace >>> > has some way to verify the kernel, it can set the flag itself. However, >>> > userspace should not attempt to use the flag as a means to verify that the >>> > kernel was trusted - untrusted userspace could have set it on an untrusted >>> > kernel, but by the same metric an untrusted kernel could just set it itself. >>> >>> FWIW, I've been running a kernel using this patchset in place of the >>> patchset Fedora typically carries for this purpose for a bit. Things >>> appear to be working as expected and the protections remain the same. >>> >>> It would be really nice to get this set of patches in so some of the >>> other patches that depend on them can start being pushed as well. >> >> What other patches depend on this series? Why aren't they also in this >> series? > > The patches we have to import certificates from the UEFI db and dbx > vars, and MokListRT and apply them to signed module verification. > Looking at them closely, there are pieces that could be sent now as > they are slightly orthogonal to what this patchset is doing, which is > probably why they aren't in this patchset to begin with. I'll have to > figure out which of those actually depend on anything in Matthew's > series. OK, I figured it out. I have a patch that adds an EFI_SECURE_BOOT x86_efi_facility bit, and that is used in the later patches where applicable. The patch that adds it depends on patch 12 in Matthew's series. There are a few patches that are mostly stand-alone and I'll try and get those sent out soon. They're a mix of things from David Howells and myself, and should probably go through the security tree. josh -- To unsubscribe from this list: send the line "unsubscribe linux-efi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
