Re: [PATCH 0/4] Enabling secure boot on PowerNV systems
On Tue, Apr 2, 2019 at 4:31 PM Claudio Carvalho wrote: > > > On 4/2/19 6:51 PM, Matthew Garrett wrote: > > 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. Not supporting dbx seems like a pretty significant shortcoming. How are signatures meant to be revoked? > 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? > > 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. My recollection is that at the time the Chromebook firmware still had EFI underpinnings and the gsmi code was largely just an alternate mechanism for calling into something that was fundamentally the EFI variable store. With hindsight I don't think layering this was the right move - we've adjusted the semantics of efivarfs on more than one occasion to deal with the behaviour of real-world EFI platforms, and I don't think it's helpful to end up in a situation where we're trying to keep behaviour consistent among entirely different firmware interfaces. > 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. 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.
Re: [PATCH 0/4] Enabling secure boot on PowerNV systems
On 4/3/19 10:21 AM, Michael Ellerman wrote: > Hi Claudio, > > Thanks for posting this. > > Claudio Carvalho 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. Yes, we agree. We are working on the v2 and it is not going to depend on CONFIG_EFI. Rather, the IMA arch policies will make the OPAL calls directly. > > So I'd definitely prefer we go the route of enabling efivarfs with an > alternate backend. Right, I'm investigating how we can do that, but it looks like we should post that as a separate patchset to avoid delaying upstreaming signature verification based on the secure boot variables. Thanks, Claudio > > 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 >
[PATCH] efi: Include tpm_eventlog.h after asm/efi.h to avoid memcpy breakage
769a8089c1fd2 (x86, efi, kasan: #undef memset/memcpy/memmove per arch) disables the KASAN version of certain memory calls in the EFI boot stub. tpm_eventlog.h references memcpy, so must be included after asm/efi.h in order to allow 769a8089c1fd2 to take effect on its declarations. Signed-off-by: Matthew Garrett --- drivers/firmware/efi/libstub/tpm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/firmware/efi/libstub/tpm.c b/drivers/firmware/efi/libstub/tpm.c index b6e93e14fcf1..777c1e82495a 100644 --- a/drivers/firmware/efi/libstub/tpm.c +++ b/drivers/firmware/efi/libstub/tpm.c @@ -8,9 +8,11 @@ * Thiebaud Weksteen */ #include -#include #include +/* Must be included after asm/efi.h in order to avoid using the wrong memcpy */ +#include + #include "efistub.h" #ifdef CONFIG_RESET_ATTACK_MITIGATION -- 2.21.0.392.gf8f6787159e-goog
Re: Add support for TCG2 log format on UEFI systems
On Tue, Apr 02, 2019 at 10:15:39AM -0700, Matthew Garrett wrote: > On Tue, Apr 2, 2019 at 6:07 AM Jarkko Sakkinen > wrote: > > Reviewed-by: Jarkko Sakkinen > > Tested-by: Jarkko Sakkinen > > > > I'll apply all patches soonish and include them to the next PR. > > Thanks! Looks like I need some fixes to deal with non-x86 > architectures, I'll get on that today. Great thanks. I'll check them tomorrow (Thu). /Jarkko
Re: [PATCH 1/2] efi: Fix cast to pointer from integer of different size in TPM log code
On Wed, Apr 3, 2019 at 6:41 AM David Laight wrote: > > From: Matthew Garrett > > Sent: 02 April 2019 22:56 > > > > 8bfcff4a6a1d9d7226bb63a7da758b82d9ab4373 introduced a cast from > > efi_physical_address_t to (void *), which are different sizes on 32-bit. > > Fix that. Caught by the 0-day test bot. > > Casting a physical address to 'void *' seems completely wrong. > Also you'd need a guarantee that the address was below 4G or the result > is meaningless. > Looks to me like something is using the wrong types somewhere. We're in UEFI here, not the kernel proper - the firmware functions we call give us back physical addresses, and we're operating with a 1:1 mapping. long is 64 bit on 64 bit systems, and on 32 bit systems we've already asserted that all firmware resources are under 4GB (obviously we're going to have a bad time if they're not, but there's not really anything we can do about that)
RE: [PATCH 1/2] efi: Fix cast to pointer from integer of different size in TPM log code
From: Matthew Garrett
> Sent: 02 April 2019 22:56
>
> 8bfcff4a6a1d9d7226bb63a7da758b82d9ab4373 introduced a cast from
> efi_physical_address_t to (void *), which are different sizes on 32-bit.
> Fix that. Caught by the 0-day test bot.
Casting a physical address to 'void *' seems completely wrong.
Also you'd need a guarantee that the address was below 4G or the result
is meaningless.
Looks to me like something is using the wrong types somewhere.
David
> Signed-off-by: Matthew Garrett
> ---
> drivers/firmware/efi/libstub/tpm.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/firmware/efi/libstub/tpm.c
> b/drivers/firmware/efi/libstub/tpm.c
> index b6e93e14fcf1..6b3b507a54eb 100644
> --- a/drivers/firmware/efi/libstub/tpm.c
> +++ b/drivers/firmware/efi/libstub/tpm.c
> @@ -114,8 +114,8 @@ void efi_retrieve_tpm2_eventlog(efi_system_table_t
> *sys_table_arg)
>*/
> last_entry_size =
> __calc_tpm2_event_size((void *)last_entry_addr,
> -(void *)log_location,
> -false);
> + (void *)(long)log_location,
> + false);
> } else {
> last_entry_size = sizeof(struct tcpa_event) +
> ((struct tcpa_event *) last_entry_addr)->event_size;
> --
> 2.21.0.392.gf8f6787159e-goog
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT,
UK
Registration No: 1397386 (Wales)
Re: [PATCH 0/4] Enabling secure boot on PowerNV systems
Hi Claudio, Thanks for posting this. Claudio Carvalho 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
Вывод в 10-ку поисковых систем
Здравствуйте! Предлагаю услуги по продвижению сайта в поисковой выдаче. Направить доп.информацию?
