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 EA8C6724 for ; Wed, 3 Aug 2016 04:46:13 +0000 (UTC) Received: from mail-vk0-f54.google.com (mail-vk0-f54.google.com [209.85.213.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4F0E822C for ; Wed, 3 Aug 2016 04:46:13 +0000 (UTC) Received: by mail-vk0-f54.google.com with SMTP id x130so138056624vkc.0 for ; Tue, 02 Aug 2016 21:46:13 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20160803073731-mutt-send-email-mst@kernel.org> References: <20160803073731-mutt-send-email-mst@kernel.org> From: Andy Lutomirski Date: Tue, 2 Aug 2016 21:46:11 -0700 Message-ID: To: "Michael S. Tsirkin" Content-Type: multipart/alternative; boundary=001a1143092244f262053923830b Cc: Josh Boyer , Jason Cooper , "ksummit-discuss@lists.linuxfoundation.org" , James Bottomley , 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: , --001a1143092244f262053923830b Content-Type: text/plain; charset=UTF-8 On Aug 2, 2016 9:42 PM, "Michael S. Tsirkin" wrote: > > On Tue, Aug 02, 2016 at 09:34:14PM -0700, Andy Lutomirski wrote: > > 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. > > Hmm. I kind of like ability to build and add modules to a running > kernel. And I think some distros might use it too, updating modules > without updating the kernel (doesn't work if you discard the key, > obviously). I have no plans to prevent the existing module signature verification scheme from working. I just see no reason that in-tree modules should need to be signed. > > > > 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? > > Typically already possible with firmware menus. Sure, but I'm trying to understand what types of attacks we need to resist. --001a1143092244f262053923830b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Aug 2, 2016 9:42 PM, "Michael S. Tsirkin" <<= a href=3D"mailto:mst@redhat.com">mst@redhat.com> wrote:
>
> On Tue, Aug 02, 2016 at 09:34:14PM -0700, Andy Lutomirski wrote:
> > On Tue, Aug 2, 2016 at 8:32 PM, Matthew Garrett <mjg59@coreos.com> wrote:
> > > On Tue, Aug 2, 2016 at 7:58 PM, Andy Lutomirski <luto@amacapital.net> wrote:
> > >>=C2=A0 - Appeasing the Secure Boot deities.=C2=A0 AFAIK t= his 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-si= gned
> > > object can be used to compromise other operating systems, Mi= crosoft
> > > may unilaterally blacklist that object. Allowing arbitrary m= odule
> > > loading or arbitrary kexec clearly makes it straightforward = to simply
> > > use a signed Linux boot chain to then boot a compromised ver= sion of
> > > any other operating system, defeating the point of Secure Bo= ot.
> >
> > > Distro
> > > keys are used for module signing because that's the easi= est way to
> > > handle it (sign them during build and then discard the key),=
> >
> > With my module hashing patches, that'll be even simpler.=C2= =A0 The kernel
> > image will contain a list of SHA256 hashes of in-tree .ko files a= nd
> > will accept those files.
>
> Hmm. I kind of like ability to build and add modules to a running
> kernel. And I think some distros might use it too, updating modules > without updating the kernel (doesn't work if you discard the key,<= br> > obviously).

I have no plans to prevent the existing module signature ver= ification scheme from working.=C2=A0 I just see no reason that in-tree modu= les should need to be signed.

>
> > > UEFI keys
> > > are used to appease some manufacturers (they can ship their<= br> > > > 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.=C2=A0 Would it be okay if a physically present user could su= bvert it?
> > For example, if a physically present user typed "insecure&qu= ot; into a
> > bootloader command line and thus turned off signature verificatio= n?
>
> Typically already possible with firmware menus.

Sure, but I'm trying to understand what types of attacks= we need to resist.

--001a1143092244f262053923830b--