On 4/2/19 6:51 PM, Matthew Garrett wrote:
> On Tue, Apr 2, 2019 at 2:11 PM Claudio Carvalho
> 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
Couple of patches to fix ktest reported issues with the crypto-agile log
format support.
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.
Signed-off-by: Matthew Garrett
---
drivers/firmware/efi/libstub/tpm.c | 4 ++--
1 file changed, 2 insertions(+), 2
On EFI systems, __calc_tpm2_event_size() needs to be able to map tables
at early boot time in order to extract information from them.
Unfortunately this interacts badly with other architectures that don't
provide the early_memremap() interface but which may still have other
mechanisms for
On Tue, Apr 2, 2019 at 2:11 PM Claudio Carvalho 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?
>
On 4/2/19 4:36 PM, Matthew Garrett wrote:
> On Tue, Apr 2, 2019 at 11:15 AM Claudio Carvalho
> wrote:
>> 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
On Tue, Apr 2, 2019 at 11:15 AM Claudio Carvalho wrote:
> 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.
efivarfs has some pretty significant
From: Nayna Jain
PowerNV secure boot relies on the kernel IMA security subsystem to
perform the OS kernel image signature verification. Since each secure
boot mode has different IMA policy requirements, dynamic definition of
the policy rules based on the runtime secure boot mode of the system is
From: Nayna Jain
PowerNV secure boot defines different IMA policies based on the secure
boot state of the system.
This patch defines a function to detect the secure boot state of the
system.
Signed-off-by: Nayna Jain
---
arch/powerpc/include/asm/secboot.h | 21 +
The X.509 certificates trusted by the platform and other information
required to secure boot the host OS kernel are wrapped in secure
variables, which are controlled by OPAL.
The OPAL secure variables can be handled through the following OPAL
calls.
OPAL_SECVAR_GET:
Returns the data for a given
When CONFIG_EFI is enabled, the EFI driver includes the generic
early_ioremap header, which assumes that architectures may want to
provide their own early ioremap functions.
This patch overrides the ioremap functions in powerpc because they are
not required for secure boot on powerpc systems.
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
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.
On Mon, Apr 01, 2019 at 08:32:26PM -0700, Matthew Garrett wrote:
> On Mon, Apr 1, 2019 at 4:52 PM Jarkko Sakkinen
> wrote:
> >
> > On Wed, Feb 27, 2019 at 12:26:54PM -0800, Matthew Garrett wrote:
> > > Identical to V4, but based on tpmdd-next
> >
> > OK, so on my GLK NUC I get valid final log and
14 matches
Mail list logo
