All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: Lenny Szubowicz <lszubowi@redhat.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	linux-efi <linux-efi@vger.kernel.org>,
	platform-driver-x86@vger.kernel.org,
	linux-security-module@vger.kernel.org, andy.shevchenko@gmail.com,
	James Morris <jmorris@namei.org>,
	serge@hallyn.com, Kees Cook <keescook@chromium.org>,
	zohar@linux.ibm.com, Borislav Petkov <bp@alien8.de>,
	Peter Jones <pjones@redhat.com>,
	David Howells <dhowells@redhat.com>,
	prarit@redhat.com
Subject: Re: [PATCH V2 0/3] integrity: Load certs from EFI MOK config table
Date: Fri, 11 Sep 2020 18:17:28 +0300	[thread overview]
Message-ID: <CAMj1kXHOcGiwOT_sNTQRA=G7GCQSKLk2HSNoS2vEQYPzQpn0nw@mail.gmail.com> (raw)
In-Reply-To: <20200905013107.10457-1-lszubowi@redhat.com>

On Sat, 5 Sep 2020 at 04:31, Lenny Szubowicz <lszubowi@redhat.com> wrote:
>
> Because of system-specific EFI firmware limitations, EFI volatile
> variables may not be capable of holding the required contents of
> the Machine Owner Key (MOK) certificate store when the certificate
> list grows above some size. Therefore, an EFI boot loader may pass
> the MOK certs via a EFI configuration table created specifically for
> this purpose to avoid this firmware limitation.
>
> An EFI configuration table is a simpler and more robust mechanism
> compared to EFI variables and is well suited for one-way passage
> of static information from a pre-OS environment to the kernel.
>
> Entries in the MOK variable configuration table are named key/value
> pairs. Therefore the shim boot loader can create a MokListRT named
> entry in the MOK configuration table that contains exactly the same
> data as the MokListRT UEFI variable does or would otherwise contain.
> As such, the kernel can load certs from the data in the MokListRT
> configuration table entry data in the same way that it loads certs
> from the data returned by the EFI GetVariable() runtime call for the
> MokListRT variable.
>
> This patch set does not remove the support for loading certs from the
> EFI MOK variables into the platform key ring. However, if both the EFI
> MOK configuration table and corresponding EFI MOK variables are present,
> the MOK table is used as the source of MOK certs.
>
> The contents of the individual named MOK config table entries are
> made available to user space as individual sysfs binary files,
> which are read-only to root, under:
>
>         /sys/firmware/efi/mok-variables/
>
> This enables an updated mokutil to provide support for:
>
>         mokutil --list-enrolled
>
> such that it can provide accurate information regardless of whether
> the MOK configuration table or MOK EFI variables were the source
> for certs. Note that all modifications of MOK related state are still
> initiated by mokutil via EFI variables.
>
> V2: Incorporate feedback from V1
>   Patch 01: efi: Support for MOK variable config table
>   - Minor update to change log; no code changes
>   Patch 02: integrity: Move import of MokListRT certs to a separate routine
>   - Clean up code flow in code moved to load_moklist_certs()
>   - Remove some unnecessary initialization of variables
>   Patch 03: integrity: Load certs from the EFI MOK config table
>   - Update required due to changes in patch 02.
>   - Remove unnecessary init of mokvar_entry in load_moklist_certs()
>
> V1:
>   https://lore.kernel.org/lkml/20200826034455.28707-1-lszubowi@redhat.com/
>
> Lenny Szubowicz (3):
>   efi: Support for MOK variable config table
>   integrity: Move import of MokListRT certs to a separate routine
>   integrity: Load certs from the EFI MOK config table
>
>  arch/x86/kernel/setup.c                       |   1 +
>  arch/x86/platform/efi/efi.c                   |   3 +
>  drivers/firmware/efi/Makefile                 |   1 +
>  drivers/firmware/efi/arm-init.c               |   1 +
>  drivers/firmware/efi/efi.c                    |   6 +
>  drivers/firmware/efi/mokvar-table.c           | 360 ++++++++++++++++++
>  include/linux/efi.h                           |  34 ++
>  security/integrity/platform_certs/load_uefi.c |  85 ++++-
>  8 files changed, 472 insertions(+), 19 deletions(-)
>  create mode 100644 drivers/firmware/efi/mokvar-table.c
>

Thanks. I have tentatively queued these up in efi/next.

Mimi, please let me know if you have any thoughts on 3/3, and whether
your R-b on 2/3 [v1] implies that you are ok with the series going
through the EFI tree.

-- 
Ard.

  parent reply	other threads:[~2020-09-11 16:28 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-05  1:31 [PATCH V2 0/3] integrity: Load certs from EFI MOK config table Lenny Szubowicz
2020-09-05  1:31 ` [PATCH V2 1/3] efi: Support for MOK variable " Lenny Szubowicz
2020-09-18  8:30   ` [tip: efi/core] " tip-bot2 for Lenny Szubowicz
2020-09-21 15:55     ` Borislav Petkov
2020-09-21 16:18   ` [PATCH V2 1/3] " Arvind Sankar
2020-09-21 16:27     ` Ard Biesheuvel
2020-09-21 16:55       ` Arvind Sankar
2020-09-24 19:09         ` Lenny Szubowicz
2020-10-01 17:44   ` Nathan Chancellor
2020-10-01 20:57     ` Ard Biesheuvel
2020-10-01 21:07       ` Nathan Chancellor
2020-09-05  1:31 ` [PATCH V2 2/3] integrity: Move import of MokListRT certs to a separate routine Lenny Szubowicz
2020-09-11 15:02   ` Ard Biesheuvel
2020-09-11 15:54     ` Lenny Szubowicz
2020-09-11 15:59       ` Mimi Zohar
2020-09-11 17:18         ` Lenny Szubowicz
2020-09-11 18:16           ` Ard Biesheuvel
2020-09-11 19:08             ` Mimi Zohar
2020-09-11 19:46               ` Lenny Szubowicz
2020-09-18  8:30   ` [tip: efi/core] " tip-bot2 for Lenny Szubowicz
2020-09-05  1:31 ` [PATCH V2 3/3] integrity: Load certs from the EFI MOK config table Lenny Szubowicz
2020-09-18  8:30   ` [tip: efi/core] " tip-bot2 for Lenny Szubowicz
2020-09-11 15:17 ` Ard Biesheuvel [this message]
2020-09-11 16:01   ` [PATCH V2 0/3] integrity: Load certs from " Mimi Zohar

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='CAMj1kXHOcGiwOT_sNTQRA=G7GCQSKLk2HSNoS2vEQYPzQpn0nw@mail.gmail.com' \
    --to=ardb@kernel.org \
    --cc=andy.shevchenko@gmail.com \
    --cc=bp@alien8.de \
    --cc=dhowells@redhat.com \
    --cc=jmorris@namei.org \
    --cc=keescook@chromium.org \
    --cc=linux-efi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=lszubowi@redhat.com \
    --cc=pjones@redhat.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=prarit@redhat.com \
    --cc=serge@hallyn.com \
    --cc=zohar@linux.ibm.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.