Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp5666534yba; Mon, 13 May 2019 15:10:14 -0700 (PDT) X-Google-Smtp-Source: APXvYqwQwNwngVahdq4ienSQVTVETC+7MLHqRC+s9toBwvhniu0iFE5QkUujR9zZmZuhCniHjTto X-Received: by 2002:a17:902:2869:: with SMTP id e96mr10230211plb.150.1557785414226; Mon, 13 May 2019 15:10:14 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557785414; cv=none; d=google.com; s=arc-20160816; b=Wun1GFodYRG7CJCg149pqXWAnnJOqYqL+CP+TcIhqvi7uvYYPYAK/z5y7ksYy43QOt 2SWPeIk3rjCumxc+lk2kLQhLsEmTCVAIooRE579QVG+GXMgpAWURhpCjmawNXOuqnugh xyPFUfTqQ4fzdQp1uFtvewK9SZ43x8l34AgKaEltvv7ZlX9Np1U42umFzTe1eFwJuo0K /rbtmVmch2BoiReCvEB7mNAhdzRv5LrnDBUpsf0sPW0xyGSNV6lOv96YGZtuD5Fc9E+I zn/B7jX/srzFZqXISvXH3JIc9+xWtMZvVvzssCKZd0XW7Sv96qE6CfBXTuQpqEmz+2C7 f+PA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=JIx3h0Mt9J+/lEWG7UoB4dTDXrEgdUjpPED38EFg7mE=; b=Xe1CI15l0fmOi7WW+Br8D/ht1SWahJJHwafUkH50WGkDQMV/rZNm0MwbGvlCH/w/fH LO7ag4Rzcw81eHZrW0JNkF/AbyNw1ijqSJm/F8+0UDwHwo5pBXsWy6A8OM4T8kstQGyy V6KUdteNoJ5PuUDCqi0aafbppogfhWVQvHgTfQ7ANZC2QWA98QDe8ozRKmdWhVYXWngc VCJTuXj+cVYYOxzCaaYwVoFS1x0U8uvJ+5sRtZuqJwX1ds6BLIE8s0ki0IgG2lpKmIe4 ZmcDgjcR643spC36dUUfI77ArcngTh6KuQDavVacbs9/iOiqE+5czQGx6Qf2sqS8/+Q8 h55g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=iEelTsof; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id h11si5024009pgq.170.2019.05.13.15.09.57; Mon, 13 May 2019 15:10:14 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=iEelTsof; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726720AbfEMWGd (ORCPT + 99 others); Mon, 13 May 2019 18:06:33 -0400 Received: from mail-it1-f196.google.com ([209.85.166.196]:51247 "EHLO mail-it1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726677AbfEMWGc (ORCPT ); Mon, 13 May 2019 18:06:32 -0400 Received: by mail-it1-f196.google.com with SMTP id s3so1736772itk.1 for ; Mon, 13 May 2019 15:06:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JIx3h0Mt9J+/lEWG7UoB4dTDXrEgdUjpPED38EFg7mE=; b=iEelTsof+PDlHfZHmpCsN1rfQAIAXGmSyIh/ZEbPdRedDgxTFdUqLg7anbmYK8zGgN mz8ec7r6euQ3VdSjSndqQ+ytzbNVB+gjBfW8lG6QX3FwNyK/tEc1Dk16ORUDOgNmv/0C 4vLbedTDkGwHilbifp4a9lVkTsWEGkEMtJJd73f0KAXfI+Xet0TkUTeP433yvMpHTQi9 O9J36p+2xqo2BqojOCPSot1JMnD43wgjzsgdNKLKub4yrbwbLpC7SeabpGWTsm4GIjR9 hsCs+/3nZwxaS3FHvCsJLQ0bkls0A64xkM7XrdDtyDIyk3wEp1t49+RTCwdpUbVR8Ygc ZXYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JIx3h0Mt9J+/lEWG7UoB4dTDXrEgdUjpPED38EFg7mE=; b=gkUNjjQ9ZEQmPLoD6lJCh3FH+YvKtAmhTvUrUvXiZILH9PX4EnWDi18ARdmyAkLVKi pS7/NP6Zws+GNmEkQjPppkmDxXNw3MsuoZlem8dJ759jfzvubLa95JqfBmAGboFeyKKN LOMv/FoYN78HRsq5IfhbsIHjLuYCL4Z2kQPUAQfUdU6y6iqZ1a9unsgCBi+05bxRZ5GO uzpUXEb8O8z1grcot01TpRfscVHEQ9ykvUYsSZErTCB8tE0M+Tz/nBiN3qRZ9XJaavLt 7RRnOrSgEJD3+mpzvgpJ2Y0+/qEdw1ESyrna9EI6bBJvrce8XhneLke0SQaBobg4aSO4 ZIRg== X-Gm-Message-State: APjAAAWyAHQa5jtZVFKokCR4LcjdRBLeT4puP4/IWldDuXYPR09UGC+S KaDW9ASbOuxdoM4g3v43Bh35oCO9wZJdYvA3DPFwqw== X-Received: by 2002:a24:e046:: with SMTP id c67mr66255ith.16.1557785191476; Mon, 13 May 2019 15:06:31 -0700 (PDT) MIME-Version: 1.0 References: <20190402181505.25037-1-cclaudio@linux.ibm.com> <4ce5e057-0702-b0d5-7bb2-cea5b22e2efa@linux.ibm.com> <2208f156-d441-3082-2f4c-8030c84ef788@linux.ibm.com> <28bfc0a7-9ae5-2c99-e472-ea53f856bafc@linux.ibm.com> In-Reply-To: From: Matthew Garrett Date: Mon, 13 May 2019 15:06:20 -0700 Message-ID: Subject: Re: [PATCH 0/4] Enabling secure boot on PowerNV systems To: Claudio Carvalho Cc: linuxppc-dev@ozlabs.org, linux-efi , linux-integrity , Linux Kernel Mailing List , Michael Ellerman , Paul Mackerras , Ard Biesheuvel , Jeremy Kerr , Matthew Garret , Nayna Jain , Peter Jones Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 10, 2019 at 2:31 PM Claudio Carvalho wrote: > On 4/10/19 2:36 PM, Matthew Garrett wrote: > > I don't see the benefit in attempting to maintain compatibility with > > existing tooling unless you're going to be *completely* compatible > > with existing tooling. That means supporting dbx and dbt. (snip) > In OS secure boot domain (work in progress): > - The skiroot container is verified as part of firmware secure boot. > - Skiroot uses UEFI-like secure variables (PK, KEK and db) to verify OS > kernels. Only X.509 certificates will be supported for these secure variables. You don't support hashes? If so, this isn't compatible with UEFI Secure Boot and we shouldn't try to make it look like UEFI Secure Boot. > How about dbx and dbt? > > The db keys will be used to verify only OS kernels via kexecs initiated by > petitboot. So we only need the dbx to revoke kernel images, either via > certs or hashes. Currently, the kernel loads certs and hashes from the dbx > to the system blacklist keyring. The revoked certs are checked during pkcs7 > signature verification and loading of keys. However, there doesn't appear > to be any verification against blacklisted hashes. Should kernel images be > revoked only by keys and not hashes? We tried to find published revoked > kernel lists but couldn't find any. How is kernel image revocation handled > in practice? Hash-based revocation is in active use in the UEFI world - to the best of my knowledge, all existing dbx entries are hashes with the exception of the invalidation of the Microsoft Windows 2010 CA. > Also, we didn't see the shim or kernel loading anything from dbt. dbt is currently only used for validation at the firmware level - the way grub and kernel signatures are currently managed means it doesn't make a huge amount of sense to use it in shim, but it would probably be reasonable to extend shim's validation to include dbt. > > So I do the following: > > > > 1) Boot > > 2) Extend the contents of db > > 3) Extend the contents of db again > > 4) Read back the contents of db through efivarfs > > 5) Reboot > > 6) Read back the contents of db through efivarfs > > > > Is what I see in (4) and (6) the same? Does it contain the values form > > both extensions? > > In (2) and (3) the extensions are added to the update queue, which is > processed only in (5) by firmware. So, in (4) you should see the db content > without the extensions. Ok, this is not what we expect from UEFI systems. I'm strongly against providing what looks like the same ABI on multiple platforms but carrying subtle differences between those platforms - it's guaranteed to break tooling in unexpected ways. > In (5), firmware (skiboot) will process the update queue. The extensions > will be applied only if *all* of them are valid and pass signature > verification. Only in this case should you be able to see the extensions in > (6). If any of the extensions fail, firmware will discard all of them, > clear the queue, and do the proper logging. I believe that this is also a violation of expectations. > > Why would the intermediate level organisations not just have entries > > in db? > > Because that seems to add more complexity than having three levels (PK, KEK > and db). > > Typically, the intermediate level organisations (or KEK) are used to > authorize new additions to db. However, if we also have them in the db, who > would authorize the new additions to db. If that would be the intermediate > level organisation entries now in the db, it seems we would need to > implement a mechanism to determine which entries are for authorizing new > additions and which are for kernel signature verification. If that would be > the PK, we'd be burdening the PK owner to sign every new db addition if the > platform is owned by a company that has intermediate level organizations. Ok, in this scenario I don't understand why you wouldn't just want the intermediates in PK. Or, put another way - if you have a business justification for three layers of hierarchy, what do you do when someone has a business justification for four? The three layer hierarchy represents the weirdness of the PC industry where you have Microsoft needing to be in KEK (because they need to be able to issue updates to machines from multiple vendors) but not wanting to be in PK (because vendors don't want Microsoft to have ultimate control over their systems). If it weren't for this conflict, we'd just have a two layer hierarchy, and if some other aspect of the market had evolved over time we'd have a four layer hierarchy. > > > The main reason we don't do it this way in UEFI is because we > > need to support dbx, and if you're not supporting dbx I'm not sure I > > see the benefit. > > I'm not sure I understand your question. We would be using dbx to prevent > kernels from being loaded. How is that related to having three levels in > the key hierarchy (PK, KEK and db)? dbx entries come from Microsoft, so we need the KEK layer so Microsoft can update dbx. If Microsoft didn't need to update dbx then we'd leave Microsoft out of KEK, and then KEK and PK would be the same and we'd be able to get rid of KEK.