linux-kernel - Re: [PATCH 0/4] Enabling secure boot on PowerNV systems

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 04 Apr 2019 00:21:12 +1100
From:   Michael Ellerman <mpe@...erman.id.au>
To:     Claudio Carvalho <cclaudio@...ux.ibm.com>, linuxppc-dev@...abs.org,
        linux-efi@...r.kernel.org, linux-integrity@...r.kernel.org,
        linux-kernel@...r.kernel.org
Cc:     Paul Mackerras <paulus@...ba.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Ard Biesheuvel <ard.biesheuvel@...aro.org>,
        Jeremy Kerr <jk@...abs.org>,
        Matthew Garret <matthew.garret@...ula.com>,
        Claudio Carvalho <cclaudio@...ux.ibm.com>,
        Nayna Jain <nayna@...ux.ibm.com>
Subject: Re: [PATCH 0/4] Enabling secure boot on PowerNV systems

Hi Claudio,

Thanks for posting this.

Claudio Carvalho <cclaudio@...ux.ibm.com> writes:
> This patch set is part of a series that implements secure boot on
> PowerNV systems.
>
> In order to verify the OS kernel on PowerNV, secure boot requires X.509
> certificates trusted by the platform, the secure boot modes, and several
> other pieces of information. These are stored in secure variables
> controlled by OPAL, also known as OPAL secure variables.
>
> This patch set adds the following features:
>
> 1. Enable efivarfs by selecting CONFIG_EFI in the CONFIG_OPAL_SECVAR
>    introduced in this patch set. With CONFIG_EFIVAR_FS, userspace tools can
>    be used to manage the secure variables.
> 2. Add support for OPAL secure variables by overwriting the EFI hooks
>    (get_variable, get_next_variable, set_variable and query_variable_info)
>    with OPAL call wrappers. There is probably a better way to add this
>    support, for example, we are investigating if we could register the
>    efivar_operations rather than overwriting the EFI hooks. In this patch
>    set, CONFIG_OPAL_SECVAR selects CONFIG_EFI. If, instead, we registered
>    efivar_operations, CONFIG_EFIVAR_FS would need to depend on
>    CONFIG_EFI|| CONFIG_OPAL_SECVAR. Comments or suggestions on the
>    preferred technique would be greatly appreciated.

I am *very* reluctant to start selecting CONFIG_EFI on powerpc.

Simply because we don't actually have EFI, and I worry we're going to
both break assumptions in the EFI code as well as impose requirements on
the powerpc code that aren't really necessary.

So I'd definitely prefer we go the route of enabling efivarfs with an
alternate backend.

Better still would be a generic secure variable interface as Matt
suggests, if the userspace tools can be relatively easily adapted to use
that interface.

cheers