Re: [PATCH 0/4] Enabling secure boot on PowerNV systems
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 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
[PATCH] TCG2 log support build fixes for non-x86_64
Couple of patches to fix ktest reported issues with the crypto-agile log format support.
[PATCH 1/2] efi: Fix cast to pointer from integer of different size in TPM log code
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 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
[PATCH 2/2] tpm: Fix builds on platforms that lack early_memremap()
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 obtaining crypto-agile logs. Abstract this away so we
can avoid the need for two implementations while still avoiding breakage
on architectures that don't require remapping of the table.
Signed-off-by: Matthew Garrett
---
drivers/firmware/efi/tpm.c | 3 +++
include/linux/tpm_eventlog.h | 32
2 files changed, 23 insertions(+), 12 deletions(-)
diff --git a/drivers/firmware/efi/tpm.c b/drivers/firmware/efi/tpm.c
index f2a13cbb8688..fe48150f06d1 100644
--- a/drivers/firmware/efi/tpm.c
+++ b/drivers/firmware/efi/tpm.c
@@ -4,6 +4,9 @@
* Thiebaud Weksteen
*/
+#define TPM_MEMREMAP(start, size) early_memremap(start, size)
+#define TPM_MEMUNMAP(start, size) early_memunmap(start, size)
+
#include
#include
#include
diff --git a/include/linux/tpm_eventlog.h b/include/linux/tpm_eventlog.h
index d889e12047d9..0ca27bc053af 100644
--- a/include/linux/tpm_eventlog.h
+++ b/include/linux/tpm_eventlog.h
@@ -128,6 +128,14 @@ struct tcg_algorithm_info {
struct tcg_algorithm_size digest_sizes[];
};
+#ifndef TPM_MEMREMAP
+#define TPM_MEMREMAP(start, size) NULL
+#endif
+
+#ifndef TPM_MEMUNMAP
+#define TPM_MEMUNMAP(start, size) do{} while(0)
+#endif
+
/**
* __calc_tpm2_event_size - calculate the size of a TPM2 event log entry
* @event:Pointer to the event whose size should be calculated
@@ -171,8 +179,8 @@ static inline int __calc_tpm2_event_size(struct
tcg_pcr_event2_head *event,
/* Map the event header */
if (do_mapping) {
mapping_size = marker - marker_start;
- mapping = early_memremap((unsigned long)marker_start,
-mapping_size);
+ mapping = TPM_MEMREMAP((unsigned long)marker_start,
+ mapping_size);
if (!mapping) {
size = 0;
goto out;
@@ -192,10 +200,10 @@ static inline int __calc_tpm2_event_size(struct
tcg_pcr_event2_head *event,
/* Map the digest's algorithm identifier */
if (do_mapping) {
- early_memunmap(mapping, mapping_size);
+ TPM_MEMUNMAP(mapping, mapping_size);
mapping_size = marker - marker_start + halg_size;
- mapping = early_memremap((unsigned long)marker_start,
-mapping_size);
+ mapping = TPM_MEMREMAP((unsigned long)marker_start,
+ mapping_size);
if (!mapping) {
size = 0;
goto out;
@@ -212,10 +220,10 @@ static inline int __calc_tpm2_event_size(struct
tcg_pcr_event2_head *event,
/* Map the digest content itself */
if (do_mapping) {
- early_memunmap(mapping, mapping_size);
+ TPM_MEMUNMAP(mapping, mapping_size);
mapping_size = marker - marker_start;
- mapping = early_memremap((unsigned
long)marker_start,
- mapping_size);
+ mapping = TPM_MEMREMAP((unsigned
long)marker_start,
+ mapping_size);
if (!mapping) {
size = 0;
goto out;
@@ -238,10 +246,10 @@ static inline int __calc_tpm2_event_size(struct
tcg_pcr_event2_head *event,
* we don't need to map it
*/
if (do_mapping) {
- early_memunmap(marker_start, mapping_size);
+ TPM_MEMUNMAP(marker_start, mapping_size);
mapping_size += sizeof(event_field->event_size);
- mapping = early_memremap((unsigned long)marker_start,
-mapping_size);
+ mapping = TPM_MEMREMAP((unsigned long)marker_start,
+ mapping_size);
if (!mapping) {
size = 0;
goto out;
@@ -256,7 +264,7 @@ static inline int __calc_tpm2_event_size(struct
tcg_pcr_event2_head *event,
size = 0;
out:
if (do_mapping)
- early_memunmap(mapping, mapping_size);
+ TPM_MEMUNMAP(mapping, mapping_size);
return size;
}
--
2.21.0.392.gf8f6787159e-goog
Re: [PATCH 0/4] Enabling secure boot on PowerNV systems
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? > 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.
Re: [PATCH 0/4] Enabling secure boot on PowerNV systems
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 variables. > efivarfs has some pretty significant behavioural semantics that > directly reflect the EFI specification. Using it to expose non-EFI > variable data feels like it's going to increase fragility - there's a > risk that we'll change things in a way that makes sense for the EFI > spec but breaks your use case. Is the desire to use efivarfs to > maintain consistency with existing userland tooling, or just to avoid > having a separate filesystem? > We want to use the efivarfs for compatibility with existing userspace tools. We will track and match any EFI changes that affect us. Our use case is restricted to secure boot - this is not going to be a general purpose EFI variable implementation. Claudio
Re: [PATCH 0/4] Enabling secure boot on PowerNV systems
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 behavioural semantics that directly reflect the EFI specification. Using it to expose non-EFI variable data feels like it's going to increase fragility - there's a risk that we'll change things in a way that makes sense for the EFI spec but breaks your use case. Is the desire to use efivarfs to maintain consistency with existing userland tooling, or just to avoid having a separate filesystem?
[PATCH 4/4] powerpc: Add support to initialize ima policy rules
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
required. On systems that support secure boot, but have it disabled,
only measurement policy rules of the kernel image and modules are
defined.
This patch defines the arch-specific implementation to retrieve the
secure boot mode of the system and accordingly configures the IMA policy
rules.
This patch will provide arch-specific IMA policies if PPC_SECURE_BOOT
config is enabled.
Signed-off-by: Nayna Jain
---
arch/powerpc/Kconfig | 12
arch/powerpc/kernel/Makefile | 1 +
arch/powerpc/kernel/ima_arch.c | 54 ++
include/linux/ima.h| 3 +-
4 files changed, 69 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/kernel/ima_arch.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 2d0be82c3061..e0ba9a9114b3 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -901,6 +901,18 @@ config PPC_MEM_KEYS
If unsure, say y.
+config PPC_SECURE_BOOT
+ prompt "Enable PowerPC Secure Boot"
+ bool
+ default n
+ depends on IMA
+ depends on IMA_ARCH_POLICY
+ help
+ Linux on POWER with firmware secure boot enabled needs to define
+ security policies to extend secure boot to the OS.
+ This config allows user to enable OS Secure Boot on PowerPC systems
+ that have firmware secure boot support.
+
endmenu
config ISA_DMA_API
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index cddadccf551d..0f08ed7dfd1b 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -119,6 +119,7 @@ ifdef CONFIG_IMA
obj-y += ima_kexec.o
endif
endif
+obj-$(CONFIG_IMA) += ima_arch.o
obj-$(CONFIG_AUDIT)+= audit.o
obj64-$(CONFIG_AUDIT) += compat_audit.o
diff --git a/arch/powerpc/kernel/ima_arch.c b/arch/powerpc/kernel/ima_arch.c
new file mode 100644
index ..871b321656fb
--- /dev/null
+++ b/arch/powerpc/kernel/ima_arch.c
@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 IBM Corporation
+ * Author: Nayna Jain
+ *
+ * ima_arch.c
+ * - initialize ima policies for PowerPC Secure Boot
+ */
+
+#include
+#include
+
+bool arch_ima_get_secureboot(void)
+{
+ bool sb_mode;
+
+ sb_mode = get_powerpc_sb_mode();
+ if (sb_mode)
+ return true;
+ else
+ return false;
+}
+
+/*
+ * File signature verification is not needed, include only measurements
+ */
+static const char *const default_arch_rules[] = {
+ "measure func=KEXEC_KERNEL_CHECK",
+ "measure func=MODULE_CHECK",
+ NULL
+};
+
+/* Both file signature verification and measurements are needed */
+static const char *const sb_arch_rules[] = {
+ "measure func=KEXEC_KERNEL_CHECK",
+ "measure func=MODULE_CHECK",
+ "appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig",
+#if !IS_ENABLED(CONFIG_MODULE_SIG)
+ "appraise func=MODULE_CHECK appraise_type=imasig",
+#endif
+ NULL
+};
+
+/*
+ * On PowerPC, file measurements are to be added to the IMA measurement list
+ * irrespective of the secure boot state of the system. Signature verification
+ * is conditionally enabled based on the secure boot state.
+ */
+const char *const *arch_get_ima_policy(void)
+{
+ if (IS_ENABLED(CONFIG_IMA_ARCH_POLICY) && arch_ima_get_secureboot())
+ return sb_arch_rules;
+ return default_arch_rules;
+}
diff --git a/include/linux/ima.h b/include/linux/ima.h
index dc12fbcf484c..32f46d69ebd7 100644
--- a/include/linux/ima.h
+++ b/include/linux/ima.h
@@ -31,7 +31,8 @@ extern void ima_post_path_mknod(struct dentry *dentry);
extern void ima_add_kexec_buffer(struct kimage *image);
#endif
-#if defined(CONFIG_X86) && defined(CONFIG_EFI)
+#if defined(CONFIG_X86) && defined(CONFIG_EFI) \
+ || defined(CONFIG_PPC_SECURE_BOOT)
extern bool arch_ima_get_secureboot(void);
extern const char * const *arch_get_ima_policy(void);
#else
--
2.20.1
[PATCH 3/4] powerpc/powernv: Detect the secure boot mode of the system
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 +
arch/powerpc/platforms/powernv/Makefile | 2 +-
arch/powerpc/platforms/powernv/secboot.c | 54
3 files changed, 76 insertions(+), 1 deletion(-)
create mode 100644 arch/powerpc/include/asm/secboot.h
create mode 100644 arch/powerpc/platforms/powernv/secboot.c
diff --git a/arch/powerpc/include/asm/secboot.h
b/arch/powerpc/include/asm/secboot.h
new file mode 100644
index ..1904fb4a3352
--- /dev/null
+++ b/arch/powerpc/include/asm/secboot.h
@@ -0,0 +1,21 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * PowerPC secure boot definitions
+ *
+ * Copyright (C) 2019 IBM Corporation
+ * Author: Nayna Jain
+ *
+ */
+#ifndef POWERPC_SECBOOT_H
+#define POWERPC_SECBOOT_H
+
+#if defined(CONFIG_OPAL_SECVAR)
+extern bool get_powerpc_sb_mode(void);
+#else
+static inline bool get_powerpc_sb_mode(void)
+{
+ return false;
+}
+#endif
+
+#endif
diff --git a/arch/powerpc/platforms/powernv/Makefile
b/arch/powerpc/platforms/powernv/Makefile
index 1511d836fd19..a36e22f8ecf8 100644
--- a/arch/powerpc/platforms/powernv/Makefile
+++ b/arch/powerpc/platforms/powernv/Makefile
@@ -16,4 +16,4 @@ obj-$(CONFIG_PERF_EVENTS) += opal-imc.o
obj-$(CONFIG_PPC_MEMTRACE) += memtrace.o
obj-$(CONFIG_PPC_VAS) += vas.o vas-window.o vas-debug.o
obj-$(CONFIG_OCXL_BASE)+= ocxl.o
-obj-$(CONFIG_OPAL_SECVAR) += opal-secvar.o
+obj-$(CONFIG_OPAL_SECVAR) += opal-secvar.o secboot.o
diff --git a/arch/powerpc/platforms/powernv/secboot.c
b/arch/powerpc/platforms/powernv/secboot.c
new file mode 100644
index ..afb1552636c5
--- /dev/null
+++ b/arch/powerpc/platforms/powernv/secboot.c
@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 IBM Corporation
+ * Author: Nayna Jain
+ *
+ * secboot.c
+ * - util functions to get powerpc secboot state
+ *
+ */
+#include
+#include
+
+bool get_powerpc_sb_mode(void)
+{
+ efi_char16_t efi_SecureBoot_name[] = L"SecureBoot";
+ efi_char16_t efi_SetupMode_name[] = L"SetupMode";
+ efi_guid_t efi_variable_guid = EFI_GLOBAL_VARIABLE_GUID;
+ efi_status_t status;
+ u8 secboot, setupmode;
+ unsigned long size = sizeof(secboot);
+
+ status = efi.get_variable(efi_SecureBoot_name, _variable_guid,
+ NULL, , );
+
+ /*
+* For now assume all failures reading the SecureBoot variable implies
+* secure boot is not enabled. Later differentiate failure types.
+*/
+ if (status != EFI_SUCCESS) {
+ secboot = 0;
+ setupmode = 0;
+ goto out;
+ }
+
+ size = sizeof(setupmode);
+ status = efi.get_variable(efi_SetupMode_name, _variable_guid,
+ NULL, , );
+
+ /*
+* Failure to read the SetupMode variable does not prevent
+* secure boot mode
+*/
+ if (status != EFI_SUCCESS)
+ setupmode = 0;
+
+out:
+ if ((secboot == 0) || (setupmode == 1)) {
+ pr_info("ima: secureboot mode disabled\n");
+ return false;
+ }
+
+ pr_info("ima: secureboot mode enabled\n");
+ return true;
+}
--
2.20.1
[PATCH 2/4] powerpc/powernv: Add support for OPAL secure variables
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 secure variable name and vendor GUID. OPAL_SECVAR_GET_NEXT: For a given secure variable, it returns the name and vendor GUID of the next variable. OPAL_SECVAR_ENQUEUE: Enqueue the supplied secure variable update so that it can be processed by OPAL in the next boot. Variable updates cannot be be processed right away because the variable storage is write locked at runtime. OPAL_SECVAR_INFO: Returns size information about the variable. This patch adds support for OPAL secure variables by setting up the EFI runtime variable services to make OPAL calls. This patch also introduces CONFIG_OPAL_SECVAR for enabling the OPAL secure variables support in the kernel. Since CONFIG_OPAL_SECVAR selects CONFIG_EFI, it also allow us to manage the OPAL secure variables from userspace via efivarfs. Signed-off-by: Claudio Carvalho --- This patch depends on new OPAL calls that are being added to skiboot. The patch set that implements the new calls has been posted to https://patchwork.ozlabs.org/project/skiboot/list/?series=99805 --- arch/powerpc/include/asm/opal-api.h | 6 +- arch/powerpc/include/asm/opal.h | 10 ++ arch/powerpc/platforms/Kconfig | 3 + arch/powerpc/platforms/powernv/Kconfig | 9 + arch/powerpc/platforms/powernv/Makefile | 1 + arch/powerpc/platforms/powernv/opal-call.c | 4 + arch/powerpc/platforms/powernv/opal-secvar.c | 179 +++ 7 files changed, 211 insertions(+), 1 deletion(-) create mode 100644 arch/powerpc/platforms/powernv/opal-secvar.c diff --git a/arch/powerpc/include/asm/opal-api.h b/arch/powerpc/include/asm/opal-api.h index 870fb7b239ea..d3066f29cb7a 100644 --- a/arch/powerpc/include/asm/opal-api.h +++ b/arch/powerpc/include/asm/opal-api.h @@ -210,7 +210,11 @@ #define OPAL_PCI_GET_PBCQ_TUNNEL_BAR 164 #define OPAL_PCI_SET_PBCQ_TUNNEL_BAR 165 #defineOPAL_NX_COPROC_INIT 167 -#define OPAL_LAST 167 +#define OPAL_SECVAR_GET170 +#define OPAL_SECVAR_GET_NEXT 171 +#define OPAL_SECVAR_ENQUEUE172 +#define OPAL_SECVAR_INFO 173 +#define OPAL_LAST 173 #define QUIESCE_HOLD 1 /* Spin all calls at entry */ #define QUIESCE_REJECT 2 /* Fail all calls with OPAL_BUSY */ diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h index a55b01c90bb1..fdfd8dd7b326 100644 --- a/arch/powerpc/include/asm/opal.h +++ b/arch/powerpc/include/asm/opal.h @@ -385,6 +385,16 @@ void opal_powercap_init(void); void opal_psr_init(void); void opal_sensor_groups_init(void); +extern int opal_secvar_get(uint64_t name, uint64_t vendor, uint64_t attr, + uint64_t data_size, uint64_t data); +extern int opal_secvar_get_next(uint64_t name_size, uint64_t name, + uint64_t vendor); +extern int opal_secvar_enqueue(uint64_t name, uint64_t vendor, uint64_t attr, + uint64_t data_size, uint64_t data); +extern int opal_secvar_info(uint64_t attr, uint64_t storage_space, + uint64_t remaining_space, + uint64_t max_variable_size); + #endif /* __ASSEMBLY__ */ #endif /* _ASM_POWERPC_OPAL_H */ diff --git a/arch/powerpc/platforms/Kconfig b/arch/powerpc/platforms/Kconfig index f3fb79fccc72..8e30510bc0c1 100644 --- a/arch/powerpc/platforms/Kconfig +++ b/arch/powerpc/platforms/Kconfig @@ -326,4 +326,7 @@ config XILINX_PCI bool "Xilinx PCI host bridge support" depends on PCI && XILINX_VIRTEX +config EFI + bool + endmenu diff --git a/arch/powerpc/platforms/powernv/Kconfig b/arch/powerpc/platforms/powernv/Kconfig index 850eee860cf2..879f8e766098 100644 --- a/arch/powerpc/platforms/powernv/Kconfig +++ b/arch/powerpc/platforms/powernv/Kconfig @@ -47,3 +47,12 @@ config PPC_VAS VAS adapters are found in POWER9 based systems. If unsure, say N. + +config OPAL_SECVAR + bool "OPAL Secure Variables" + depends on PPC_POWERNV && !CPU_BIG_ENDIAN + select UCS2_STRING + select EFI + help + This enables the kernel to access OPAL secure variables via EFI + runtime variable services. diff --git a/arch/powerpc/platforms/powernv/Makefile b/arch/powerpc/platforms/powernv/Makefile index da2e99efbd04..1511d836fd19 100644 --- a/arch/powerpc/platforms/powernv/Makefile +++ b/arch/powerpc/platforms/powernv/Makefile @@ -16,3 +16,4 @@ obj-$(CONFIG_PERF_EVENTS) += opal-imc.o obj-$(CONFIG_PPC_MEMTRACE) += memtrace.o
[PATCH 1/4] powerpc/include: Override unneeded early ioremap functions
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.
Signed-off-by: Claudio Carvalho
---
arch/powerpc/include/asm/early_ioremap.h | 41
1 file changed, 41 insertions(+)
create mode 100644 arch/powerpc/include/asm/early_ioremap.h
diff --git a/arch/powerpc/include/asm/early_ioremap.h
b/arch/powerpc/include/asm/early_ioremap.h
new file mode 100644
index ..a86a06e9f3b9
--- /dev/null
+++ b/arch/powerpc/include/asm/early_ioremap.h
@@ -0,0 +1,41 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Early ioremap definitions
+ *
+ * Copyright (C) 2019 IBM Corporation
+ * Author: Claudio Carvalho
+ *
+ */
+#ifndef _ASM_POWERPC_EARLY_IOREMAP_H
+#define _ASM_POWERPC_EARLY_IOREMAP_H
+
+static inline void __iomem *early_ioremap(resource_size_t phys_addr,
+ unsigned long size)
+{
+ return NULL;
+}
+
+static inline void *early_memremap(resource_size_t phys_addr,
+ unsigned long size)
+{
+ return NULL;
+}
+
+static inline void *early_memremap_ro(resource_size_t phys_addr,
+ unsigned long size)
+{
+ return NULL;
+}
+
+static inline void *early_memremap_prot(resource_size_t phys_addr,
+ unsigned long size,
+ unsigned long prot_val)
+{
+ return NULL;
+}
+
+static inline void early_iounmap(void __iomem *addr, unsigned long size) { }
+static inline void early_memunmap(void *addr, unsigned long size) { }
+static inline void early_ioremap_shutdown(void) { }
+
+#endif
--
2.20.1
[PATCH 0/4] Enabling secure boot on PowerNV 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 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. 3. Define IMA arch-specific policies based on the secure boot state and mode of the system. On secure boot enabled powernv systems, the host OS kernel signature will be verified by IMA appraisal. Claudio Carvalho (2): powerpc/include: Override unneeded early ioremap functions powerpc/powernv: Add support for OPAL secure variables Nayna Jain (2): powerpc/powernv: Detect the secure boot mode of the system powerpc: Add support to initialize ima policy rules arch/powerpc/Kconfig | 12 ++ arch/powerpc/include/asm/early_ioremap.h | 41 + arch/powerpc/include/asm/opal-api.h | 6 +- arch/powerpc/include/asm/opal.h | 10 ++ arch/powerpc/include/asm/secboot.h | 21 +++ arch/powerpc/kernel/Makefile | 1 + arch/powerpc/kernel/ima_arch.c | 54 ++ arch/powerpc/platforms/Kconfig | 3 + arch/powerpc/platforms/powernv/Kconfig | 9 + arch/powerpc/platforms/powernv/Makefile | 1 + arch/powerpc/platforms/powernv/opal-call.c | 4 + arch/powerpc/platforms/powernv/opal-secvar.c | 179 +++ arch/powerpc/platforms/powernv/secboot.c | 54 ++ include/linux/ima.h | 3 +- 14 files changed, 396 insertions(+), 2 deletions(-) create mode 100644 arch/powerpc/include/asm/early_ioremap.h create mode 100644 arch/powerpc/include/asm/secboot.h create mode 100644 arch/powerpc/kernel/ima_arch.c create mode 100644 arch/powerpc/platforms/powernv/opal-secvar.c create mode 100644 arch/powerpc/platforms/powernv/secboot.c -- 2.20.1
Re: Add support for TCG2 log format on UEFI systems
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.
Re: Add support for TCG2 log format on UEFI systems
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 invalid event log
> > after adding some extra klogs.
> >
> > I.e.
> >
> > - if (efi.tpm_log == EFI_INVALID_TABLE_ADDR)
> > + if (efi.tpm_log == EFI_INVALID_TABLE_ADDR) {
>
> Just to make sure - are you booting via the EFI boot stub? We need to
> obtain the boot log before ExitBootServices() is called, so if you're
> booting directly into the 32-bit entry point (eg, by using the "linux"
> command in grub) then you won't get a log.
... and I was wondering why it used to work when I tested the first
flush of patches. Ugh, sorry. The only excuse is too much multitasking
lately.
Anyway:
Reviewed-by: Jarkko Sakkinen
Tested-by: Jarkko Sakkinen
I'll apply all patches soonish and include them to the next PR.
/Jarkko
