Thread (34 messages) 34 messages, 8 authors, 2019-06-13

Re: [RFC v2 3/7] arm64: cpufeature: handle conflicts based on capability

From: Kristina Martsenko <hidden>
Date: 2019-05-31 14:00:52

On 30/05/2019 15:16, Suzuki K Poulose wrote:
On 05/29/2019 08:03 PM, Kristina Martsenko wrote:
quoted
Each system capability can be of either boot, local, or system scope,
depending on when the state of the capability is finalized. When we
detect a conflict on a late CPU, we either offline the CPU or panic the
system. We currently always panic if the conflict is caused by a boot
scope capability, and offline the CPU if the conflict is caused by a
local or system scope capability.

We're going to want to add new capability (for pointer authentication)
which needs to be boot scope but doesn't need to panic the system when a
conflict is detected. So add a new flag to specify whether the
capability requires the system to panic or not. Current boot scope
capabilities are updated to set the flag, so there should be no
functional change as a result of this patch.

Signed-off-by: Kristina Martsenko <redacted>
quoted
---

Changes since RFC v1:
  - New patch, to have ptrauth mismatches disable secondaries instead of
    panicking

  arch/arm64/include/asm/cpufeature.h | 15 ++++++++++++++-
  arch/arm64/kernel/cpufeature.c      | 23 +++++++++--------------
  2 files changed, 23 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/include/asm/cpufeature.h b/arch/arm64/include/asm/cpufeature.h
index 0522ea674253..ad952f2e0a2b 100644
--- a/arch/arm64/include/asm/cpufeature.h
+++ b/arch/arm64/include/asm/cpufeature.h
@@ -217,6 +217,10 @@ extern struct arm64_ftr_reg arm64_ftr_reg_ctrel0;
   *     In some non-typical cases either both (a) and (b), or neither,
   *     should be permitted. This can be described by including neither
   *     or both flags in the capability's type field.
+ *
+ *     In case of a conflict, the CPU is prevented from booting. If the
+ *     ARM64_CPUCAP_PANIC_ON_CONFLICT flag is specified for the capability,
+ *     then a kernel panic is triggered.
   */
    @@ -249,6 +253,8 @@ extern struct arm64_ftr_reg arm64_ftr_reg_ctrel0;
  #define ARM64_CPUCAP_PERMITTED_FOR_LATE_CPU    ((u16)BIT(4))
  /* Is it safe for a late CPU to miss this capability when system has it */
  #define ARM64_CPUCAP_OPTIONAL_FOR_LATE_CPU    ((u16)BIT(5))
+/* Panic when a conflict is detected */
+#define ARM64_CPUCAP_PANIC_ON_CONFLICT        ((u16)BIT(6))
    /*
   * CPU errata workarounds that need to be enabled at boot time if one or
@@ -290,7 +296,8 @@ extern struct arm64_ftr_reg arm64_ftr_reg_ctrel0;
   * CPU feature used early in the boot based on the boot CPU. All secondary
   * CPUs must match the state of the capability as detected by the boot CPU.
   */
-#define ARM64_CPUCAP_STRICT_BOOT_CPU_FEATURE ARM64_CPUCAP_SCOPE_BOOT_CPU
+#define ARM64_CPUCAP_STRICT_BOOT_CPU_FEATURE        \
+    (ARM64_CPUCAP_SCOPE_BOOT_CPU | ARM64_CPUCAP_PANIC_ON_CONFLICT)
You may want to update the comment to mention that a conflict triggers
kernel panic, as it is more within the control of the "cap" behavior.
Do you mean to update the comment above ARM64_CPUCAP_STRICT_BOOT_CPU_FEATURE?
To something like the following?

/*
 * CPU feature used early in the boot based on the boot CPU. All secondary
 * CPUs must match the state of the capability as detected by the boot CPU. In
 * case of a conflict, a kernel panic is triggered.
 */
With that:

Reviewed-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Thanks!

Kristina

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help