linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Claudio Carvalho <cclaudio@linux.ibm.com>
To: Matthew Garrett <mjg59@google.com>
Cc: linuxppc-dev@ozlabs.org, linux-efi <linux-efi@vger.kernel.org>,
	linux-integrity <linux-integrity@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Paul Mackerras <paulus@samba.org>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Ard Biesheuvel <ard.biesheuvel@linaro.org>,
	Jeremy Kerr <jk@ozlabs.org>,
	Matthew Garret <matthew.garret@nebula.com>,
	Nayna Jain <nayna@linux.ibm.com>
Subject: Re: [PATCH 0/4] Enabling secure boot on PowerNV systems
Date: Tue, 2 Apr 2019 20:31:19 -0300	[thread overview]
Message-ID: <2208f156-d441-3082-2f4c-8030c84ef788@linux.ibm.com> (raw)
In-Reply-To: <CACdnJusBm93zwDqTXTx_QYsg1-aGUAAHm_qq8Lcx3TvGTxdmbg@mail.gmail.com>


On 4/2/19 6:51 PM, Matthew Garrett wrote:
> On Tue, Apr 2, 2019 at 2:11 PM Claudio Carvalho <cclaudio@linux.ibm.com> wrote:
>> We want to use the efivarfs for compatibility with existing userspace
>> tools. We will track and match any EFI changes that affect us.
> So you implement the full PK/KEK/db/dbx/dbt infrastructure, and
> updates are signed in the same way?

For the first version, our firmware will implement a simplistic PK, KEK and
db infrastructure (without dbx and dbt) where only the Setup and User modes
will be supported.

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.


>> Our use case is restricted to secure boot - this is not going to be a
>> general purpose EFI variable implementation.
> In that case we might be better off with a generic interface for this
> purpose that we can expose on all platforms that implement a secure
> boot key hierarchy. Having an efivarfs that doesn't allow the creation
> of arbitrary attributes may break other existing userland
> expectations.
>
For what it's worth, gsmi uses the efivars infrastructure for EFI-like
variables.

What might a generic interface look like?  It would have to work for
existing secure boot solutions - including EFI - which would seem to imply
changes to userspace tools.

Claudio



  reply	other threads:[~2019-04-02 23:31 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-02 18:15 [PATCH 0/4] Enabling secure boot on PowerNV systems Claudio Carvalho
2019-04-02 18:15 ` [PATCH 1/4] powerpc/include: Override unneeded early ioremap functions Claudio Carvalho
2019-04-02 18:15 ` [PATCH 2/4] powerpc/powernv: Add support for OPAL secure variables Claudio Carvalho
2019-04-02 18:15 ` [PATCH 3/4] powerpc/powernv: Detect the secure boot mode of the system Claudio Carvalho
2019-04-02 18:15 ` [PATCH 4/4] powerpc: Add support to initialize ima policy rules Claudio Carvalho
2019-04-02 19:36 ` [PATCH 0/4] Enabling secure boot on PowerNV systems Matthew Garrett
2019-04-02 21:11   ` Claudio Carvalho
2019-04-02 21:51     ` Matthew Garrett
2019-04-02 23:31       ` Claudio Carvalho [this message]
2019-04-03 22:27         ` Matthew Garrett
2019-04-05 21:11           ` Claudio Carvalho
2019-04-05 22:19             ` Matthew Garrett
2019-04-09 22:55               ` Claudio Carvalho
2019-04-10 17:36                 ` Matthew Garrett
2019-05-10 21:31                   ` Claudio Carvalho
2019-05-13 22:06                     ` Matthew Garrett
2019-04-03 13:21 ` Michael Ellerman
2019-04-03 21:48   ` Claudio Carvalho

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2208f156-d441-3082-2f4c-8030c84ef788@linux.ibm.com \
    --to=cclaudio@linux.ibm.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=benh@kernel.crashing.org \
    --cc=jk@ozlabs.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=matthew.garret@nebula.com \
    --cc=mjg59@google.com \
    --cc=mpe@ellerman.id.au \
    --cc=nayna@linux.ibm.com \
    --cc=paulus@samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).