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 06C6B87A for ; Wed, 3 Aug 2016 05:16:00 +0000 (UTC) Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com [209.85.161.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 31004112 for ; Wed, 3 Aug 2016 05:15:59 +0000 (UTC) Received: by mail-yw0-f179.google.com with SMTP id j12so217701608ywb.2 for ; Tue, 02 Aug 2016 22:15:59 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: From: Matthew Garrett Date: Tue, 2 Aug 2016 22:15:57 -0700 Message-ID: To: Andy Lutomirski 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 9:34 PM, Andy Lutomirski wrote: > On Tue, Aug 2, 2016 at 8:32 PM, Matthew Garrett wrote: >> 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? A physically present user can just disable Secure Boot. Shim has support for doing this, at which point enforcement is disabled for the rest of the boot chain. >>> - 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. Yeah, I think in general this would be incredibly useful. There's various things that I've ended up implementing in x86 specific ways because there's no standard way to pass significant quantities of data between the boot environment and the kernel proper. DeviceTree is probably the closest we have, but it's still somewhat architecture specific and then we're suddenly having to deal with DTB+ACPI scenarios we haven't necessarily planned for.