* [PATCH v3 0/3] powerpc: Enabling IMA arch specific secure boot policies @ 2019-06-10 20:33 Nayna Jain 2019-06-10 20:33 ` [PATCH v3 1/3] powerpc/powernv: Add OPAL API interface to get secureboot state Nayna Jain ` (2 more replies) 0 siblings, 3 replies; 11+ messages in thread From: Nayna Jain @ 2019-06-10 20:33 UTC (permalink / raw) To: linuxppc-dev, linux-efi, linux-integrity, linux-kernel Cc: Ard Biesheuvel, Nayna Jain, Claudio Carvalho, Mimi Zohar, Matthew Garret, Paul Mackerras, Jeremy Kerr This patch set, previously named "powerpc: Enabling secure boot on powernv systems - Part 1", 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. The IMA architecture specific policy support on POWER is dependent on OPAL runtime services to access secure variables. OPAL APIs in skiboot are modified to define generic interface compatible to any backend. This patchset is consequently updated to be compatible with new OPAL API interface. This has cleaned up any EFIsms in the arch specific code. Further, the ima arch specific policies are updated to be able to support appended signatures. They also now use per policy template. Exposing the OPAL secure variables to userspace will be posted as a separate patch set, allowing the IMA architecture specific policy on POWER to be upstreamed independently. This patch set adds the following features: 1. Add support for OPAL Runtime API to access secure variables controlled by OPAL. 2. Define IMA arch-specific policies based on the secure boot state and mode of the system. On secure boot enabled PowerNV systems, the OS kernel signature will be verified by IMA appraisal. Pre-requisites for this patchset are: 1. OPAL APIs in Skiboot[1] 2. Appended signature support in IMA [2] 3. Per policy template support in IMA [3] [1] https://patchwork.ozlabs.org/project/skiboot/list/?series=112868 [2] https://patchwork.ozlabs.org/cover/1087361/. Updated version will be posted soon [3] Repo: https://kernel.googlesource.com/pub/scm/linux/kernel/git/zohar/linux-integrity Branch: next-queued-testing. Commit: f241bb1f42aa95 ---------------------------------------------------------------------------------- Original Cover Letter: 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. The IMA architecture specific policy support on Power is dependent on OPAL runtime services to access secure variables. Instead of directly accessing the OPAL runtime services, version 3 of this patch set relied upon the EFI hooks. This version drops that dependency and calls the OPAL runtime services directly. Skiboot OPAL APIs are due to be posted soon. Exposing the OPAL secure variables to userspace will be posted as a separate patch set, allowing the IMA architecture specific policy on Power to be upstreamed independently. This patch set adds the following features: 1. Add support for OPAL Runtime API to access secure variables controlled by OPAL. 2. Define IMA arch-specific policies based on the secure boot state and mode of the system. On secure boot enabled powernv systems, the OS kernel signature will be verified by IMA appraisal. [1] https://patchwork.kernel.org/cover/10882149/ Changelog: v3: * OPAL APIs in Patch 1 are updated to provide generic interface based on key/keylen. This patchset updates kernel OPAL APIs to be compatible with generic interface. * Patch 2 is cleaned up to use new OPAL APIs. * Since OPAL can support different types of backend which can vary in the variable interpretation, the Patch 2 is updated to add a check for the backend version * OPAL API now expects consumer to first check the supported backend version before calling other secvar OPAL APIs. This check is now added in patch 2. * IMA policies in Patch 3 is updated to specify appended signature and per policy template. * The patches now are free of any EFIisms. v2: * Removed Patch 1: powerpc/include: Override unneeded early ioremap functions * Updated Subject line and patch description of the Patch 1 of this series * Removed dependency of OPAL_SECVAR on EFI, CPU_BIG_ENDIAN and UCS2_STRING * Changed OPAL APIs from static to non-static. Added opal-secvar.h for the same * Removed EFI hooks from opal_secvar.c * Removed opal_secvar_get_next(), opal_secvar_enqueue() and opal_query_variable_info() function * get_powerpc_sb_mode() in secboot.c now directly calls OPAL Runtime API rather than via EFI hooks. * Fixed log messages in get_powerpc_sb_mode() function. * Added dependency for PPC_SECURE_BOOT on configs PPC64 and OPAL_SECVAR * Replaced obj-$(CONFIG_IMA) with obj-$(CONFIG_PPC_SECURE_BOOT) in arch/powerpc/kernel/Makefile Claudio Carvalho (1): powerpc/powernv: Add OPAL API interface to get secureboot state Nayna Jain (2): powerpc/powernv: detect the secure boot mode of the system powerpc: Add support to initialize ima policy rules arch/powerpc/Kconfig | 14 ++++ arch/powerpc/include/asm/opal-api.h | 4 +- arch/powerpc/include/asm/opal-secvar.h | 23 ++++++ arch/powerpc/include/asm/opal.h | 6 ++ arch/powerpc/include/asm/secboot.h | 21 +++++ arch/powerpc/kernel/Makefile | 1 + arch/powerpc/kernel/ima_arch.c | 54 +++++++++++++ arch/powerpc/platforms/powernv/Kconfig | 6 ++ arch/powerpc/platforms/powernv/Makefile | 2 + arch/powerpc/platforms/powernv/opal-call.c | 2 + arch/powerpc/platforms/powernv/opal-secvar.c | 85 ++++++++++++++++++++ arch/powerpc/platforms/powernv/secboot.c | 61 ++++++++++++++ include/linux/ima.h | 3 +- 13 files changed, 280 insertions(+), 2 deletions(-) create mode 100644 arch/powerpc/include/asm/opal-secvar.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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v3 1/3] powerpc/powernv: Add OPAL API interface to get secureboot state 2019-06-10 20:33 [PATCH v3 0/3] powerpc: Enabling IMA arch specific secure boot policies Nayna Jain @ 2019-06-10 20:33 ` Nayna Jain 2019-06-12 6:17 ` Daniel Axtens 2019-06-10 20:33 ` [PATCH v3 2/3] powerpc/powernv: detect the secure boot mode of the system Nayna Jain 2019-06-10 20:33 ` [PATCH v3 3/3] powerpc: Add support to initialize ima policy rules Nayna Jain 2 siblings, 1 reply; 11+ messages in thread From: Nayna Jain @ 2019-06-10 20:33 UTC (permalink / raw) To: linuxppc-dev, linux-efi, linux-integrity, linux-kernel Cc: Ard Biesheuvel, Nayna Jain, Claudio Carvalho, Mimi Zohar, Matthew Garret, Paul Mackerras, Jeremy Kerr From: Claudio Carvalho <cclaudio@linux.ibm.com> The X.509 certificates trusted by the platform and other information required to secure boot the OS kernel are wrapped in secure variables, which are controlled by OPAL. This patch adds support to read OPAL secure variables through OPAL_SECVAR_GET call. It returns the metadata and data for a given secure variable based on the unique key. Since OPAL can support different types of backend which can vary in the variable interpretation, a new OPAL API call named OPAL_SECVAR_BACKEND, is added to retrieve the supported backend version. This helps the consumer to know how to interpret the variable. This support can be enabled using CONFIG_OPAL_SECVAR Signed-off-by: Claudio Carvalho <cclaudio@linux.ibm.com> Signed-off-by: Nayna Jain <nayna@linux.ibm.com> --- This patch depends on a new OPAL call that is being added to skiboot. The patch set that implements the new call has been posted to https://patchwork.ozlabs.org/project/skiboot/list/?series=112868 arch/powerpc/include/asm/opal-api.h | 4 +- arch/powerpc/include/asm/opal-secvar.h | 23 ++++++ arch/powerpc/include/asm/opal.h | 6 ++ arch/powerpc/platforms/powernv/Kconfig | 6 ++ arch/powerpc/platforms/powernv/Makefile | 1 + arch/powerpc/platforms/powernv/opal-call.c | 2 + arch/powerpc/platforms/powernv/opal-secvar.c | 85 ++++++++++++++++++++ 7 files changed, 126 insertions(+), 1 deletion(-) create mode 100644 arch/powerpc/include/asm/opal-secvar.h 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 e1577cfa7186..a505e669b4b6 100644 --- a/arch/powerpc/include/asm/opal-api.h +++ b/arch/powerpc/include/asm/opal-api.h @@ -212,7 +212,9 @@ #define OPAL_HANDLE_HMI2 166 #define OPAL_NX_COPROC_INIT 167 #define OPAL_XIVE_GET_VP_STATE 170 -#define OPAL_LAST 170 +#define OPAL_SECVAR_GET 173 +#define OPAL_SECVAR_BACKEND 177 +#define OPAL_LAST 177 #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-secvar.h b/arch/powerpc/include/asm/opal-secvar.h new file mode 100644 index 000000000000..b677171a0368 --- /dev/null +++ b/arch/powerpc/include/asm/opal-secvar.h @@ -0,0 +1,23 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * PowerNV definitions for secure variables OPAL API. + * + * Copyright (C) 2019 IBM Corporation + * Author: Claudio Carvalho <cclaudio@linux.ibm.com> + * + */ +#ifndef OPAL_SECVAR_H +#define OPAL_SECVAR_H + +enum { + BACKEND_NONE = 0, + BACKEND_TC_COMPAT_V1, +}; + +extern int opal_get_variable(u8 *key, unsigned long ksize, + u8 *metadata, unsigned long *mdsize, + u8 *data, unsigned long *dsize); + +extern int opal_variable_version(unsigned long *backend); + +#endif diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h index 4cc37e708bc7..57d2c2356eda 100644 --- a/arch/powerpc/include/asm/opal.h +++ b/arch/powerpc/include/asm/opal.h @@ -394,6 +394,12 @@ void opal_powercap_init(void); void opal_psr_init(void); void opal_sensor_groups_init(void); +extern int opal_secvar_get(uint64_t k_key, uint64_t k_key_len, + uint64_t k_metadata, uint64_t k_metadata_size, + uint64_t k_data, uint64_t k_data_size); + +extern int opal_secvar_backend(uint64_t k_backend); + #endif /* __ASSEMBLY__ */ #endif /* _ASM_POWERPC_OPAL_H */ diff --git a/arch/powerpc/platforms/powernv/Kconfig b/arch/powerpc/platforms/powernv/Kconfig index 850eee860cf2..65b060539b5c 100644 --- a/arch/powerpc/platforms/powernv/Kconfig +++ b/arch/powerpc/platforms/powernv/Kconfig @@ -47,3 +47,9 @@ 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 + help + This enables the kernel to access OPAL secure variables. diff --git a/arch/powerpc/platforms/powernv/Makefile b/arch/powerpc/platforms/powernv/Makefile index da2e99efbd04..6651c742e530 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 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 diff --git a/arch/powerpc/platforms/powernv/opal-call.c b/arch/powerpc/platforms/powernv/opal-call.c index 36c8fa3647a2..0445980f294f 100644 --- a/arch/powerpc/platforms/powernv/opal-call.c +++ b/arch/powerpc/platforms/powernv/opal-call.c @@ -288,3 +288,5 @@ OPAL_CALL(opal_pci_set_pbcq_tunnel_bar, OPAL_PCI_SET_PBCQ_TUNNEL_BAR); OPAL_CALL(opal_sensor_read_u64, OPAL_SENSOR_READ_U64); OPAL_CALL(opal_sensor_group_enable, OPAL_SENSOR_GROUP_ENABLE); OPAL_CALL(opal_nx_coproc_init, OPAL_NX_COPROC_INIT); +OPAL_CALL(opal_secvar_get, OPAL_SECVAR_GET); +OPAL_CALL(opal_secvar_backend, OPAL_SECVAR_BACKEND); diff --git a/arch/powerpc/platforms/powernv/opal-secvar.c b/arch/powerpc/platforms/powernv/opal-secvar.c new file mode 100644 index 000000000000..dba441dd5af1 --- /dev/null +++ b/arch/powerpc/platforms/powernv/opal-secvar.c @@ -0,0 +1,85 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * PowerNV code for secure variables + * + * Copyright (C) 2019 IBM Corporation + * Author: Claudio Carvalho <cclaudio@linux.ibm.com> + * + */ + +/* + * The opal wrappers in this file treat the @name, @vendor, and @data + * parameters as little endian blobs. + * @name is a ucs2 string + * @vendor is the vendor GUID. It is converted to LE in the kernel + * @data variable data, which layout may be different for each variable + */ + +#define pr_fmt(fmt) "secvar: "fmt + +#include <linux/types.h> +#include <asm/opal.h> +#include <asm/opal-secvar.h> + +static bool is_opal_secvar_supported(void) +{ + static bool opal_secvar_supported; + static bool initialized; + + if (initialized) + return opal_secvar_supported; + + if (!opal_check_token(OPAL_SECVAR_GET) + || !opal_check_token(OPAL_SECVAR_BACKEND)) { + pr_err("OPAL doesn't support secure variables\n"); + opal_secvar_supported = false; + } else { + opal_secvar_supported = true; + } + + initialized = true; + + return opal_secvar_supported; +} + +int opal_get_variable(u8 *key, unsigned long ksize, u8 *metadata, + unsigned long *mdsize, u8 *data, unsigned long *dsize) +{ + int rc; + + if (!is_opal_secvar_supported()) + return OPAL_UNSUPPORTED; + + if (mdsize) + *mdsize = cpu_to_be64(*mdsize); + if (dsize) + *dsize = cpu_to_be64(*dsize); + + rc = opal_secvar_get(__pa(key), ksize, __pa(metadata), __pa(mdsize), + __pa(data), __pa(dsize)); + + if (mdsize) + *mdsize = be64_to_cpu(*mdsize); + if (dsize) + *dsize = be64_to_cpu(*dsize); + + return rc; +} + +int opal_variable_version(unsigned long *backend) +{ + int rc; + + if (!is_opal_secvar_supported()) + return OPAL_UNSUPPORTED; + + if (backend) + *backend = cpu_to_be64(*backend); + + rc = opal_secvar_backend(__pa(backend)); + + if (backend) + *backend = be64_to_cpu(*backend); + + return rc; +} -- 2.20.1 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH v3 1/3] powerpc/powernv: Add OPAL API interface to get secureboot state 2019-06-10 20:33 ` [PATCH v3 1/3] powerpc/powernv: Add OPAL API interface to get secureboot state Nayna Jain @ 2019-06-12 6:17 ` Daniel Axtens 2019-06-12 21:08 ` Nayna 0 siblings, 1 reply; 11+ messages in thread From: Daniel Axtens @ 2019-06-12 6:17 UTC (permalink / raw) To: Nayna Jain, linuxppc-dev, linux-efi, linux-integrity, linux-kernel Cc: Ard Biesheuvel, Nayna Jain, Claudio Carvalho, Mimi Zohar, Matthew Garret, Paul Mackerras, Jeremy Kerr Nayna Jain <nayna@linux.ibm.com> writes: > From: Claudio Carvalho <cclaudio@linux.ibm.com> > > The X.509 certificates trusted by the platform and other information > required to secure boot the OS kernel are wrapped in secure variables, > which are controlled by OPAL. > > This patch adds support to read OPAL secure variables through > OPAL_SECVAR_GET call. It returns the metadata and data for a given secure > variable based on the unique key. > > Since OPAL can support different types of backend which can vary in the > variable interpretation, a new OPAL API call named OPAL_SECVAR_BACKEND, is > added to retrieve the supported backend version. This helps the consumer > to know how to interpret the variable. > (Firstly, apologies that I haven't got around to asking about this yet!) Are pluggable/versioned backend a good idea? There are a few things that worry me about the idea: - It adds complexity in crypto (or crypto-adjacent) code, and that increases the likelihood that we'll accidentally add a bug with bad consequences. - Under what circumstances would would we change the kernel-visible behaviour of skiboot? Are we expecting to change the behaviour, content or names of the variables in future? Otherwise the only relevant change I can think of is a change to hardware platforms, and I'm not sure how a change in hardware would lead to change in behaviour in the kernel. Wouldn't Skiboot hide h/w differences? - If we are worried about a long-term-future change to how secure-boot works, would it be better to just add more get/set calls to opal at the point at which we actually implement the new system? - UEFI added EFI_VARIABLE_AUTHENTICATION_3 in a way that - as far as I know - didn't break backwards compatibility. Is there a reason we cannot add features that way instead? (It also dropped v1 of the authentication header.) - What is the correct fallback behaviour if a kernel receives a result that it does not expect? If a kernel expecting BackendV1 is instead informed that it is running on BackendV2, then the cannot access the secure variable at all, so it cannot load keys that are potentially required to successfully boot (e.g. to validate the module for network card or graphics!) Kind regards, Daniel > This support can be enabled using CONFIG_OPAL_SECVAR > > Signed-off-by: Claudio Carvalho <cclaudio@linux.ibm.com> > Signed-off-by: Nayna Jain <nayna@linux.ibm.com> > --- > This patch depends on a new OPAL call that is being added to skiboot. > The patch set that implements the new call has been posted to > https://patchwork.ozlabs.org/project/skiboot/list/?series=112868 > > arch/powerpc/include/asm/opal-api.h | 4 +- > arch/powerpc/include/asm/opal-secvar.h | 23 ++++++ > arch/powerpc/include/asm/opal.h | 6 ++ > arch/powerpc/platforms/powernv/Kconfig | 6 ++ > arch/powerpc/platforms/powernv/Makefile | 1 + > arch/powerpc/platforms/powernv/opal-call.c | 2 + > arch/powerpc/platforms/powernv/opal-secvar.c | 85 ++++++++++++++++++++ > 7 files changed, 126 insertions(+), 1 deletion(-) > create mode 100644 arch/powerpc/include/asm/opal-secvar.h > 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 e1577cfa7186..a505e669b4b6 100644 > --- a/arch/powerpc/include/asm/opal-api.h > +++ b/arch/powerpc/include/asm/opal-api.h > @@ -212,7 +212,9 @@ > #define OPAL_HANDLE_HMI2 166 > #define OPAL_NX_COPROC_INIT 167 > #define OPAL_XIVE_GET_VP_STATE 170 > -#define OPAL_LAST 170 > +#define OPAL_SECVAR_GET 173 > +#define OPAL_SECVAR_BACKEND 177 > +#define OPAL_LAST 177 > > #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-secvar.h b/arch/powerpc/include/asm/opal-secvar.h > new file mode 100644 > index 000000000000..b677171a0368 > --- /dev/null > +++ b/arch/powerpc/include/asm/opal-secvar.h > @@ -0,0 +1,23 @@ > +/* SPDX-License-Identifier: GPL-2.0 */ > +/* > + * PowerNV definitions for secure variables OPAL API. > + * > + * Copyright (C) 2019 IBM Corporation > + * Author: Claudio Carvalho <cclaudio@linux.ibm.com> > + * > + */ > +#ifndef OPAL_SECVAR_H > +#define OPAL_SECVAR_H > + > +enum { > + BACKEND_NONE = 0, > + BACKEND_TC_COMPAT_V1, > +}; > + > +extern int opal_get_variable(u8 *key, unsigned long ksize, > + u8 *metadata, unsigned long *mdsize, > + u8 *data, unsigned long *dsize); > + > +extern int opal_variable_version(unsigned long *backend); > + > +#endif > diff --git a/arch/powerpc/include/asm/opal.h b/arch/powerpc/include/asm/opal.h > index 4cc37e708bc7..57d2c2356eda 100644 > --- a/arch/powerpc/include/asm/opal.h > +++ b/arch/powerpc/include/asm/opal.h > @@ -394,6 +394,12 @@ void opal_powercap_init(void); > void opal_psr_init(void); > void opal_sensor_groups_init(void); > > +extern int opal_secvar_get(uint64_t k_key, uint64_t k_key_len, > + uint64_t k_metadata, uint64_t k_metadata_size, > + uint64_t k_data, uint64_t k_data_size); > + > +extern int opal_secvar_backend(uint64_t k_backend); > + > #endif /* __ASSEMBLY__ */ > > #endif /* _ASM_POWERPC_OPAL_H */ > diff --git a/arch/powerpc/platforms/powernv/Kconfig b/arch/powerpc/platforms/powernv/Kconfig > index 850eee860cf2..65b060539b5c 100644 > --- a/arch/powerpc/platforms/powernv/Kconfig > +++ b/arch/powerpc/platforms/powernv/Kconfig > @@ -47,3 +47,9 @@ 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 > + help > + This enables the kernel to access OPAL secure variables. > diff --git a/arch/powerpc/platforms/powernv/Makefile b/arch/powerpc/platforms/powernv/Makefile > index da2e99efbd04..6651c742e530 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 > 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 > diff --git a/arch/powerpc/platforms/powernv/opal-call.c b/arch/powerpc/platforms/powernv/opal-call.c > index 36c8fa3647a2..0445980f294f 100644 > --- a/arch/powerpc/platforms/powernv/opal-call.c > +++ b/arch/powerpc/platforms/powernv/opal-call.c > @@ -288,3 +288,5 @@ OPAL_CALL(opal_pci_set_pbcq_tunnel_bar, OPAL_PCI_SET_PBCQ_TUNNEL_BAR); > OPAL_CALL(opal_sensor_read_u64, OPAL_SENSOR_READ_U64); > OPAL_CALL(opal_sensor_group_enable, OPAL_SENSOR_GROUP_ENABLE); > OPAL_CALL(opal_nx_coproc_init, OPAL_NX_COPROC_INIT); > +OPAL_CALL(opal_secvar_get, OPAL_SECVAR_GET); > +OPAL_CALL(opal_secvar_backend, OPAL_SECVAR_BACKEND); > diff --git a/arch/powerpc/platforms/powernv/opal-secvar.c b/arch/powerpc/platforms/powernv/opal-secvar.c > new file mode 100644 > index 000000000000..dba441dd5af1 > --- /dev/null > +++ b/arch/powerpc/platforms/powernv/opal-secvar.c > @@ -0,0 +1,85 @@ > +// SPDX-License-Identifier: GPL-2.0 > +/* > + * PowerNV code for secure variables > + * > + * Copyright (C) 2019 IBM Corporation > + * Author: Claudio Carvalho <cclaudio@linux.ibm.com> > + * > + */ > + > +/* > + * The opal wrappers in this file treat the @name, @vendor, and @data > + * parameters as little endian blobs. > + * @name is a ucs2 string > + * @vendor is the vendor GUID. It is converted to LE in the kernel > + * @data variable data, which layout may be different for each variable > + */ > + > +#define pr_fmt(fmt) "secvar: "fmt > + > +#include <linux/types.h> > +#include <asm/opal.h> > +#include <asm/opal-secvar.h> > + > +static bool is_opal_secvar_supported(void) > +{ > + static bool opal_secvar_supported; > + static bool initialized; > + > + if (initialized) > + return opal_secvar_supported; > + > + if (!opal_check_token(OPAL_SECVAR_GET) > + || !opal_check_token(OPAL_SECVAR_BACKEND)) { > + pr_err("OPAL doesn't support secure variables\n"); > + opal_secvar_supported = false; > + } else { > + opal_secvar_supported = true; > + } > + > + initialized = true; > + > + return opal_secvar_supported; > +} > + > +int opal_get_variable(u8 *key, unsigned long ksize, u8 *metadata, > + unsigned long *mdsize, u8 *data, unsigned long *dsize) > +{ > + int rc; > + > + if (!is_opal_secvar_supported()) > + return OPAL_UNSUPPORTED; > + > + if (mdsize) > + *mdsize = cpu_to_be64(*mdsize); > + if (dsize) > + *dsize = cpu_to_be64(*dsize); > + > + rc = opal_secvar_get(__pa(key), ksize, __pa(metadata), __pa(mdsize), > + __pa(data), __pa(dsize)); > + > + if (mdsize) > + *mdsize = be64_to_cpu(*mdsize); > + if (dsize) > + *dsize = be64_to_cpu(*dsize); > + > + return rc; > +} > + > +int opal_variable_version(unsigned long *backend) > +{ > + int rc; > + > + if (!is_opal_secvar_supported()) > + return OPAL_UNSUPPORTED; > + > + if (backend) > + *backend = cpu_to_be64(*backend); > + > + rc = opal_secvar_backend(__pa(backend)); > + > + if (backend) > + *backend = be64_to_cpu(*backend); > + > + return rc; > +} > -- > 2.20.1 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v3 1/3] powerpc/powernv: Add OPAL API interface to get secureboot state 2019-06-12 6:17 ` Daniel Axtens @ 2019-06-12 21:08 ` Nayna 2019-06-12 23:04 ` Daniel Axtens 0 siblings, 1 reply; 11+ messages in thread From: Nayna @ 2019-06-12 21:08 UTC (permalink / raw) To: Daniel Axtens, Nayna Jain, linuxppc-dev, linux-efi, linux-integrity, linux-kernel Cc: Ard Biesheuvel, Eric Richter, Claudio Carvalho, Mimi Zohar, Matthew Garret, Paul Mackerras, Jeremy Kerr [-- Attachment #1: Type: text/plain, Size: 3869 bytes --] On 06/12/2019 02:17 AM, Daniel Axtens wrote: > Nayna Jain <nayna@linux.ibm.com> writes: > >> From: Claudio Carvalho <cclaudio@linux.ibm.com> >> >> The X.509 certificates trusted by the platform and other information >> required to secure boot the OS kernel are wrapped in secure variables, >> which are controlled by OPAL. >> >> This patch adds support to read OPAL secure variables through >> OPAL_SECVAR_GET call. It returns the metadata and data for a given secure >> variable based on the unique key. >> >> Since OPAL can support different types of backend which can vary in the >> variable interpretation, a new OPAL API call named OPAL_SECVAR_BACKEND, is >> added to retrieve the supported backend version. This helps the consumer >> to know how to interpret the variable. >> > (Firstly, apologies that I haven't got around to asking about this yet!) > > Are pluggable/versioned backend a good idea? > > There are a few things that worry me about the idea: > > - It adds complexity in crypto (or crypto-adjacent) code, and that > increases the likelihood that we'll accidentally add a bug with bad > consequences. Sorry, I think I am not clear on what exactly you mean here.Can you please elaborate or give specifics ? > > - Under what circumstances would would we change the kernel-visible > behaviour of skiboot? Are we expecting to change the behaviour, > content or names of the variables in future? Otherwise the only > relevant change I can think of is a change to hardware platforms, and > I'm not sure how a change in hardware would lead to change in > behaviour in the kernel. Wouldn't Skiboot hide h/w differences? Backends are intended to be an agreement for firmware, kernel and userspace on what the format of variables are, what variables should be expected, how they should be signed, etc. Though we don't expect it to happen very often, we want to anticipate possible changes in the firmware which may affect the kernel such as new features, support of new authentication mechanisms, addition of new variables. Corresponding skiboot patches are on - https://lists.ozlabs.org/pipermail/skiboot/2019-June/014641.html > > - If we are worried about a long-term-future change to how secure-boot > works, would it be better to just add more get/set calls to opal at > the point at which we actually implement the new system? The intention is to avoid to re-implement the key/value interface for each scheme. Do you mean to deprecate the old APIs and add new APIs with every scheme ? > > - UEFI added EFI_VARIABLE_AUTHENTICATION_3 in a way that - as far > as I know - didn't break backwards compatibility. Is there a reason > we cannot add features that way instead? (It also dropped v1 of the > authentication header.) > > - What is the correct fallback behaviour if a kernel receives a result > that it does not expect? If a kernel expecting BackendV1 is instead > informed that it is running on BackendV2, then the cannot access the > secure variable at all, so it cannot load keys that are potentially > required to successfully boot (e.g. to validate the module for > network card or graphics!) The backend is declaredby the firmware, and is set at compile-time. The kernel queriesfirmware on whichbackend is in use, and the backend will not change at runtime.If the backend in use by the firmware is not supported by the kernel (e.g. kernel is too old), the kernel does not attempt to read any secure variables, as it won't understand what the format is. This is a secure boot failure condition, as we cannot verify the next kernel. With addition of new backends in the skiboot, the support will be added to the kernel. Note: skiboot and skiroot should always be in sync with backend support. Thanks & Regards, - Nayna [-- Attachment #2: Type: text/html, Size: 10781 bytes --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v3 1/3] powerpc/powernv: Add OPAL API interface to get secureboot state 2019-06-12 21:08 ` Nayna @ 2019-06-12 23:04 ` Daniel Axtens 2019-06-14 22:22 ` Nayna 0 siblings, 1 reply; 11+ messages in thread From: Daniel Axtens @ 2019-06-12 23:04 UTC (permalink / raw) To: Nayna, Nayna Jain, linuxppc-dev, linux-efi, linux-integrity, linux-kernel Cc: Ard Biesheuvel, Eric Richter, Claudio Carvalho, Mimi Zohar, Matthew Garret, Paul Mackerras, Jeremy Kerr Hi Nayna, >>> Since OPAL can support different types of backend which can vary in the >>> variable interpretation, a new OPAL API call named OPAL_SECVAR_BACKEND, is >>> added to retrieve the supported backend version. This helps the consumer >>> to know how to interpret the variable. >>> >> (Firstly, apologies that I haven't got around to asking about this yet!) >> >> Are pluggable/versioned backend a good idea? >> >> There are a few things that worry me about the idea: >> >> - It adds complexity in crypto (or crypto-adjacent) code, and that >> increases the likelihood that we'll accidentally add a bug with bad >> consequences. > > Sorry, I think I am not clear on what exactly you mean here.Can you > please elaborate or give specifics ? Cryptosystems with greater flexibility can have new kinds of vulnerabilities arise from the greater complexity. The first sort of thing that comes to mind is a downgrade attack like from TLS. I think you're protected from this because the mode cannot be negotiatied at run time, but in general it's security sensitive code so I'd like it to be as simple as possible. >> - If we are worried about a long-term-future change to how secure-boot >> works, would it be better to just add more get/set calls to opal at >> the point at which we actually implement the new system? > > The intention is to avoid to re-implement the key/value interface for > each scheme. Do you mean to deprecate the old APIs and add new APIs with > every scheme ? Yes, because I expect the scheme would change very, very rarely. >> - Under what circumstances would would we change the kernel-visible >> behaviour of skiboot? Are we expecting to change the behaviour, >> content or names of the variables in future? Otherwise the only >> relevant change I can think of is a change to hardware platforms, and >> I'm not sure how a change in hardware would lead to change in >> behaviour in the kernel. Wouldn't Skiboot hide h/w differences? > > Backends are intended to be an agreement for firmware, kernel and > userspace on what the format of variables are, what variables should be > expected, how they should be signed, etc. Though we don't expect it to > happen very often, we want to anticipate possible changes in the > firmware which may affect the kernel such as new features, support of > new authentication mechanisms, addition of new variables. Corresponding > skiboot patches are on - > https://lists.ozlabs.org/pipermail/skiboot/2019-June/014641.html I still feel like this is holding onto ongoing complexity for very little gain, but perhaps this is because I can't picture a specific change that would actually require a wholesale change to the scheme. You mention new features, support for new authentication mechanisms, and addition of new variables. - New features is a bit too generic to answer specifically. In general I accept that there exists some new feature that would be sufficiently backwards-incompatible as to require a new version. I just can't think of one off the top of my head and so I'm not convinced it's worth the complexity. Did you have something in mind? - By support for new authentication mechanisms, I assume you mean new mechanisms for authenticating variable updates? This is communicated in edk2 via the attributes field. Looking at patch 5 from the skiboot series: + * When the attribute EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS is set, + * then the Data buffer shall begin with an instance of a complete (and + * serialized) EFI_VARIABLE_AUTHENTICATION_2 descriptor. Could a new authentication scheme be communicated by setting a different attribute value? Or are we not carrying attributes in the metadata blob? - For addition of new variables, I'm confused as to why this would require a new API - wouldn't it just be exposed in the normal way via opal_secvar_get(_next)? I guess I also somewhat object to calling it a 'backend' if we're using it as a version scheme. I think the skiboot storage backends are true backends - they provide different implementations of the same functionality with the same API, but this seems like you're using it to indicate different functionality. It seems like we're using it as if it were called OPAL_SECVAR_VERSION. >> - What is the correct fallback behaviour if a kernel receives a result >> that it does not expect? If a kernel expecting BackendV1 is instead >> informed that it is running on BackendV2, then the cannot access the >> secure variable at all, so it cannot load keys that are potentially >> required to successfully boot (e.g. to validate the module for >> network card or graphics!) > > The backend is declaredby the firmware, and is set at compile-time. The > kernel queriesfirmware on whichbackend is in use, and the backend will > not change at runtime.If the backend in use by the firmware is not > supported by the kernel (e.g. kernel is too old), the kernel does not > attempt to read any secure variables, as it won't understand what the > format is. This is a secure boot failure condition, as we cannot verify > the next kernel. With addition of new backends in the skiboot, the > support will be added to the kernel. Note: skiboot and skiroot should > always be in sync with backend support. Seems reasonable. I'm thinking specifically about the kernel loaded after skiroot; and yes, on reflection just failing to boot is the only sensible thing you can do. Regards, Daniel ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v3 1/3] powerpc/powernv: Add OPAL API interface to get secureboot state 2019-06-12 23:04 ` Daniel Axtens @ 2019-06-14 22:22 ` Nayna 2019-06-16 23:56 ` Daniel Axtens 0 siblings, 1 reply; 11+ messages in thread From: Nayna @ 2019-06-14 22:22 UTC (permalink / raw) To: Daniel Axtens Cc: linux-efi, Ard Biesheuvel, Eric Richter, Nayna Jain, linux-kernel, Mimi Zohar, Claudio Carvalho, Matthew Garret, linuxppc-dev, Paul Mackerras, Jeremy Kerr, linux-integrity On 06/12/2019 07:04 PM, Daniel Axtens wrote: > Hi Nayna, > >>>> Since OPAL can support different types of backend which can vary in the >>>> variable interpretation, a new OPAL API call named OPAL_SECVAR_BACKEND, is >>>> added to retrieve the supported backend version. This helps the consumer >>>> to know how to interpret the variable. >>>> >>> (Firstly, apologies that I haven't got around to asking about this yet!) >>> >>> Are pluggable/versioned backend a good idea? >>> >>> There are a few things that worry me about the idea: >>> >>> - It adds complexity in crypto (or crypto-adjacent) code, and that >>> increases the likelihood that we'll accidentally add a bug with bad >>> consequences. >> Sorry, I think I am not clear on what exactly you mean here.Can you >> please elaborate or give specifics ? > Cryptosystems with greater flexibility can have new kinds of > vulnerabilities arise from the greater complexity. The first sort of > thing that comes to mind is a downgrade attack like from TLS. I think > you're protected from this because the mode cannot be negotiatied at run > time, but in general it's security sensitive code so I'd like it to be > as simple as possible. > >>> - If we are worried about a long-term-future change to how secure-boot >>> works, would it be better to just add more get/set calls to opal at >>> the point at which we actually implement the new system? >> The intention is to avoid to re-implement the key/value interface for >> each scheme. Do you mean to deprecate the old APIs and add new APIs with >> every scheme ? > Yes, because I expect the scheme would change very, very rarely. So, the design is not making the assumption that a particular scheme will change often. It is just allowing the flexibility for addition of new schemes or enhancements if needed. > >>> - Under what circumstances would would we change the kernel-visible >>> behaviour of skiboot? Are we expecting to change the behaviour, >>> content or names of the variables in future? Otherwise the only >>> relevant change I can think of is a change to hardware platforms, and >>> I'm not sure how a change in hardware would lead to change in >>> behaviour in the kernel. Wouldn't Skiboot hide h/w differences? >> Backends are intended to be an agreement for firmware, kernel and >> userspace on what the format of variables are, what variables should be >> expected, how they should be signed, etc. Though we don't expect it to >> happen very often, we want to anticipate possible changes in the >> firmware which may affect the kernel such as new features, support of >> new authentication mechanisms, addition of new variables. Corresponding >> skiboot patches are on - >> https://lists.ozlabs.org/pipermail/skiboot/2019-June/014641.html > I still feel like this is holding onto ongoing complexity for very > little gain, but perhaps this is because I can't picture a specific > change that would actually require a wholesale change to the scheme. That is the exact reason for having pluggable backend, because we cannot determine now if there will be a need of new scheme in future or not. > > You mention new features, support for new authentication mechanisms, and > addition of new variables. > > - New features is a bit too generic to answer specifically. In general > I accept that there exists some new feature that would be > sufficiently backwards-incompatible as to require a new version. I > just can't think of one off the top of my head and so I'm not > convinced it's worth the complexity. Did you have something in mind? That is the idea to keep the design flexible to be able to handle future additions with maximum reuse. Example, supporting new algorithms or a different handling of secure variable updates by different vendors. > > - By support for new authentication mechanisms, I assume you mean new > mechanisms for authenticating variable updates? This is communicated > in edk2 via the attributes field. Looking at patch 5 from the skiboot > series: > > + * When the attribute EFI_VARIABLE_TIME_BASED_AUTHENTICATED_WRITE_ACCESS is set, > + * then the Data buffer shall begin with an instance of a complete (and > + * serialized) EFI_VARIABLE_AUTHENTICATION_2 descriptor. > > Could a new authentication scheme be communicated by setting a > different attribute value? Or are we not carrying attributes in the > metadata blob? > > - For addition of new variables, I'm confused as to why this would > require a new API - wouldn't it just be exposed in the normal way via > opal_secvar_get(_next)? Sorry, probably it wasn't clear. By addition of new variables, we meant that over time we might have to add new "volatile" variables that "fine tunes" secure boot state. This might impact the kernel if it needs to understand new variables to define its policies. However, this will not result in change of API, it will result in change of the version. > > I guess I also somewhat object to calling it a 'backend' if we're using > it as a version scheme. I think the skiboot storage backends are true > backends - they provide different implementations of the same > functionality with the same API, but this seems like you're using it to > indicate different functionality. It seems like we're using it as if it > were called OPAL_SECVAR_VERSION. We are changing how we are exposing the version to the kernel. The version will be exposed as device-tree entry rather than a OPAL runtime service. We are not tied to the name "backend", we can switch to calling it as "scheme" unless there is a better name. Thanks & Regards, - Nayna ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v3 1/3] powerpc/powernv: Add OPAL API interface to get secureboot state 2019-06-14 22:22 ` Nayna @ 2019-06-16 23:56 ` Daniel Axtens 0 siblings, 0 replies; 11+ messages in thread From: Daniel Axtens @ 2019-06-16 23:56 UTC (permalink / raw) To: Nayna Cc: linux-efi, Ard Biesheuvel, Eric Richter, Nayna Jain, linux-kernel, Mimi Zohar, Claudio Carvalho, Matthew Garret, linuxppc-dev, Paul Mackerras, Jeremy Kerr, linux-integrity Hi Nayna, >> I guess I also somewhat object to calling it a 'backend' if we're using >> it as a version scheme. I think the skiboot storage backends are true >> backends - they provide different implementations of the same >> functionality with the same API, but this seems like you're using it to >> indicate different functionality. It seems like we're using it as if it >> were called OPAL_SECVAR_VERSION. > > We are changing how we are exposing the version to the kernel. The > version will be exposed as device-tree entry rather than a OPAL runtime > service. We are not tied to the name "backend", we can switch to calling > it as "scheme" unless there is a better name. This sounds like a good approach to me. Kind regards, Daniel > > Thanks & Regards, > - Nayna ^ permalink raw reply [flat|nested] 11+ messages in thread
* [PATCH v3 2/3] powerpc/powernv: detect the secure boot mode of the system 2019-06-10 20:33 [PATCH v3 0/3] powerpc: Enabling IMA arch specific secure boot policies Nayna Jain 2019-06-10 20:33 ` [PATCH v3 1/3] powerpc/powernv: Add OPAL API interface to get secureboot state Nayna Jain @ 2019-06-10 20:33 ` Nayna Jain 2019-06-10 20:33 ` [PATCH v3 3/3] powerpc: Add support to initialize ima policy rules Nayna Jain 2 siblings, 0 replies; 11+ messages in thread From: Nayna Jain @ 2019-06-10 20:33 UTC (permalink / raw) To: linuxppc-dev, linux-efi, linux-integrity, linux-kernel Cc: Ard Biesheuvel, Nayna Jain, Claudio Carvalho, Mimi Zohar, Matthew Garret, Paul Mackerras, Jeremy Kerr 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 <nayna@linux.ibm.com> --- arch/powerpc/include/asm/secboot.h | 21 ++++++++ arch/powerpc/platforms/powernv/Makefile | 3 +- arch/powerpc/platforms/powernv/secboot.c | 61 ++++++++++++++++++++++++ 3 files changed, 84 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 000000000000..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 <nayna@linux.ibm.com> + * + */ +#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 6651c742e530..74705a3fc474 100644 --- a/arch/powerpc/platforms/powernv/Makefile +++ b/arch/powerpc/platforms/powernv/Makefile @@ -4,6 +4,7 @@ obj-y += idle.o opal-rtc.o opal-nvram.o opal-lpc.o opal-flash.o obj-y += rng.o opal-elog.o opal-dump.o opal-sysparam.o opal-sensor.o obj-y += opal-msglog.o opal-hmi.o opal-power.o opal-irqchip.o obj-y += opal-kmsg.o opal-powercap.o opal-psr.o opal-sensor-groups.o +obj-y += secboot.o obj-$(CONFIG_SMP) += smp.o subcore.o subcore-asm.o obj-$(CONFIG_PCI) += pci.o pci-ioda.o npu-dma.o pci-ioda-tce.o @@ -16,4 +17,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 000000000000..9199e520ebed --- /dev/null +++ b/arch/powerpc/platforms/powernv/secboot.c @@ -0,0 +1,61 @@ +// SPDX-License-Identifier: GPL-2.0 +/* + * Copyright (C) 2019 IBM Corporation + * Author: Nayna Jain <nayna@linux.ibm.com> + * + * secboot.c + * - util function to get powerpc secboot state + */ +#include <linux/uuid.h> +#include <asm/opal.h> +#include <asm/secboot.h> +#include <asm/opal-secvar.h> + +bool get_powerpc_sb_mode(void) +{ + u8 secure_boot_name[] = "SecureBoot"; + u8 setup_mode_name[] = "SetupMode"; + u8 secboot, setupmode; + unsigned long size = sizeof(secboot); + int status; + unsigned long version; + + status = opal_variable_version(&version); + if ((status != OPAL_SUCCESS) || (version != BACKEND_TC_COMPAT_V1)) { + pr_info("secboot: error retrieving compatible backend\n"); + return false; + } + + status = opal_get_variable(secure_boot_name, sizeof(secure_boot_name), + NULL, NULL, &secboot, &size); + + /* + * For now assume all failures reading the SecureBoot variable implies + * secure boot is not enabled. Later differentiate failure types. + */ + if (status != OPAL_SUCCESS) { + secboot = 0; + setupmode = 0; + goto out; + } + + size = sizeof(setupmode); + status = opal_get_variable(setup_mode_name, sizeof(setup_mode_name), + NULL, NULL, &setupmode, &size); + + /* + * Failure to read the SetupMode variable does not prevent + * secure boot mode + */ + if (status != OPAL_SUCCESS) + setupmode = 0; + +out: + if ((secboot == 0) || (setupmode == 1)) { + pr_info("secboot: secureboot mode disabled\n"); + return false; + } + + pr_info("secboot: secureboot mode enabled\n"); + return true; +} -- 2.20.1 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* [PATCH v3 3/3] powerpc: Add support to initialize ima policy rules 2019-06-10 20:33 [PATCH v3 0/3] powerpc: Enabling IMA arch specific secure boot policies Nayna Jain 2019-06-10 20:33 ` [PATCH v3 1/3] powerpc/powernv: Add OPAL API interface to get secureboot state Nayna Jain 2019-06-10 20:33 ` [PATCH v3 2/3] powerpc/powernv: detect the secure boot mode of the system Nayna Jain @ 2019-06-10 20:33 ` Nayna Jain 2019-06-11 5:19 ` Satheesh Rajendran 2 siblings, 1 reply; 11+ messages in thread From: Nayna Jain @ 2019-06-10 20:33 UTC (permalink / raw) To: linuxppc-dev, linux-efi, linux-integrity, linux-kernel Cc: Ard Biesheuvel, Nayna Jain, Claudio Carvalho, Mimi Zohar, Matthew Garret, Paul Mackerras, Jeremy Kerr 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 provides arch-specific IMA policies if PPC_SECURE_BOOT config is enabled. Signed-off-by: Nayna Jain <nayna@linux.ibm.com> --- arch/powerpc/Kconfig | 14 +++++++++ arch/powerpc/kernel/Makefile | 1 + arch/powerpc/kernel/ima_arch.c | 54 ++++++++++++++++++++++++++++++++++ include/linux/ima.h | 3 +- 4 files changed, 71 insertions(+), 1 deletion(-) create mode 100644 arch/powerpc/kernel/ima_arch.c diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index 8c1c636308c8..9de77bb14f54 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -902,6 +902,20 @@ config PPC_MEM_KEYS If unsure, say y. +config PPC_SECURE_BOOT + prompt "Enable PowerPC Secure Boot" + bool + default n + depends on PPC64 + depends on OPAL_SECVAR + 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 0ea6c4aa3a20..75c929b41341 100644 --- a/arch/powerpc/kernel/Makefile +++ b/arch/powerpc/kernel/Makefile @@ -131,6 +131,7 @@ ifdef CONFIG_IMA obj-y += ima_kexec.o endif endif +obj-$(CONFIG_PPC_SECURE_BOOT) += 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 000000000000..1767bf6e6550 --- /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 <nayna@linux.ibm.com> + * + * ima_arch.c + * - initialize ima policies for PowerPC Secure Boot + */ + +#include <linux/ima.h> +#include <asm/secboot.h> + +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 template=ima-modsig", + "measure func=MODULE_CHECK template=ima-modsig", + NULL +}; + +/* Both file signature verification and measurements are needed */ +static const char *const sb_arch_rules[] = { + "measure func=KEXEC_KERNEL_CHECK template=ima-modsig", + "measure func=MODULE_CHECK template=ima-modsig", + "appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig|modsig template=ima-modsig", +#if !IS_ENABLED(CONFIG_MODULE_SIG) + "appraise func=MODULE_CHECK appraise_type=imasig|modsig template=ima-modsig", +#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 fd9f7cf4cdf5..a01df076ecae 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)) || defined(CONFIG_S390) +#if (defined(CONFIG_X86) && defined(CONFIG_EFI)) || defined(CONFIG_S390) \ + || 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 ^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: [PATCH v3 3/3] powerpc: Add support to initialize ima policy rules 2019-06-10 20:33 ` [PATCH v3 3/3] powerpc: Add support to initialize ima policy rules Nayna Jain @ 2019-06-11 5:19 ` Satheesh Rajendran 2019-06-11 17:07 ` Nayna 0 siblings, 1 reply; 11+ messages in thread From: Satheesh Rajendran @ 2019-06-11 5:19 UTC (permalink / raw) To: Nayna Jain Cc: linux-efi, Ard Biesheuvel, linux-kernel, Mimi Zohar, Claudio Carvalho, Matthew Garret, linuxppc-dev, Paul Mackerras, Jeremy Kerr, linux-integrity On Mon, Jun 10, 2019 at 04:33:57PM -0400, Nayna Jain wrote: > 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 provides arch-specific IMA policies if PPC_SECURE_BOOT > config is enabled. > > Signed-off-by: Nayna Jain <nayna@linux.ibm.com> > --- > arch/powerpc/Kconfig | 14 +++++++++ > arch/powerpc/kernel/Makefile | 1 + > arch/powerpc/kernel/ima_arch.c | 54 ++++++++++++++++++++++++++++++++++ > include/linux/ima.h | 3 +- > 4 files changed, 71 insertions(+), 1 deletion(-) > create mode 100644 arch/powerpc/kernel/ima_arch.c Hi, This series failed to build against linuxppc/merge tree with `ppc64le_defconfig`, arch/powerpc/platforms/powernv/secboot.c:14:6: error: redefinition of 'get_powerpc_sb_mode' 14 | bool get_powerpc_sb_mode(void) | ^~~~~~~~~~~~~~~~~~~ In file included from arch/powerpc/platforms/powernv/secboot.c:11: ./arch/powerpc/include/asm/secboot.h:15:20: note: previous definition of 'get_powerpc_sb_mode' was here 15 | static inline bool get_powerpc_sb_mode(void) | ^~~~~~~~~~~~~~~~~~~ make[3]: *** [scripts/Makefile.build:278: arch/powerpc/platforms/powernv/secboot.o] Error 1 make[3]: *** Waiting for unfinished jobs.... make[2]: *** [scripts/Makefile.build:489: arch/powerpc/platforms/powernv] Error 2 make[1]: *** [scripts/Makefile.build:489: arch/powerpc/platforms] Error 2 make: *** [Makefile:1071: arch/powerpc] Error 2 make: *** Waiting for unfinished jobs.... Regards, -Satheesh > > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index 8c1c636308c8..9de77bb14f54 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -902,6 +902,20 @@ config PPC_MEM_KEYS > > If unsure, say y. > > +config PPC_SECURE_BOOT > + prompt "Enable PowerPC Secure Boot" > + bool > + default n > + depends on PPC64 > + depends on OPAL_SECVAR > + 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 0ea6c4aa3a20..75c929b41341 100644 > --- a/arch/powerpc/kernel/Makefile > +++ b/arch/powerpc/kernel/Makefile > @@ -131,6 +131,7 @@ ifdef CONFIG_IMA > obj-y += ima_kexec.o > endif > endif > +obj-$(CONFIG_PPC_SECURE_BOOT) += 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 000000000000..1767bf6e6550 > --- /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 <nayna@linux.ibm.com> > + * > + * ima_arch.c > + * - initialize ima policies for PowerPC Secure Boot > + */ > + > +#include <linux/ima.h> > +#include <asm/secboot.h> > + > +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 template=ima-modsig", > + "measure func=MODULE_CHECK template=ima-modsig", > + NULL > +}; > + > +/* Both file signature verification and measurements are needed */ > +static const char *const sb_arch_rules[] = { > + "measure func=KEXEC_KERNEL_CHECK template=ima-modsig", > + "measure func=MODULE_CHECK template=ima-modsig", > + "appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig|modsig template=ima-modsig", > +#if !IS_ENABLED(CONFIG_MODULE_SIG) > + "appraise func=MODULE_CHECK appraise_type=imasig|modsig template=ima-modsig", > +#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 fd9f7cf4cdf5..a01df076ecae 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)) || defined(CONFIG_S390) > +#if (defined(CONFIG_X86) && defined(CONFIG_EFI)) || defined(CONFIG_S390) \ > + || 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 > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [PATCH v3 3/3] powerpc: Add support to initialize ima policy rules 2019-06-11 5:19 ` Satheesh Rajendran @ 2019-06-11 17:07 ` Nayna 0 siblings, 0 replies; 11+ messages in thread From: Nayna @ 2019-06-11 17:07 UTC (permalink / raw) To: Satheesh Rajendran, Nayna Jain Cc: linux-efi, Ard Biesheuvel, linux-kernel, Mimi Zohar, Claudio Carvalho, Matthew Garret, linuxppc-dev, Paul Mackerras, Jeremy Kerr, linux-integrity On 06/11/2019 01:19 AM, Satheesh Rajendran wrote: > On Mon, Jun 10, 2019 at 04:33:57PM -0400, Nayna Jain wrote: >> 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 provides arch-specific IMA policies if PPC_SECURE_BOOT >> config is enabled. >> >> Signed-off-by: Nayna Jain <nayna@linux.ibm.com> >> --- >> arch/powerpc/Kconfig | 14 +++++++++ >> arch/powerpc/kernel/Makefile | 1 + >> arch/powerpc/kernel/ima_arch.c | 54 ++++++++++++++++++++++++++++++++++ >> include/linux/ima.h | 3 +- >> 4 files changed, 71 insertions(+), 1 deletion(-) >> create mode 100644 arch/powerpc/kernel/ima_arch.c > Hi, > > This series failed to build against linuxppc/merge tree with `ppc64le_defconfig`, > > arch/powerpc/platforms/powernv/secboot.c:14:6: error: redefinition of 'get_powerpc_sb_mode' > 14 | bool get_powerpc_sb_mode(void) > | ^~~~~~~~~~~~~~~~~~~ > In file included from arch/powerpc/platforms/powernv/secboot.c:11: > ./arch/powerpc/include/asm/secboot.h:15:20: note: previous definition of 'get_powerpc_sb_mode' was here > 15 | static inline bool get_powerpc_sb_mode(void) > | ^~~~~~~~~~~~~~~~~~~ > make[3]: *** [scripts/Makefile.build:278: arch/powerpc/platforms/powernv/secboot.o] Error 1 > make[3]: *** Waiting for unfinished jobs.... > make[2]: *** [scripts/Makefile.build:489: arch/powerpc/platforms/powernv] Error 2 > make[1]: *** [scripts/Makefile.build:489: arch/powerpc/platforms] Error 2 > make: *** [Makefile:1071: arch/powerpc] Error 2 > make: *** Waiting for unfinished jobs.... Thanks for reporting. I have fixed it and reposted as v4. Please retry. Thanks & Regards, - Nayna ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2019-06-16 23:58 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-06-10 20:33 [PATCH v3 0/3] powerpc: Enabling IMA arch specific secure boot policies Nayna Jain 2019-06-10 20:33 ` [PATCH v3 1/3] powerpc/powernv: Add OPAL API interface to get secureboot state Nayna Jain 2019-06-12 6:17 ` Daniel Axtens 2019-06-12 21:08 ` Nayna 2019-06-12 23:04 ` Daniel Axtens 2019-06-14 22:22 ` Nayna 2019-06-16 23:56 ` Daniel Axtens 2019-06-10 20:33 ` [PATCH v3 2/3] powerpc/powernv: detect the secure boot mode of the system Nayna Jain 2019-06-10 20:33 ` [PATCH v3 3/3] powerpc: Add support to initialize ima policy rules Nayna Jain 2019-06-11 5:19 ` Satheesh Rajendran 2019-06-11 17:07 ` Nayna
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).