From: Kees Cook <keescook@chromium.org>
To: Kristina Martsenko <kristina.martsenko@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Will Deacon <will.deacon@arm.com>,
Ramana Radhakrishnan <ramana.radhakrishnan@arm.com>,
Amit Kachhap <Amit.Kachhap@arm.com>,
Dave Martin <Dave.Martin@arm.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: [RFC v2 3/7] arm64: cpufeature: handle conflicts based on capability
Date: Wed, 29 May 2019 19:49:25 -0700 [thread overview]
Message-ID: <201905291948.295007E00@keescook> (raw)
In-Reply-To: <20190529190332.29753-4-kristina.martsenko@arm.com>
On Wed, May 29, 2019 at 08:03:28PM +0100, Kristina Martsenko wrote:
> 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 <kristina.martsenko@arm.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
-Kees
> ---
>
> 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)
>
> struct arm64_cpu_capabilities {
> const char *desc;
> @@ -354,6 +361,12 @@ cpucap_late_cpu_permitted(const struct arm64_cpu_capabilities *cap)
> return !!(cap->type & ARM64_CPUCAP_PERMITTED_FOR_LATE_CPU);
> }
>
> +static inline bool
> +cpucap_panic_on_conflict(const struct arm64_cpu_capabilities *cap)
> +{
> + return !!(cap->type & ARM64_CPUCAP_PANIC_ON_CONFLICT);
> +}
> +
> /*
> * Generic helper for handling capabilties with multiple (match,enable) pairs
> * of call backs, sharing the same capability bit.
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 166584deaed2..8a595b4cb0aa 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -1796,10 +1796,8 @@ static void __init enable_cpu_capabilities(u16 scope_mask)
> * Run through the list of capabilities to check for conflicts.
> * If the system has already detected a capability, take necessary
> * action on this CPU.
> - *
> - * Returns "false" on conflicts.
> */
> -static bool verify_local_cpu_caps(u16 scope_mask)
> +static void verify_local_cpu_caps(u16 scope_mask)
> {
> int i;
> bool cpu_has_cap, system_has_cap;
> @@ -1844,10 +1842,12 @@ static bool verify_local_cpu_caps(u16 scope_mask)
> pr_crit("CPU%d: Detected conflict for capability %d (%s), System: %d, CPU: %d\n",
> smp_processor_id(), caps->capability,
> caps->desc, system_has_cap, cpu_has_cap);
> - return false;
> - }
>
> - return true;
> + if (cpucap_panic_on_conflict(caps))
> + cpu_panic_kernel();
> + else
> + cpu_die_early();
> + }
> }
>
> /*
> @@ -1857,12 +1857,8 @@ static bool verify_local_cpu_caps(u16 scope_mask)
> static void check_early_cpu_features(void)
> {
> verify_cpu_asid_bits();
> - /*
> - * Early features are used by the kernel already. If there
> - * is a conflict, we cannot proceed further.
> - */
> - if (!verify_local_cpu_caps(SCOPE_BOOT_CPU))
> - cpu_panic_kernel();
> +
> + verify_local_cpu_caps(SCOPE_BOOT_CPU);
> }
>
> static void
> @@ -1910,8 +1906,7 @@ static void verify_local_cpu_capabilities(void)
> * check_early_cpu_features(), as they need to be verified
> * on all secondary CPUs.
> */
> - if (!verify_local_cpu_caps(SCOPE_ALL & ~SCOPE_BOOT_CPU))
> - cpu_die_early();
> + verify_local_cpu_caps(SCOPE_ALL & ~SCOPE_BOOT_CPU);
>
> verify_local_elf_hwcaps(arm64_elf_hwcaps);
>
> --
> 2.11.0
>
--
Kees Cook
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-05-30 2:49 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-05-29 19:03 [RFC v2 0/7] arm64: return address signing Kristina Martsenko
2019-05-29 19:03 ` [RFC v2 1/7] arm64: cpufeature: add pointer auth meta-capabilities Kristina Martsenko
2019-05-30 1:58 ` Kees Cook
2019-05-30 10:50 ` Suzuki K Poulose
2019-06-13 16:13 ` Suzuki K Poulose
2019-05-29 19:03 ` [RFC v2 2/7] arm64: install user ptrauth keys at kernel exit time Kristina Martsenko
2019-05-30 2:04 ` Kees Cook
2019-06-06 16:26 ` Catalin Marinas
2019-05-29 19:03 ` [RFC v2 3/7] arm64: cpufeature: handle conflicts based on capability Kristina Martsenko
2019-05-30 2:49 ` Kees Cook [this message]
2019-05-30 14:16 ` Suzuki K Poulose
2019-05-31 14:00 ` Kristina Martsenko
2019-05-31 15:08 ` Suzuki K Poulose
2019-05-29 19:03 ` [RFC v2 4/7] arm64: enable ptrauth earlier Kristina Martsenko
2019-05-30 3:11 ` Kees Cook
2019-06-13 15:41 ` Suzuki K Poulose
2019-05-29 19:03 ` [RFC v2 5/7] arm64: initialize and switch ptrauth kernel keys Kristina Martsenko
2019-05-30 3:34 ` Kees Cook
2019-05-30 16:26 ` Kristina Martsenko
2019-06-04 10:03 ` Dave Martin
2019-06-06 16:44 ` Catalin Marinas
2019-06-12 16:21 ` Kristina Martsenko
2019-06-13 10:44 ` Catalin Marinas
2019-05-29 19:03 ` [RFC v2 6/7] arm64: unwind: strip PAC from kernel addresses Kristina Martsenko
2019-05-30 3:36 ` Kees Cook
2019-05-29 19:03 ` [RFC v2 7/7] arm64: compile the kernel with ptrauth return address signing Kristina Martsenko
2019-05-30 3:45 ` Kees Cook
2019-05-30 3:09 ` [RFC v2 0/7] arm64: " Kees Cook
2019-05-30 7:25 ` Will Deacon
2019-05-30 8:39 ` Ard Biesheuvel
2019-05-30 9:11 ` Ramana Radhakrishnan
2019-05-30 9:12 ` Ramana Radhakrishnan
2019-06-06 17:44 ` Kristina Martsenko
2019-06-08 4:09 ` Kees Cook
[not found] ` <DB7PR08MB3865C4AA36C9C465B2A687DABF180@DB7PR08MB3865.eurprd08.prod.outlook.com>
2019-05-30 15:57 ` Kees Cook
[not found] ` <DB7PR08MB3865A83066179CE419D171EDBF180@DB7PR08MB3865.eurprd08.prod.outlook.com>
2019-05-30 18:05 ` Kees Cook
2019-05-31 9:22 ` Will Deacon
2019-06-02 15:43 ` Kees Cook
2019-06-03 10:40 ` Will Deacon
2019-06-04 13:52 ` Luke Cheeseman
2019-06-06 17:43 ` Kristina Martsenko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201905291948.295007E00@keescook \
--to=keescook@chromium.org \
--cc=Amit.Kachhap@arm.com \
--cc=Dave.Martin@arm.com \
--cc=ard.biesheuvel@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=kristina.martsenko@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=ramana.radhakrishnan@arm.com \
--cc=suzuki.poulose@arm.com \
--cc=will.deacon@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox