From: Marc Zyngier <marc.zyngier@arm.com>
To: Suzuki K Poulose <suzuki.poulose@arm.com>, will.deacon@arm.com
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, lorenzo.pieralisi@arm.com,
catalin.marinas@arm.com, mark.rutland@arm.com,
ard.biesheuvel@linaro.org, shankerd@codeaurora.org,
christoffer.dall@linaro.org, jnair@caviumnetworks.com
Subject: Re: [PATCH v3 11/13] arm64: Implement branch predictor hardening for affected Cortex-A CPUs
Date: Mon, 15 Jan 2018 11:51:34 +0000 [thread overview]
Message-ID: <0baae1c1-8ea8-e01d-ff16-aabae36f8ee5@arm.com> (raw)
In-Reply-To: <20180109161218.2079-1-suzuki.poulose@arm.com>
Hi Suzuki,
On 09/01/18 16:12, Suzuki K Poulose wrote:
> On 08/01/18 17:32, Will Deacon wrote:
>> Cortex-A57, A72, A73 and A75 are susceptible to branch predictor aliasing
>> and can theoretically be attacked by malicious code.
>>
>> This patch implements a PSCI-based mitigation for these CPUs when available.
>> The call into firmware will invalidate the branch predictor state, preventing
>> any malicious entries from affecting other victim contexts.
>>
>> Co-developed-by: Marc Zyngier <marc.zyngier@arm.com>
>> Signed-off-by: Will Deacon <will.deacon@arm.com>
>
> Will, Marc,
>
>> +#ifdef CONFIG_HARDEN_BRANCH_PREDICTOR
>> + {
>> + .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
>> + MIDR_ALL_VERSIONS(MIDR_CORTEX_A57),
>> + .enable = enable_psci_bp_hardening,
>> + },
>> + {
>> + .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
>> + MIDR_ALL_VERSIONS(MIDR_CORTEX_A72),
>> + .enable = enable_psci_bp_hardening,
>> + },
>> + {
>> + .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
>> + MIDR_ALL_VERSIONS(MIDR_CORTEX_A73),
>> + .enable = enable_psci_bp_hardening,
>> + },
>> + {
>> + .capability = ARM64_HARDEN_BRANCH_PREDICTOR,
>> + MIDR_ALL_VERSIONS(MIDR_CORTEX_A75),
>> + .enable = enable_psci_bp_hardening,
>> + },
>> +#endif
>
> The introduction of multiple entries for the same capability breaks
> some assumptions in this_cpu_has_caps() and verify_local_cpu_features()
> as they all stop at the first entry matching the "capability" and could
> return wrong results. We need something like the following to make this
> work, should someone add duplicate feature entry or use
> this_cpu_has_caps() on one of the errata.
>
> ---8>---
>
> arm64: capabilities: Handle duplicate entries for a capability
>
> Sometimes a single capability could be listed multiple times with
> differing matches(), e.g, CPU errata for different MIDR versions.
> This breaks verify_local_cpu_feature() and this_cpu_has_cap() as
> we stop checking for a capability on a CPU with the first
> entry in the given table, which is not sufficient. Make sure we
> run the checks for all entries of the same capability. We do
> this by fixing __this_cpu_has_cap() to run through all the
> entries in the given table for a match and reuse it for
> verify_local_cpu_feature().
>
> Cc: Mark Rutland <mark.rutland@arm.com>
> Cc: Will Deacon <will.deacon@arm.com>
> Cc: Marc Zyngier <marc.zyngier@arm.com>
> Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
> ---
> arch/arm64/kernel/cpufeature.c | 44 ++++++++++++++++++++++--------------------
> 1 file changed, 23 insertions(+), 21 deletions(-)
>
> diff --git a/arch/arm64/kernel/cpufeature.c b/arch/arm64/kernel/cpufeature.c
> index 862a417ca0e2..0c43447f7406 100644
> --- a/arch/arm64/kernel/cpufeature.c
> +++ b/arch/arm64/kernel/cpufeature.c
> @@ -1120,6 +1120,26 @@ static void __init setup_elf_hwcaps(const struct arm64_cpu_capabilities *hwcaps)
> cap_set_elf_hwcap(hwcaps);
> }
>
> +/*
> + * Check if the current CPU has a given feature capability.
> + * Should be called from non-preemptible context.
> + */
> +static bool __this_cpu_has_cap(const struct arm64_cpu_capabilities *cap_array,
> + unsigned int cap)
> +{
> + const struct arm64_cpu_capabilities *caps;
> +
> + if (WARN_ON(preemptible()))
> + return false;
> +
> + for (caps = cap_array; caps->desc; caps++)
> + if (caps->capability == cap &&
> + caps->matches &&
> + caps->matches(caps, SCOPE_LOCAL_CPU))
> + return true;
> + return false;
> +}
> +
> void update_cpu_capabilities(const struct arm64_cpu_capabilities *caps,
> const char *info)
> {
> @@ -1183,8 +1203,9 @@ verify_local_elf_hwcaps(const struct arm64_cpu_capabilities *caps)
> }
>
> static void
> -verify_local_cpu_features(const struct arm64_cpu_capabilities *caps)
> +verify_local_cpu_features(const struct arm64_cpu_capabilities *caps_list)
> {
> + const struct arm64_cpu_capabilities *caps = caps_list;
> for (; caps->matches; caps++) {
> if (!cpus_have_cap(caps->capability))
> continue;
> @@ -1192,7 +1213,7 @@ verify_local_cpu_features(const struct arm64_cpu_capabilities *caps)
> * If the new CPU misses an advertised feature, we cannot proceed
> * further, park the cpu.
> */
> - if (!caps->matches(caps, SCOPE_LOCAL_CPU)) {
> + if (!__this_cpu_has_cap(caps_list, caps->capability)) {
> pr_crit("CPU%d: missing feature: %s\n",
> smp_processor_id(), caps->desc);
> cpu_die_early();
> @@ -1274,25 +1295,6 @@ static void __init mark_const_caps_ready(void)
> static_branch_enable(&arm64_const_caps_ready);
> }
>
> -/*
> - * Check if the current CPU has a given feature capability.
> - * Should be called from non-preemptible context.
> - */
> -static bool __this_cpu_has_cap(const struct arm64_cpu_capabilities *cap_array,
> - unsigned int cap)
> -{
> - const struct arm64_cpu_capabilities *caps;
> -
> - if (WARN_ON(preemptible()))
> - return false;
> -
> - for (caps = cap_array; caps->desc; caps++)
> - if (caps->capability == cap && caps->matches)
> - return caps->matches(caps, SCOPE_LOCAL_CPU);
> -
> - return false;
> -}
> -
> extern const struct arm64_cpu_capabilities arm64_errata[];
>
> bool this_cpu_has_cap(unsigned int cap)
>
This looks sensible to me.
Acked-by: Marc Zyngier <marc.zyngier@arm.com>
M.
--
Jazz is not dead. It just smells funny...
next prev parent reply other threads:[~2018-01-15 11:51 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-08 17:32 [PATCH v3 00/13] arm64 kpti hardening and variant 2 workarounds Will Deacon
2018-01-08 17:32 ` [PATCH v3 01/13] arm64: use RET instruction for exiting the trampoline Will Deacon
2018-01-08 17:32 ` [PATCH v3 02/13] arm64: Kconfig: Reword UNMAP_KERNEL_AT_EL0 kconfig entry Will Deacon
2018-01-09 17:17 ` Christoph Hellwig
2018-01-10 19:26 ` Will Deacon
2018-01-08 17:32 ` [PATCH v3 03/13] arm64: Take into account ID_AA64PFR0_EL1.CSV3 Will Deacon
2018-01-08 17:32 ` [PATCH v3 04/13] arm64: cpufeature: Pass capability structure to ->enable callback Will Deacon
2018-01-08 17:32 ` [PATCH v3 05/13] drivers/firmware: Expose psci_get_version through psci_ops structure Will Deacon
2018-01-08 17:32 ` [PATCH v3 06/13] arm64: Move post_ttbr_update_workaround to C code Will Deacon
2018-01-08 17:32 ` [PATCH v3 07/13] arm64: Add skeleton to harden the branch predictor against aliasing attacks Will Deacon
2018-01-09 12:55 ` Philippe Ombredanne
2018-01-08 17:32 ` [PATCH v3 08/13] arm64: KVM: Use per-CPU vector when BP hardening is enabled Will Deacon
2018-01-08 17:32 ` [PATCH v3 09/13] arm64: KVM: Make PSCI_VERSION a fast path Will Deacon
2018-01-08 17:32 ` [PATCH v3 10/13] arm64: cputype: Add missing MIDR values for Cortex-A72 and Cortex-A75 Will Deacon
2018-01-08 17:32 ` [PATCH v3 11/13] arm64: Implement branch predictor hardening for affected Cortex-A CPUs Will Deacon
2018-01-09 16:12 ` Suzuki K Poulose
2018-01-15 11:51 ` Marc Zyngier [this message]
2018-01-15 18:01 ` Catalin Marinas
2018-01-08 17:32 ` [PATCH v3 12/13] arm64: Implement branch predictor hardening for Falkor Will Deacon
2018-01-12 17:58 ` Shanker Donthineni
2018-01-08 17:32 ` [PATCH v3 13/13] arm64: cputype: Add MIDR values for Cavium ThunderX2 CPUs Will Deacon
2018-01-08 18:53 ` [PATCH v3 00/13] arm64 kpti hardening and variant 2 workarounds Catalin Marinas
2018-01-09 14:07 ` Matthias Brugger
2018-01-12 15:58 ` Catalin Marinas
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=0baae1c1-8ea8-e01d-ff16-aabae36f8ee5@arm.com \
--to=marc.zyngier@arm.com \
--cc=ard.biesheuvel@linaro.org \
--cc=catalin.marinas@arm.com \
--cc=christoffer.dall@linaro.org \
--cc=jnair@caviumnetworks.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lorenzo.pieralisi@arm.com \
--cc=mark.rutland@arm.com \
--cc=shankerd@codeaurora.org \
--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
Powered by JetHome