From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-8.6 required=3.0 tests=DKIMWL_WL_MED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_PASS,USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id C52A2C282CE for ; Fri, 5 Apr 2019 22:19:21 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8DB4021871 for ; Fri, 5 Apr 2019 22:19:21 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="Bc0tJq9N" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726218AbfDEWTU (ORCPT ); Fri, 5 Apr 2019 18:19:20 -0400 Received: from mail-it1-f195.google.com ([209.85.166.195]:51564 "EHLO mail-it1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726124AbfDEWTU (ORCPT ); Fri, 5 Apr 2019 18:19:20 -0400 Received: by mail-it1-f195.google.com with SMTP id s3so12071558itk.1 for ; Fri, 05 Apr 2019 15:19:20 -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=p70rh8DzLMoO9YQR1wIHClyyXHDpqpEks55cuvOjfCY=; b=Bc0tJq9N/sPYw85QXGSIH0hbEtzljs8EWItZ9MIwCmNwpRUoa/Wpc5hsHoxnO/te/o O3F7X0+2bCdaluN6rPhO4hAZPUmPfFaaJIknDhttv3aW3vSR2RBpC49xL+P10rlIABz2 FtRzhFhWl+sdRw1u7SF5C+Ul/CUNeqzj2OmmTtoUzMM/nubLgmCHk1xDxXr9CenY1pcQ b0moIO332HU3WYNlXK8fBIj84fYUgtIGZOcp9farU3QDzoBMhwPPDbrro6c1+P9Jk9BI dtakwadfwEhfde93OHQh09dc8rKxnXgvtSMn54RFzPcjbCcm/hATCmPV1sGr1TIM37QO ZEvQ== 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=p70rh8DzLMoO9YQR1wIHClyyXHDpqpEks55cuvOjfCY=; b=oFhw354GDU/X+H8jU0Y2LUy6xF/ZFsg6ddHt4kC6T+t16FW7zanVffAOgx7nb9636R 2ua6f/7Ehnd6l8u3hEDKQ+WokEKz0JgyzFOmxyRqrRdziHphWwManwCuVRxkcigfvHi7 V2yNkyP9yFGxNbsz93UlsSkBtPyAMZFHL6lf5+nhJK8/L5cn7PO/2RuZDAFG9qJc70K7 qAFmjc+uxFvvacl8mo94uQhfkVMXp0xhPuIG6vGHaG7qQegtp1FNzRKz5QhZ12tNijUo 4+VK+ZGF0aMjMrqtbea2zZ/6Seq4j5qIOjDrUqlxc3BOxL1xu8AnpoBRZ4q7hAZsDMzD FYbw== X-Gm-Message-State: APjAAAVC+taAW0lkHZ9QT4IObcaFyp4Ipnyw8iPz+ai+pZKG2yv/L8wR G8AWp/TogZIjf90OGQdxNIKAouQVUjKm1wiwOtRrMdJ/ X-Google-Smtp-Source: APXvYqz8L0DRIH950OrISsoMW75m56cdjyA82W8JwtiaTtpNLc8MeWdCquXt/H6qVstvEF2gn6aGUbrGlapaBmieosc= X-Received: by 2002:a02:1a45:: with SMTP id 66mr11594981jai.124.1554502759204; Fri, 05 Apr 2019 15:19:19 -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> In-Reply-To: From: Matthew Garrett Date: Fri, 5 Apr 2019 15:19:07 -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 Content-Type: text/plain; charset="UTF-8" Sender: linux-integrity-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-integrity@vger.kernel.org On Fri, Apr 5, 2019 at 2:11 PM Claudio Carvalho wrote: > > > On 4/3/19 7:27 PM, Matthew Garrett wrote: > > Not supporting dbx seems like a pretty significant shortcoming. How > > are signatures meant to be revoked? > > > We began by focusing on certificates for keys that can be added at > runtime. Before adding support for revocation, we plan to gather > additional use cases. In the meantime, unwanted certificates can be > removed by the administrator. 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. > > > > >> PK, KEK and db updates will be signed the same way, that is, using > >> userspace tooling like efitools in PowerNV. As for the authentication > >> descriptors, only the EFI_VARIABLE_AUTHENTICATION_2 descriptor will be > >> supported. > > Is this API documented? > > > The API is still a work in progress. We are planning to publish a document > describing the current API and overall design shortly. Ok. How are the attributes interpreted by the API? > 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 written 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 TPM > 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? > > I think that depends on exactly what problem you're trying to solve. > > Some aspects of the EFI secure boot design end up mirroring the > > economics of the PC ecosystem rather than being inherently good design > > goals, so it'd be helpful to know whether you're taking this solution > > because you want the same three-level key infrastructure or because > > that just leaves you compatible with the tooling. > > > In our use case, the three-level key hierarchy conveniently supports the > concept of (1) an administrator authority, who authorizes (2) other > organizations, e.g., distros, to provide (3) certificates for their code > signing keys. By using efivars, we leverage pre-existing userspace EFI > tools to generate authenticated updates and certificates. Additionally, > pre-existing kernel infrastructure simplifies efivars processing. 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?