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 5A87498F for ; Tue, 2 Aug 2016 14:53:19 +0000 (UTC) Received: from mail-vk0-f46.google.com (mail-vk0-f46.google.com [209.85.213.46]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CB3F61C9 for ; Tue, 2 Aug 2016 14:53:18 +0000 (UTC) Received: by mail-vk0-f46.google.com with SMTP id w127so124466753vkh.2 for ; Tue, 02 Aug 2016 07:53:18 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20150804152622.GY30479@wotan.suse.de> <1468612258.5335.0.camel@linux.vnet.ibm.com> <1468612671.5335.5.camel@linux.vnet.ibm.com> <20160716005213.GL30372@sirena.org.uk> <1469544138.120686.327.camel@infradead.org> <20160727140406.GP4541@io.lakedaemon.net> <20160802140031.GK4541@io.lakedaemon.net> From: Andy Lutomirski Date: Tue, 2 Aug 2016 07:53:16 -0700 Message-ID: To: Jason Cooper Content-Type: multipart/alternative; boundary=001a11c0087e8dac55053917e0ec Cc: Mark Brown , "ksummit-discuss@lists.linuxfoundation.org" Subject: Re: [Ksummit-discuss] [TECH TOPIC] Signature management - keys, modules, firmware, was: Last minute nominations: mcgrof and toshi List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , --001a11c0087e8dac55053917e0ec Content-Type: text/plain; charset=UTF-8 On Aug 2, 2016 7:00 AM, "Jason Cooper" wrote: > > The problem here is that we (users) need to be able to verify that > iwlwifi-whatever.ucode claimed to be created by Intel, was indeed the > *same* one Intel shipped out the door. That's it. It's up to the user > to decide to "trust" Intel's microcode or not. All the kernel should be > doing is confirming cryptographically that it came from Intel. Except that this particular use case doesn't require any kernel support at all. If the goal is that root doesn't want to load a bad firmware, then root can check whatever signature it wants in userspace. The point of in-kernel verification is to enforce policies that are intended to work even if root is compromised. This includes CRDA-like policy and MS's Secure Boot policy. If, while doing this, we get to check vendor keys too, that's just an added benefit in my book. --001a11c0087e8dac55053917e0ec Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Aug 2, 2016 7:00 AM, "Jason Cooper" <jason@lakedaemon.net> wrote:

>
> The problem here is that we (users) need to be able to verify that
> iwlwifi-whatever.ucode claimed to be created by Intel, was indeed the<= br> > *same* one Intel shipped out the door.=C2=A0 That's it.=C2=A0 It&#= 39;s up to the user
> to decide to "trust" Intel's microcode or not.=C2=A0 All= the kernel should be
> doing is confirming cryptographically that it came from Intel.

Except that this particular use case doesn't require any= kernel support at all.=C2=A0 If the goal is that root doesn't want to = load a bad firmware, then root can check whatever signature it wants in use= rspace.

The point of in-kernel verification is to enforce policies t= hat are intended to work even if root is compromised.=C2=A0 This includes C= RDA-like policy and MS's Secure Boot policy.=C2=A0 If, while doing this= , we get to check vendor keys too, that's just an added benefit in my b= ook.

--001a11c0087e8dac55053917e0ec--