From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A8378724 for ; Wed, 3 Aug 2016 04:34:36 +0000 (UTC) Received: from mail-vk0-f53.google.com (mail-vk0-f53.google.com [209.85.213.53]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EEF4A17D for ; Wed, 3 Aug 2016 04:34:35 +0000 (UTC) Received: by mail-vk0-f53.google.com with SMTP id n129so137271406vke.3 for ; Tue, 02 Aug 2016 21:34:35 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Andy Lutomirski Date: Tue, 2 Aug 2016 21:34:14 -0700 Message-ID: To: Matthew Garrett Content-Type: text/plain; charset=UTF-8 Cc: James Bottomley , Josh Boyer , Jason Cooper , "ksummit-discuss@lists.linuxfoundation.org" , Mark Brown Subject: Re: [Ksummit-discuss] [TOPIC] Secure/verified boot and roots of trust List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, Aug 2, 2016 at 8:32 PM, Matthew Garrett wrote: > On Tue, Aug 2, 2016 at 7:58 PM, Andy Lutomirski wrote: >> - Appeasing the Secure Boot deities. AFAIK this specifically >> requires that we verify the kernel and its modules using a combination >> of EFI-supplied and distro keys. > > Eh not quite. The rules are basically that if a Microsoft-signed > object can be used to compromise other operating systems, Microsoft > may unilaterally blacklist that object. Allowing arbitrary module > loading or arbitrary kexec clearly makes it straightforward to simply > use a signed Linux boot chain to then boot a compromised version of > any other operating system, defeating the point of Secure Boot. > Distro > keys are used for module signing because that's the easiest way to > handle it (sign them during build and then discard the key), With my module hashing patches, that'll be even simpler. The kernel image will contain a list of SHA256 hashes of in-tree .ko files and will accept those files. > UEFI keys > are used to appease some manufacturers (they can ship their > binary-only drivers signed with a key that's in firmware) and shim > keys are used to allow users to sign their own modules. Hmm. Would it be okay if a physically present user could subvert it? For example, if a physically present user typed "insecure" into a bootloader command line and thus turned off signature verification? >> - Bootloader supplies public keys and policy to the kernel. > > The main problem here is the lack of a standardised way of passing > data from bootloader to kernel. We can't just append a CPIO to the > initramfs because using arbitrary initramfs is a reasonable policy for > many usecases. Having a secure architecture-independent communications > channel between the bootloader and the kernel would be helpful in > various ways. Indeed. I wonder if we could design such a thing? Or at least something that requires only minimal arch-specific work.