Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp5134249yba; Wed, 10 Apr 2019 12:07:01 -0700 (PDT) X-Google-Smtp-Source: APXvYqzMGpzDOE8+ymYcee7oNnybyqcKgVXn9qZvA71HTqdCuW59hUXbpzhzeVHktfMbmOZDb0RI X-Received: by 2002:a17:902:7206:: with SMTP id ba6mr46208394plb.301.1554923221512; Wed, 10 Apr 2019 12:07:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1554923221; cv=none; d=google.com; s=arc-20160816; b=ZuMY6hoeWzLE4FgrnOAiF9e8rY1JMw11uo+Bz9LBrDWn/v3M2wUG0fTtZ5j9xVQ7Zb XnHXGFcAv9A2/Tudkht54zIUYc2z47DlcuZjj1cdtbzgpgYT7PjX3v9hJfjPWRBJ1RzG r++0cztTmzdjE/nGnZZ1VjzAMbR8/1GC7MJrNfkkr70MNI0hJHYD0XaPBgNval7x1iKq M02kfTTD0O5n1W+rf6aikC/eRQ1PDIL+r8gk/PpBWyU6sS3ePdu6zAdsFKWhOCu/hl9b Fg/jn5Bd6P6nuXWcS1R2ta2mWQ59DHeRwxERmBzitxOnUttrtkVlqActnETdB7MRMpsr up+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:cc:to:subject :message-id:date:from:in-reply-to:references:mime-version :dkim-signature; bh=fsdwxzllgm3TZiNS2RBUzUWgv7Kl8/L4XW2AecOXicU=; b=LCrk7AyJCn9ztnB7cxi2hQ5tiRpk6utGBAe2GUTMQWu9FF0iWbsIFMchHjaDZMWHys eDsHBsRVJayI79HsWe1wl095bB/3Adupt3FV3WV9sBjW0HQ7xGEoJN1m9+WxBerOb4fR SIAJH+i8ZocMwS8zoJKJFxzfa0OZtneSFVI1FHn38/Ry943KuG+musGevWGBJI5HR+m9 0gGQ9yC5aEReO0LHirEeVNUjXmsQ4vnE0DGtTUnhZg37KzXM9kAMVzIEUBFLRKOpOqwo DnrvcXP+OL9U6+tCM/wJs1UUJDkvImRn4AGykBrn1WN33LPcVh/0PayLPwBNhnq5RMLL 6olQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=bSJRSo5M; 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 v6si32643194pgk.320.2019.04.10.12.06.45; Wed, 10 Apr 2019 12:07:01 -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=bSJRSo5M; 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 S1729586AbfDJRgv (ORCPT + 99 others); Wed, 10 Apr 2019 13:36:51 -0400 Received: from mail-it1-f196.google.com ([209.85.166.196]:39061 "EHLO mail-it1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729573AbfDJRgu (ORCPT ); Wed, 10 Apr 2019 13:36:50 -0400 Received: by mail-it1-f196.google.com with SMTP id 139so4809508ita.4 for ; Wed, 10 Apr 2019 10:36:49 -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:content-transfer-encoding; bh=fsdwxzllgm3TZiNS2RBUzUWgv7Kl8/L4XW2AecOXicU=; b=bSJRSo5MsFgno1KgFsAA0YK3rrv031WHLUUGrO3xbQk7/2nDnoqhvqCJ15Ey02vmDN Hxk/8IqQAkGzzQ3RlVdOSQn4H8INleO5W/ThQpK7vUqwbxb2+jCr7keiDXwFtAWpkfNg 4hD9j7FmHX7letmuEOZ4IDSOF/QivdG51ubmLFeGqbYbQ9clMSR1PhFfW/qE8KibK+8n SoWGBelTt+/DKTHDgSuq1WRucP6zbuqnPF2e3eqSAq4rMjWweTMpOp4pCDSu6FCEESOu cWqbWQeM5QscA0I5BMqRgU6XQnly8tSmYOXLaNcPtKQvF6my5Rx67jZ5R2MBRepNeR4B dMEw== 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:content-transfer-encoding; bh=fsdwxzllgm3TZiNS2RBUzUWgv7Kl8/L4XW2AecOXicU=; b=uCQ5cgMXwfhzc6YWc7lpLZ7Lh+U2bSEfj8w1dqS+cJNwvk2ndyr0OoUYpkAZTE37ch SeBTmt2VsNazOqmByE9o+Xq0ulS7l2Pz2QhNB+Ok1OHcUkMW5EV/XL3U+cLlg+kTF9JW R1woCkppwmKnRzlicp49AfH3OvYBTgIqn9o2OkjiHHHJJ84Nzi6PjASK3O4m1XprgZHo RULUSTNKjVbpSVdIMzZUQ81lvfVubu2zPwqj4NztQmILAnBIVXkhLNs23t1JrFLmFkh+ yaru3Q39zYTMPpibHjriRPHl3ZxYcoB967W39MltSDY3PyJ7K9zVW7ONYhvivsn8E58O bciw== X-Gm-Message-State: APjAAAUebSJQQWgmkzD+GshDqWf7DPgFwjGlI+OXTA+bz5J+JZQMgo0P 247vclE8XhzmjbLU6nfNkqBpmcQqWB0yysF0bjPq9A== X-Received: by 2002:a24:7294:: with SMTP id x142mr4445023itc.7.1554917808975; Wed, 10 Apr 2019 10:36:48 -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: <28bfc0a7-9ae5-2c99-e472-ea53f856bafc@linux.ibm.com> From: Matthew Garrett Date: Wed, 10 Apr 2019 10:36:36 -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 , Benjamin Herrenschmidt , Ard Biesheuvel , Jeremy Kerr , Matthew Garret , Nayna Jain , Peter Jones Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org (Cc:ing Peter Jones) On Tue, Apr 9, 2019 at 3:55 PM Claudio Carvalho wr= ote: > > > On 4/5/19 7:19 PM, Matthew Garrett wrote: > > Based on our experience doing this in UEFI, that's insufficient - you > > want to be able to block individual binaries or leaf certificates > > without dropping trust in an intermediate certificate entirely. > > > We agree that a dbx would be useful for blacklisting particular kernels > signed with given certificate. However, we have been avoiding doing so fo= r > the initial release of secure boot on OpenPOWER. We don't have individual > firmware binaries in OpenPOWER. Kernels are currently the only concern fo= r > the OS secure boot certificates we're discussing here. Also, we have a ve= ry > limited keystore space in POWER9. > > Petitboot doesn't have standardized OS kernel verification at all right > now. Having the capability even without dbx seems valuable. 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. > >> The API is still a work in progress. We are planning to publish a doc= ument > >> describing the current API and overall design shortly. > > Ok. How are the attributes interpreted by the API? > > > We support a subset of standard EFI variable attributes, and we only use > EFI variables that relate to secure boot. Our goal is not to implement > UEFI. However, we do seek to be compatible with user space tooling and > reuse as much existing infrastructure as possible. We don=E2=80=99t suppo= rt the > following: EFI_VARIABLE_HARDWARE_ERROR_RECORD, > EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS and > EFI_VARIABLE_ENHANCED_AUTHENTICATED_ACCESS. Ok. I think that's realistically fine. > > > > >> Perhaps the biggest departure is that the secure variables are stored = in > >> flash memory that is not lockable. In order to protect the secure > >> variables, hashes of the flash regions where they're stored are writte= n to > >> TPM NVRAM indices. The TPM NVRAM indices we use are write locked at > >> runtime. The sysadmin enqueues update commands in flash. During the = next > >> boot, the firmware verifies and processes the commands to update the > >> certificate store and accompanying integrity hashes in the TPM NVRAM > >> indices and write locks them. Before certificates read from flash are > >> used, the certificate store is hashed and compared against the hashes > >> stored from the TPM. The one exception is the PK. We store it in a TP= M > >> NVRAM index by itself rather than flash because updates to it must be > >> guaranteed to be atomic. > > What's the behaviour if multiple updates are enqueued? Does reading > > back show a mocked up updated variable or the original state? > > > Our secure variable updates are only applied at boot time. If any one of > them fails, they all fail. 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? > > I'm not really clear on the workflow here. Who's the administrator > > authority? When would they be updating the second level of keys? If > > there's no support for revocation, why would distributions need two > > levels of key in the system database rather than just distributing a > > single intermediate and signing their actual signing certs with that? > > > In OpenPOWER systems, we enable our customers and business partners to > establish and manage the platform key certificate, which is the root of o= ur > key hierarchy. From there, through the KEK, they can delegate authority t= o > intermediate level organizations, e.g. distros or IT departments or > business operations. Those intermediate level organizations then manage t= he > code signing certificates in the DB. If this answer doesn=E2=80=99t addre= ss your > question, can you please rephrase? Why would the intermediate level organisations not just have entries in db? 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.