Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753653AbaB0TLJ (ORCPT ); Thu, 27 Feb 2014 14:11:09 -0500 Received: from mail-oa0-f50.google.com ([209.85.219.50]:35501 "EHLO mail-oa0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751663AbaB0TLH (ORCPT ); Thu, 27 Feb 2014 14:11:07 -0500 MIME-Version: 1.0 In-Reply-To: <20140227190710.GA4755@kroah.com> References: <1393445473-15068-1-git-send-email-matthew.garrett@nebula.com> <20140227190710.GA4755@kroah.com> Date: Thu, 27 Feb 2014 14:11:07 -0500 X-Google-Sender-Auth: xD46IXPiUIkI3qwcBK4qa14S4Jg Message-ID: Subject: Re: Trusted kernel patchset for Secure Boot lockdown From: Josh Boyer To: Greg KH Cc: Matthew Garrett , "Linux-Kernel@Vger. Kernel. Org" , Kees Cook , "H. Peter Anvin" , "linux-efi@vger.kernel.org" , James Morris , linux-security-module Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 27, 2014 at 2:07 PM, Greg KH 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 >> 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. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/