This patchset extends the previous version of the patchset[1] by adding
the support for checking against the binary blacklisted hashes.
IMA subsystem supports custom, built-in, arch-specific policies to define
the files to be measured and appraised. These policies are honored based
on the priority where arch-specific policies is the highest and custom
is the lowest.
PowerNV systems uses the linux based bootloader and kexec the Host OS.
It rely on IMA for signature verification of the kernel before doing the
kexec. This patchset adds support for powerpc arch specific ima policies
that are defined based on system's OS secureboot and trustedboot state.
The OS secureboot and trustedboot state are determined via device-tree
properties.
The verification needs to be done only for the binaries which are not
blacklisted. The kernel currently checks against the blacklisted keys.
However that results in blacklisting all the binaries that are signed by
that key. In order to prevent single binary from loading, it is required
to support checking against blacklisting of the binary hash. This patchset
adds the support in IMA to check against blacklisted hashes for the files
signed by appended signature.
[1] http://patchwork.ozlabs.org/cover/1149262/
Changelog:
v6:
* includes feedbacks from Michael Ellerman on the patchset v5
* removed email ids from comments
* add the doc for the device-tree
* renames the secboot.c to secure_boot.c and secboot.h to secure_boot.h
* other code specific fixes
* split the patches to differentiate between secureboot and trustedboot
state of the system
* adds the patches to support the blacklisting of the binary hash.
v5:
* secureboot state is now read via device tree entry rather than OPAL
secure variables
* ima arch policies are updated to use policy based template for
measurement rules
v4:
* Fixed the build issue as reported by Satheesh Rajendran.
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
Nayna Jain (9):
dt-bindings: ibm,secureboot: secure boot specific properties for
PowerNV
powerpc: detect the secure boot mode of the system
powerpc: add support to initialize ima policy rules
powerpc: detect the trusted boot state of the system
powerpc/ima: add measurement rules to ima arch specific policy
ima: make process_buffer_measurement() non-static
ima: check against blacklisted hashes for files with modsig
ima: deprecate permit_directio, instead use appraise_flag
powerpc/ima: update ima arch policy to check for blacklist
Documentation/ABI/testing/ima_policy | 3 +-
.../bindings/powerpc/ibm,secureboot.rst | 76 +++++++++++++++
.../devicetree/bindings/powerpc/secvar.rst | 89 +++++++++++++++++
arch/powerpc/Kconfig | 12 +++
arch/powerpc/include/asm/secure_boot.h | 37 +++++++
arch/powerpc/kernel/Makefile | 2 +
arch/powerpc/kernel/ima_arch.c | 71 ++++++++++++++
arch/powerpc/kernel/secure_boot.c | 96 +++++++++++++++++++
include/linux/ima.h | 3 +-
security/integrity/ima/ima.h | 15 +++
security/integrity/ima/ima_appraise.c | 35 +++++++
security/integrity/ima/ima_main.c | 37 +++----
security/integrity/ima/ima_policy.c | 12 ++-
security/integrity/integrity.h | 1 +
14 files changed, 468 insertions(+), 21 deletions(-)
create mode 100644 Documentation/devicetree/bindings/powerpc/ibm,secureboot.rst
create mode 100644 Documentation/devicetree/bindings/powerpc/secvar.rst
create mode 100644 arch/powerpc/include/asm/secure_boot.h
create mode 100644 arch/powerpc/kernel/ima_arch.c
create mode 100644 arch/powerpc/kernel/secure_boot.c
--
2.20.1
PowerNV represents both the firmware and Host OS secureboot state of the
system via device tree. This patch adds the documentation to give
the definition of the nodes and the properties.
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
---
.../bindings/powerpc/ibm,secureboot.rst | 76 ++++++++++++++++
.../devicetree/bindings/powerpc/secvar.rst | 89 +++++++++++++++++++
2 files changed, 165 insertions(+)
create mode 100644 Documentation/devicetree/bindings/powerpc/ibm,secureboot.rst
create mode 100644 Documentation/devicetree/bindings/powerpc/secvar.rst
@@ -0,0 +1,76 @@+# SPDX-License-Identifier: GPL-2.0+*** NOTE ***+This document is copied from OPAL firmware+(skiboot/doc/device-tree/ibm,secureboot.rst)+************+.._device-tree/ibm,secureboot:++ibm,secureboot+==============++The ``ìbm,secureboot`` node provides secure boot and trusted boot information+up to the target OS. Further information can be found in :ref:`stb-overview`.++Required properties+-------------------++..code-block:: none++ compatible: Either one of the following values:++ ibm,secureboot-v1 : The container-verification-code+ is stored in a secure ROM memory.++ ibm,secureboot-v2 : The container-verification-code+ is stored in a reserved memory.+ It described by the ibm,cvc child+ node.++ ibm,secureboot-v3 : The container-verification-code+ is stored in a reserved memory.+ It described by the ibm,cvc child+ node. Secure variables are+ supported. `secvar` node should+ be created.++ secure-enabled: this property exists when the firmware stack is booting+ in secure mode (hardware secure boot jumper asserted).++ trusted-enabled: this property exists when the firmware stack is booting+ in trusted mode.++ hw-key-hash: hash of the three hardware public keys trusted by the+ platformw owner. This is used to verify if a firmware+ code is signed with trusted keys.++ hw-key-hash-size: hw-key-hash size++ secvar: this node is created if the platform supports secure+ variables. Contains information about the current+ secvar status, see 'secvar.rst'.++Obsolete properties+-------------------++..code-block:: none++ hash-algo: Superseded by the hw-key-hash-size property in+ 'ibm,secureboot-v2'.++Example+-------++..code-block:: dts++ ibm,secureboot {+ compatible = "ibm,secureboot-v2";+ secure-enabled;+ trusted-enabled;+ hw-key-hash-size = <0x40>;+ hw-key-hash = <0x40d487ff 0x7380ed6a 0xd54775d5 0x795fea0d 0xe2f541fe+ 0xa9db06b8 0x466a42a3 0x20e65f75 0xb4866546 0x0017d907+ 0x515dc2a5 0xf9fc5095 0x4d6ee0c9 0xb67d219d 0xfb708535+ 0x1d01d6d1>;+ phandle = <0x100000fd>;+ linux,phandle = <0x100000fd>;+ };
@@ -0,0 +1,89 @@+# SPDX-License-Identifier: GPL-2.0+*** NOTE ***+This document is copied from OPAL firmware+(skiboot/doc/device-tree/secvar.rst)+************+.._device-tree/ibm,secureboot/secvar:++secvar+======++The ``secvar`` node provides secure variable information for the secure+boot of the target OS.++Required properties+-------------------++..code-block:: none++ compatible: this property is set based on the current secure+ variable scheme as set by the platform.++ status: set to "fail" if the secure variables could not+ be initialized, validated, or some other+ catastrophic failure.++ update-status: contains the return code of the update queue+ process run during initialization. Signifies if+ updates were processed or not, and if there was+ an error. See table below++ secure-mode: a u64 bitfield set by the backend to determine+ what secure mode we should be in, and if host+ secure boot should be enforced.++Example+-------++..code-block:: dts++ secvar {+ compatible = "ibm,edk2-compat-v1";+ status = "okay";+ secure-mode = "1";+ };++Update Status+-------------++The update status property should be set by the backend driver to a value+that best fits its error condtion. The following table defines the+general intent of each error code, check backend specific documentation+for more detail.+++-----------------+-----------------------------------------------++| update-status | Generic Reason |++-----------------|-----------------------------------------------++| OPAL_SUCCESS | Updates were found and processed successfully |++-----------------|-----------------------------------------------++| OPAL_EMPTY | No updates were found, none processed |++-----------------|-----------------------------------------------++| OPAL_PARAMETER | Unable to parse data in the update section |++-----------------|-----------------------------------------------++| OPAL_PERMISSION | Update failed to apply, possible auth failure |++-----------------|-----------------------------------------------++| OPAL_HARDWARE | Misc. storage-related error |++-----------------|-----------------------------------------------++| OPAL_RESOURCE | Out of space (somewhere) |++-----------------|-----------------------------------------------++| OPAL_NO_MEM | Out of memory |++-----------------+-----------------------------------------------+++Secure Mode+-----------+++-----------------------+------------------------++| backend specific-bits | generic mode bits |++-----------------------+------------------------++64 32 0++The secure mode property should be set by the backend driver. The least+significant 32 bits are reserved for generic modes, shared across all+possible backends. The other 32 bits are open for backends to determine+their own modes. Any kernel must be made aware of any custom modes.++At the moment, only one general-purpose bit is defined:++``#define SECVAR_SECURE_MODE_ENFORCING 0x1``++which signals that a kernel should enforce host secure boot.
Secure boot on PowerNV 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.
The PPC_SECURE_BOOT config represents the base enablement of secureboot
on POWER.
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
---
arch/powerpc/Kconfig | 10 ++++
arch/powerpc/include/asm/secure_boot.h | 31 ++++++++++
arch/powerpc/kernel/Makefile | 2 +
arch/powerpc/kernel/secure_boot.c | 82 ++++++++++++++++++++++++++
4 files changed, 125 insertions(+)
create mode 100644 arch/powerpc/include/asm/secure_boot.h
create mode 100644 arch/powerpc/kernel/secure_boot.c
@@ -0,0 +1,82 @@+// SPDX-License-Identifier: GPL-2.0+/*+*Copyright(C)2019IBMCorporation+*Author:NaynaJain+*/+#include<linux/types.h>+#include<linux/of.h>+#include<asm/secure_boot.h>++staticstructdevice_node*get_powerpc_fw_sb_node(void)+{+returnof_find_node_by_name(NULL,"ibm,secureboot");+}++boolis_powerpc_os_sb_supported(void)+{+structdevice_node*node=NULL;++node=get_powerpc_fw_sb_node();+if(node&&of_device_is_compatible(node,"ibm,secureboot-v3"))+returntrue;++returnfalse;+}++intget_powerpc_os_sb_node(structdevice_node**node)+{+structdevice_node*fwsbnode;++if(!is_powerpc_os_sb_supported())+return-ENOTSUPP;++fwsbnode=get_powerpc_fw_sb_node();+if(!fwsbnode)+return-ENOENT;++*node=of_find_node_by_name(fwsbnode,"secvar");+if(*node)+return0;++return-ENOENT;+}++boolis_powerpc_os_secureboot_enabled(void)+{+structdevice_node*node;+u64sbmode=0;+intrc;++rc=get_powerpc_os_sb_node(&node);+if(rc==-ENOTSUPP)+gotodisabled;++/* Fail secure for any failure related to secvar */+if(rc){+pr_err("Expected secure variables support, fail secure\n");+gotoenabled;+}++if(!of_device_is_available(node)){+pr_err("Secure variables support is in error state, fail secure\n");+gotoenabled;+}++rc=of_property_read_u64(node,"os-secure-mode",&sbmode);+if(rc)+gotoenabled;++sbmode=be64_to_cpu(sbmode);++/* checks for the secure mode enforcing bit */+if(!(sbmode&SECURE_BOOT_MASK))+gotodisabled;++enabled:+pr_info("secureboot mode enabled\n");+returntrue;++disabled:+pr_info("secureboot mode disabled\n");+returnfalse;+}
PowerNV systems uses kernel based bootloader, thus its secure boot
implementation uses kernel IMA security subsystem to verify the kernel
before kexec. Since the verification policy might differ based on the
secure boot mode of the system, the policies are defined at runtime.
This patch implements the arch-specific support to define the IMA policy
rules based on the runtime secure boot mode of the system.
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 | 2 ++
arch/powerpc/kernel/Makefile | 2 +-
arch/powerpc/kernel/ima_arch.c | 33 +++++++++++++++++++++++++++++++++
include/linux/ima.h | 3 ++-
4 files changed, 38 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/kernel/ima_arch.c
PowerNV systems enables the IMA measurement rules only if the
trusted boot is enabled on the system.
This patch adds the function to detect if the system has trusted
boot enabled.
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
---
arch/powerpc/include/asm/secure_boot.h | 6 ++++++
arch/powerpc/kernel/secure_boot.c | 14 ++++++++++++++
2 files changed, 20 insertions(+)
This patch adds the measurement rules to the arch specific policies for the
systems with trusted boot.
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
---
arch/powerpc/kernel/ima_arch.c | 44 +++++++++++++++++++++++++++++++---
1 file changed, 41 insertions(+), 3 deletions(-)
To add the support for checking against blacklist, it would be needed
to add an additional measurement record that identifies the record
as blacklisted.
This patch modifies the process_buffer_measurement() and makes it
non static to be used by blacklist functionality. It modifies the
function to handle more than just the KEXEC_CMDLINE.
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
---
security/integrity/ima/ima.h | 3 +++
security/integrity/ima/ima_main.c | 29 ++++++++++++++---------------
2 files changed, 17 insertions(+), 15 deletions(-)
Asymmetric private keys are used to sign multiple files. The kernel
currently support checking against the blacklisted keys. However, if the
public key is blacklisted, any file signed by the blacklisted key will
automatically fail signature verification. We might not want to blacklist
all the files signed by a particular key, but just a single file.
Blacklisting the public key is not fine enough granularity.
This patch adds support for blacklisting binaries with appended signatures,
based on the IMA policy. Defined is a new policy option
"appraise_flag=check_blacklist".
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
---
Documentation/ABI/testing/ima_policy | 1 +
security/integrity/ima/ima.h | 12 +++++++++
security/integrity/ima/ima_appraise.c | 35 +++++++++++++++++++++++++++
security/integrity/ima/ima_main.c | 8 ++++--
security/integrity/ima/ima_policy.c | 10 ++++++--
security/integrity/integrity.h | 1 +
6 files changed, 63 insertions(+), 4 deletions(-)
This patch deprecates the existing permit_directio flag, instead adds
it as possible value to appraise_flag parameter.
For eg.
appraise_flag=permit_directio
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
---
Documentation/ABI/testing/ima_policy | 4 ++--
security/integrity/ima/ima_policy.c | 2 ++
2 files changed, 4 insertions(+), 2 deletions(-)
This patch updates the arch specific policies for PowernV systems
to add check against blacklisted hashes before doing the verification.
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
---
arch/powerpc/kernel/ima_arch.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
@@ -22,12 +32,40 @@ static const char *const arch_rules[] = { }; /*- * Returns the relevant IMA arch policies based on the system secureboot state.+ * The "measure_rules" are enabled only on "trustedboot" enabled systems.+ * These rules add the kexec kernel image and kernel modules file hashes to+ * the IMA measurement list.+ */+static const char *const measure_rules[] = {+ "measure func=KEXEC_KERNEL_CHECK",+ "measure func=MODULE_CHECK",+ NULL+};++/*+ * Returns the relevant IMA arch policies based on the system secureboot+ * and trustedboot state. */ const char *const *arch_get_ima_policy(void) {- if (is_powerpc_os_secureboot_enabled())+ const char *const *rules;+ int offset = 0;++ for (rules = arch_rules; *rules != NULL; rules++) {+ if (strncmp(*rules, "appraise", 8) == 0)+ break;+ offset++;+ }++ if (is_powerpc_os_secureboot_enabled()+ && is_powerpc_trustedboot_enabled()) return arch_rules;+ if (is_powerpc_os_secureboot_enabled())+ return arch_rules + offset;++ if (is_powerpc_trustedboot_enabled())+ return measure_rules;+ return NULL; }
PowerNV systems uses kernel based bootloader, thus its secure boot
implementation uses kernel IMA security subsystem to verify the kernel
before kexec. Since the verification policy might differ based on the
secure boot mode of the system, the policies are defined at runtime.
This patch implements the arch-specific support to define the IMA policy
rules based on the runtime secure boot mode of the system.
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 | 2 ++
arch/powerpc/kernel/Makefile | 2 +-
arch/powerpc/kernel/ima_arch.c | 33 +++++++++++++++++++++++++++++++++
include/linux/ima.h | 3 ++-
4 files changed, 38 insertions(+), 2 deletions(-)
create mode 100644 arch/powerpc/kernel/ima_arch.c
@@ -0,0 +1,33 @@+// SPDX-License-Identifier: GPL-2.0+/*+*Copyright(C)2019IBMCorporation+*Author:NaynaJain+*/++#include<linux/ima.h>+#include<asm/secure_boot.h>++boolarch_ima_get_secureboot(void)+{+returnis_powerpc_os_secureboot_enabled();+}++/* Defines IMA appraise rules for secureboot */+staticconstchar*constarch_rules[]={+"appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig|modsig",+#if !IS_ENABLED(CONFIG_MODULE_SIG)+"appraise func=MODULE_CHECK appraise_type=imasig|modsig",+#endif+NULL+};++/*+*ReturnstherelevantIMAarchpoliciesbasedonthesystemsecurebootstate.+*/+constchar*const*arch_get_ima_policy(void)+{+if(is_powerpc_os_secureboot_enabled())+returnarch_rules;++returnNULL;+}
If CONFIG_MODULE_SIG is enabled but module signatures aren't enforced,
then IMA won't enforce module signature either. x86's
arch_get_ima_policy() calls set_module_sig_enforced(). Doesn't the
powerpc version need to do that as well?
On the flip side, if module signatures are enforced by the module
subsystem then IMA will verify the signature a second time since there's
no sharing of signature verification results between the module
subsystem and IMA (this was observed by Mimi).
IMHO this is a minor issue, since module loading isn't a hot path and
the duplicate work shouldn't impact anything. But it could be avoided by
having a NULL entry in arch_rules, which arch_get_ima_policy() would
dynamically update with the "appraise func=MODULE_CHECK" rule if
is_module_sig_enforced() is true.
--
Thiago Jung Bauermann
IBM Linux Technology Center
From: Rob Herring <robh@kernel.org> Date: 2019-10-01 13:33:34
On Fri, Sep 27, 2019 at 10:25:52AM -0400, Nayna Jain wrote:
quoted hunk
PowerNV represents both the firmware and Host OS secureboot state of the
system via device tree. This patch adds the documentation to give
the definition of the nodes and the properties.
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
---
.../bindings/powerpc/ibm,secureboot.rst | 76 ++++++++++++++++
.../devicetree/bindings/powerpc/secvar.rst | 89 +++++++++++++++++++
2 files changed, 165 insertions(+)
create mode 100644 Documentation/devicetree/bindings/powerpc/ibm,secureboot.rst
create mode 100644 Documentation/devicetree/bindings/powerpc/secvar.rst
+*** NOTE ***
+This document is copied from OPAL firmware
+(skiboot/doc/device-tree/ibm,secureboot.rst)
Why copy into the kernel?
Plus, the bindings are in the process of being converted to schema. What
would I do with these files?
quoted hunk
+************
+.. _device-tree/ibm,secureboot:
+
+ibm,secureboot
+==============
+
+The ``ìbm,secureboot`` node provides secure boot and trusted boot information
+up to the target OS. Further information can be found in :ref:`stb-overview`.
+
+Required properties
+-------------------
+
+.. code-block:: none
+
+ compatible: Either one of the following values:
+
+ ibm,secureboot-v1 : The container-verification-code
+ is stored in a secure ROM memory.
+
+ ibm,secureboot-v2 : The container-verification-code
+ is stored in a reserved memory.
+ It described by the ibm,cvc child
+ node.
+
+ ibm,secureboot-v3 : The container-verification-code
+ is stored in a reserved memory.
+ It described by the ibm,cvc child
+ node. Secure variables are
+ supported. `secvar` node should
+ be created.
+
+ secure-enabled: this property exists when the firmware stack is booting
+ in secure mode (hardware secure boot jumper asserted).
+
+ trusted-enabled: this property exists when the firmware stack is booting
+ in trusted mode.
+
+ hw-key-hash: hash of the three hardware public keys trusted by the
+ platformw owner. This is used to verify if a firmware
+ code is signed with trusted keys.
+
+ hw-key-hash-size: hw-key-hash size
+
+ secvar: this node is created if the platform supports secure
+ variables. Contains information about the current
+ secvar status, see 'secvar.rst'.
+
+Obsolete properties
+-------------------
+
+.. code-block:: none
+
+ hash-algo: Superseded by the hw-key-hash-size property in
+ 'ibm,secureboot-v2'.
+
+Example
+-------
+
+.. code-block:: dts
+
+ ibm,secureboot {
+ compatible = "ibm,secureboot-v2";
+ secure-enabled;
+ trusted-enabled;
+ hw-key-hash-size = <0x40>;
+ hw-key-hash = <0x40d487ff 0x7380ed6a 0xd54775d5 0x795fea0d 0xe2f541fe
+ 0xa9db06b8 0x466a42a3 0x20e65f75 0xb4866546 0x0017d907
+ 0x515dc2a5 0xf9fc5095 0x4d6ee0c9 0xb67d219d 0xfb708535
+ 0x1d01d6d1>;
+ phandle = <0x100000fd>;
+ linux,phandle = <0x100000fd>;
+ };
@@ -0,0 +1,89 @@+# SPDX-License-Identifier: GPL-2.0+*** NOTE ***+This document is copied from OPAL firmware+(skiboot/doc/device-tree/secvar.rst)+************+.._device-tree/ibm,secureboot/secvar:++secvar+======++The ``secvar`` node provides secure variable information for the secure+boot of the target OS.++Required properties+-------------------++..code-block:: none++ compatible: this property is set based on the current secure+ variable scheme as set by the platform.++ status: set to "fail" if the secure variables could not+ be initialized, validated, or some other+ catastrophic failure.++ update-status: contains the return code of the update queue+ process run during initialization. Signifies if+ updates were processed or not, and if there was+ an error. See table below++ secure-mode: a u64 bitfield set by the backend to determine+ what secure mode we should be in, and if host+ secure boot should be enforced.++Example+-------++..code-block:: dts++ secvar {+ compatible = "ibm,edk2-compat-v1";+ status = "okay";+ secure-mode = "1";+ };++Update Status+-------------++The update status property should be set by the backend driver to a value+that best fits its error condtion. The following table defines the+general intent of each error code, check backend specific documentation+for more detail.+++-----------------+-----------------------------------------------++| update-status | Generic Reason |++-----------------|-----------------------------------------------++| OPAL_SUCCESS | Updates were found and processed successfully |++-----------------|-----------------------------------------------++| OPAL_EMPTY | No updates were found, none processed |++-----------------|-----------------------------------------------++| OPAL_PARAMETER | Unable to parse data in the update section |++-----------------|-----------------------------------------------++| OPAL_PERMISSION | Update failed to apply, possible auth failure |++-----------------|-----------------------------------------------++| OPAL_HARDWARE | Misc. storage-related error |++-----------------|-----------------------------------------------++| OPAL_RESOURCE | Out of space (somewhere) |++-----------------|-----------------------------------------------++| OPAL_NO_MEM | Out of memory |++-----------------+-----------------------------------------------+++Secure Mode+-----------+++-----------------------+------------------------++| backend specific-bits | generic mode bits |++-----------------------+------------------------++64 32 0++The secure mode property should be set by the backend driver. The least+significant 32 bits are reserved for generic modes, shared across all+possible backends. The other 32 bits are open for backends to determine+their own modes. Any kernel must be made aware of any custom modes.++At the moment, only one general-purpose bit is defined:++``#define SECVAR_SECURE_MODE_ENFORCING 0x1``++which signals that a kernel should enforce host secure boot.
@@ -0,0 +1,33 @@+// SPDX-License-Identifier: GPL-2.0+/*+*Copyright(C)2019IBMCorporation+*Author:NaynaJain+*/++#include<linux/ima.h>+#include<asm/secure_boot.h>++boolarch_ima_get_secureboot(void)+{+returnis_powerpc_os_secureboot_enabled();+}++/* Defines IMA appraise rules for secureboot */+staticconstchar*constarch_rules[]={+"appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig|modsig",+#if !IS_ENABLED(CONFIG_MODULE_SIG)+"appraise func=MODULE_CHECK appraise_type=imasig|modsig",+#endif+NULL+};++/*+*ReturnstherelevantIMAarchpoliciesbasedonthesystemsecurebootstate.+*/+constchar*const*arch_get_ima_policy(void)+{+if(is_powerpc_os_secureboot_enabled())+returnarch_rules;++returnNULL;+}
If CONFIG_MODULE_SIG is enabled but module signatures aren't enforced,
then IMA won't enforce module signature either. x86's
arch_get_ima_policy() calls set_module_sig_enforced(). Doesn't the
powerpc version need to do that as well?
On the flip side, if module signatures are enforced by the module
subsystem then IMA will verify the signature a second time since there's
no sharing of signature verification results between the module
subsystem and IMA (this was observed by Mimi).
IMHO this is a minor issue, since module loading isn't a hot path and
the duplicate work shouldn't impact anything. But it could be avoided by
having a NULL entry in arch_rules, which arch_get_ima_policy() would
dynamically update with the "appraise func=MODULE_CHECK" rule if
is_module_sig_enforced() is true.
Thanks Thiago for reviewing. I am wondering that this will give two
meanings for NULL. Can we do something like below, there are possibly
two options ?
1. Set IMA_APPRAISED in the iint->flags if is_module_sig_enforced().
OR
2. Let ima_get_action() check for is_module_sig_enforced() when policy
is appraise and func is MODULE_CHECK.
Thanks & Regards,
- Nayna
On Fri, Sep 27, 2019 at 10:25:52AM -0400, Nayna Jain wrote:
quoted
PowerNV represents both the firmware and Host OS secureboot state of the
system via device tree. This patch adds the documentation to give
the definition of the nodes and the properties.
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
---
.../bindings/powerpc/ibm,secureboot.rst | 76 ++++++++++++++++
.../devicetree/bindings/powerpc/secvar.rst | 89 +++++++++++++++++++
2 files changed, 165 insertions(+)
create mode 100644 Documentation/devicetree/bindings/powerpc/ibm,secureboot.rst
create mode 100644 Documentation/devicetree/bindings/powerpc/secvar.rst
+*** NOTE ***
+This document is copied from OPAL firmware
+(skiboot/doc/device-tree/ibm,secureboot.rst)
Why copy into the kernel?
Do you mean we do not need the device-tree documentation in the kernel
when it already exists in the skiboot tree ?
I think I am ok with that. Michael, what do you think ?
Thanks & Regards,
- Nayna
@@ -0,0 +1,33 @@+// SPDX-License-Identifier: GPL-2.0+/*+*Copyright(C)2019IBMCorporation+*Author:NaynaJain+*/++#include<linux/ima.h>+#include<asm/secure_boot.h>++boolarch_ima_get_secureboot(void)+{+returnis_powerpc_os_secureboot_enabled();+}++/* Defines IMA appraise rules for secureboot */+staticconstchar*constarch_rules[]={+"appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig|modsig",+#if !IS_ENABLED(CONFIG_MODULE_SIG)+"appraise func=MODULE_CHECK appraise_type=imasig|modsig",+#endif+NULL+};++/*+*ReturnstherelevantIMAarchpoliciesbasedonthesystemsecurebootstate.+*/+constchar*const*arch_get_ima_policy(void)+{+if(is_powerpc_os_secureboot_enabled())+returnarch_rules;++returnNULL;+}
If CONFIG_MODULE_SIG is enabled but module signatures aren't enforced,
then IMA won't enforce module signature either. x86's
arch_get_ima_policy() calls set_module_sig_enforced(). Doesn't the
powerpc version need to do that as well?
On the flip side, if module signatures are enforced by the module
subsystem then IMA will verify the signature a second time since there's
no sharing of signature verification results between the module
subsystem and IMA (this was observed by Mimi).
IMHO this is a minor issue, since module loading isn't a hot path and
the duplicate work shouldn't impact anything. But it could be avoided by
having a NULL entry in arch_rules, which arch_get_ima_policy() would
dynamically update with the "appraise func=MODULE_CHECK" rule if
is_module_sig_enforced() is true.
Thanks Thiago for reviewing. I am wondering that this will give two meanings
for NULL.
What are the two meanings? My understanding is that it only means "end
of array". The additional NULL just allows arch_get_ima_policy() to
dynamically append one item to the array.
But I hadn't thought of your other alternatives. They should work just
as well. Among those, I think option 1 is cleaner.
This addresses the second issue I mentioned, but not the first.
Also, one other thing I just noticed is that x86's arch policy has
measure rules but powerpc's policy doesn't. What is different in our
case?
Can we do something like below, there are possibly two options ?
1. Set IMA_APPRAISED in the iint->flags if is_module_sig_enforced().
OR
2. Let ima_get_action() check for is_module_sig_enforced() when policy is
appraise and func is MODULE_CHECK.
Thanks & Regards,
- Nayna
--
Thiago Jung Bauermann
IBM Linux Technology Center
On Fri, 2019-09-27 at 10:25 -0400, Nayna Jain wrote:
quoted hunk
Asymmetric private keys are used to sign multiple files. The kernel
currently support checking against the blacklisted keys. However, if the
public key is blacklisted, any file signed by the blacklisted key will
automatically fail signature verification. We might not want to blacklist
all the files signed by a particular key, but just a single file.
Blacklisting the public key is not fine enough granularity.
This patch adds support for blacklisting binaries with appended signatures,
based on the IMA policy. Defined is a new policy option
"appraise_flag=check_blacklist".
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
---
Documentation/ABI/testing/ima_policy | 1 +
security/integrity/ima/ima.h | 12 +++++++++
security/integrity/ima/ima_appraise.c | 35 +++++++++++++++++++++++++++
security/integrity/ima/ima_main.c | 8 ++++--
security/integrity/ima/ima_policy.c | 10 ++++++--
security/integrity/integrity.h | 1 +
6 files changed, 63 insertions(+), 4 deletions(-)
is_hash_blacklisted() returning -EKEYREJECTED makes sense if the key
is blacklisted, not so much for a binary. It would make more sense to
define is_binary_blacklisted(), as a wrapper for
is_hash_blacklisted().
For appended signatures, the IMA policy measurement rule would
normally be "template=ima-modsig". Shouldn't the "template_desc" for
blacklisted binaries be "template=ima-buf"?
process_measurement() calls a number of functions: ima_collect_measurement(), ima_store_measurement(), ima_appraise_measurement() and ima_audit_measurement(). The action is contained within the name (eg. collect, store, appraise, audit). "blacklist" implies the function is blacklisting a file hash, as opposed to checking whether the file hash is already black listed. Changing the tense from "blacklist" to "blacklisted" would help.
Renaming the function to "ima_is_binary_blacklisted" would be even better.
Mimi
Hi Nayna,
On Fri, 2019-09-27 at 10:25 -0400, Nayna Jain wrote:
This patch deprecates the existing permit_directio flag, instead adds
it as possible value to appraise_flag parameter.
For eg.
appraise_flag=permit_directio
Defining a generic "appraise_flag=", which supports different options,
is the right direction. I would really like to depreciate the
"permit_directio" flag, not just change the policy syntax. For now,
let's drop this change.
Mimi
@@ -0,0 +1,33 @@+// SPDX-License-Identifier: GPL-2.0+/*+*Copyright(C)2019IBMCorporation+*Author:NaynaJain+*/++#include<linux/ima.h>+#include<asm/secure_boot.h>++boolarch_ima_get_secureboot(void)+{+returnis_powerpc_os_secureboot_enabled();+}++/* Defines IMA appraise rules for secureboot */+staticconstchar*constarch_rules[]={+"appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig|modsig",+#if !IS_ENABLED(CONFIG_MODULE_SIG)+"appraise func=MODULE_CHECK appraise_type=imasig|modsig",+#endif+NULL+};++/*+*ReturnstherelevantIMAarchpoliciesbasedonthesystemsecurebootstate.+*/+constchar*const*arch_get_ima_policy(void)+{+if(is_powerpc_os_secureboot_enabled())+returnarch_rules;++returnNULL;+}
If CONFIG_MODULE_SIG is enabled but module signatures aren't enforced,
then IMA won't enforce module signature either. x86's
arch_get_ima_policy() calls set_module_sig_enforced(). Doesn't the
powerpc version need to do that as well?
On the flip side, if module signatures are enforced by the module
subsystem then IMA will verify the signature a second time since there's
no sharing of signature verification results between the module
subsystem and IMA (this was observed by Mimi).
IMHO this is a minor issue, since module loading isn't a hot path and
the duplicate work shouldn't impact anything. But it could be avoided by
having a NULL entry in arch_rules, which arch_get_ima_policy() would
dynamically update with the "appraise func=MODULE_CHECK" rule if
is_module_sig_enforced() is true.
Thanks Thiago for reviewing. I am wondering that this will give two
meanings for NULL. Can we do something like below, there are possibly
two options ?
1. Set IMA_APPRAISED in the iint->flags if is_module_sig_enforced().
OR
2. Let ima_get_action() check for is_module_sig_enforced() when policy
is appraise and func is MODULE_CHECK.
I'm a bit hesitant about mixing the module subsystem signature
verification method with the IMA measure "template=ima-modsig" rules.
Does it actually work?
We can at least limit verifying the same appended signature twice to
when "module.sig_enforce" is specified on the boot command line, by
changing "!IS_ENABLED(CONFIG_MODULE_SIG)" to test
"CONFIG_MODULE_SIG_FORCE".
Mimi
[Cc'ing Prakhar]
On Fri, 2019-09-27 at 10:25 -0400, Nayna Jain wrote:
To add the support for checking against blacklist, it would be needed
to add an additional measurement record that identifies the record
as blacklisted.
This patch modifies the process_buffer_measurement() and makes it
non static to be used by blacklist functionality. It modifies the
function to handle more than just the KEXEC_CMDLINE.
Signed-off-by: Nayna Jain <nayna@linux.ibm.com>
Making process_buffer_measurement() non static is the end result, not
the reason for the change. The reason for changing
process_buffer_measurement() is to make it more generic. The
blacklist measurement record is the usecase.
Please rewrite the patch description.
thanks,
Mimi
@@ -0,0 +1,33 @@+// SPDX-License-Identifier: GPL-2.0+/*+*Copyright(C)2019IBMCorporation+*Author:NaynaJain+*/++#include<linux/ima.h>+#include<asm/secure_boot.h>++boolarch_ima_get_secureboot(void)+{+returnis_powerpc_os_secureboot_enabled();+}++/* Defines IMA appraise rules for secureboot */+staticconstchar*constarch_rules[]={+"appraise func=KEXEC_KERNEL_CHECK appraise_type=imasig|modsig",+#if !IS_ENABLED(CONFIG_MODULE_SIG)+"appraise func=MODULE_CHECK appraise_type=imasig|modsig",+#endif+NULL+};++/*+*ReturnstherelevantIMAarchpoliciesbasedonthesystemsecurebootstate.+*/+constchar*const*arch_get_ima_policy(void)+{+if(is_powerpc_os_secureboot_enabled())+returnarch_rules;++returnNULL;+}
If CONFIG_MODULE_SIG is enabled but module signatures aren't enforced,
then IMA won't enforce module signature either. x86's
arch_get_ima_policy() calls set_module_sig_enforced(). Doesn't the
powerpc version need to do that as well?
On the flip side, if module signatures are enforced by the module
subsystem then IMA will verify the signature a second time since there's
no sharing of signature verification results between the module
subsystem and IMA (this was observed by Mimi).
IMHO this is a minor issue, since module loading isn't a hot path and
the duplicate work shouldn't impact anything. But it could be avoided by
having a NULL entry in arch_rules, which arch_get_ima_policy() would
dynamically update with the "appraise func=MODULE_CHECK" rule if
is_module_sig_enforced() is true.
Thanks Thiago for reviewing. I am wondering that this will give two
meanings for NULL. Can we do something like below, there are possibly
two options ?
1. Set IMA_APPRAISED in the iint->flags if is_module_sig_enforced().
OR
2. Let ima_get_action() check for is_module_sig_enforced() when policy
is appraise and func is MODULE_CHECK.
I'm a bit hesitant about mixing the module subsystem signature
verification method with the IMA measure "template=ima-modsig" rules.
Does it actually work?
We can at least limit verifying the same appended signature twice to
when "module.sig_enforce" is specified on the boot command line, by
changing "!IS_ENABLED(CONFIG_MODULE_SIG)" to test
"CONFIG_MODULE_SIG_FORCE".
Yes this seems to be a better idea. I have implemented this in the v7
version of the ima_arch version.
Thanks & Regards,
- Nayna