From: Jeremy Linton <jeremy.linton@arm.com>
To: Andre Przywara <andre.przywara@arm.com>,
linux-arm-kernel@lists.infradead.org
Cc: catalin.marinas@arm.com, will.deacon@arm.com,
marc.zyngier@arm.com, suzuki.poulose@arm.com,
Dave.Martin@arm.com, shankerd@codeaurora.org,
julien.thierry@arm.com, mlangsdo@redhat.com,
stefan.wahren@i2e.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 08/10] arm64: Always enable ssb vulnerability detection
Date: Fri, 1 Mar 2019 10:16:41 -0600 [thread overview]
Message-ID: <1b07e031-6b82-2a9e-9c0e-0617685b9ef3@arm.com> (raw)
In-Reply-To: <5c76075d-1889-ff75-0567-f3e2df7079f4@foss.arm.com>
On 3/1/19 1:02 AM, Andre Przywara wrote:
> Hi,
>
> On 2/26/19 7:05 PM, Jeremy Linton wrote:
>> The ssb detection logic is necessary regardless of whether
>> the vulnerability mitigation code is built into the kernel.
>> Break it out so that the CONFIG option only controls the
>> mitigation logic and not the vulnerability detection.
>>
>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>> ---
>> arch/arm64/include/asm/cpufeature.h | 4 ----
>> arch/arm64/kernel/cpu_errata.c | 11 +++++++----
>> 2 files changed, 7 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/cpufeature.h
>> b/arch/arm64/include/asm/cpufeature.h
>> index dfcfba725d72..c2b60a021437 100644
>> --- a/arch/arm64/include/asm/cpufeature.h
>> +++ b/arch/arm64/include/asm/cpufeature.h
>> @@ -628,11 +628,7 @@ static inline int arm64_get_ssbd_state(void)
>> #endif
>> }
>> -#ifdef CONFIG_ARM64_SSBD
>> void arm64_set_ssbd_mitigation(bool state);
>> -#else
>> -static inline void arm64_set_ssbd_mitigation(bool state) {}
>> -#endif
>> extern int do_emulate_mrs(struct pt_regs *regs, u32 sys_reg, u32 rt);
>> diff --git a/arch/arm64/kernel/cpu_errata.c
>> b/arch/arm64/kernel/cpu_errata.c
>> index 0f6e8f5d67bc..5f5611d17dc1 100644
>> --- a/arch/arm64/kernel/cpu_errata.c
>> +++ b/arch/arm64/kernel/cpu_errata.c
>> @@ -276,7 +276,6 @@ static int detect_harden_bp_fw(void)
>> return 1;
>> }
>> -#ifdef CONFIG_ARM64_SSBD
>> DEFINE_PER_CPU_READ_MOSTLY(u64, arm64_ssbd_callback_required);
>> int ssbd_state __read_mostly = ARM64_SSBD_KERNEL;
>> @@ -347,6 +346,7 @@ void __init arm64_enable_wa2_handling(struct
>> alt_instr *alt,
>> *updptr = cpu_to_le32(aarch64_insn_gen_nop());
>> }
>> +#ifdef CONFIG_ARM64_SSBD
>> void arm64_set_ssbd_mitigation(bool state)
>> {
>> if (this_cpu_has_cap(ARM64_SSBS)) {
>> @@ -371,6 +371,12 @@ void arm64_set_ssbd_mitigation(bool state)
>> break;
>> }
>> }
>> +#else
>> +void arm64_set_ssbd_mitigation(bool state)
>> +{
>> + pr_info_once("SSBD, disabled by kernel configuration\n");
>
> Is there a stray comma or is the continuation of some previous printout?
This is on purpose because I didn't like the way it read if you expanded
the acronym. I still don't, maybe a ":" is more appropriate.
>
> Regardless of that it looks good and compiles with both
> CONFIG_ARM64_SSBD defined or not:
>
> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
>
> Cheers,
> Andre.
>
>> +}
>> +#endif /* CONFIG_ARM64_SSBD */
>> static bool has_ssbd_mitigation(const struct arm64_cpu_capabilities
>> *entry,
>> int scope)
>> @@ -468,7 +474,6 @@ static bool has_ssbd_mitigation(const struct
>> arm64_cpu_capabilities *entry,
>> return required;
>> }
>> -#endif /* CONFIG_ARM64_SSBD */
>> static void __maybe_unused
>> cpu_enable_cache_maint_trap(const struct arm64_cpu_capabilities
>> *__unused)
>> @@ -760,14 +765,12 @@ const struct arm64_cpu_capabilities
>> arm64_errata[] = {
>> ERRATA_MIDR_RANGE_LIST(arm64_harden_el2_vectors),
>> },
>> #endif
>> -#ifdef CONFIG_ARM64_SSBD
>> {
>> .desc = "Speculative Store Bypass Disable",
>> .capability = ARM64_SSBD,
>> .type = ARM64_CPUCAP_LOCAL_CPU_ERRATUM,
>> .matches = has_ssbd_mitigation,
>> },
>> -#endif
>> #ifdef CONFIG_ARM64_ERRATUM_1188873
>> {
>> /* Cortex-A76 r0p0 to r2p0 */
>>
next prev parent reply other threads:[~2019-03-01 16:16 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-27 1:05 [PATCH v5 00/10] arm64: add system vulnerability sysfs entries Jeremy Linton
2019-02-27 1:05 ` [PATCH v5 01/10] arm64: Provide a command line to disable spectre_v2 mitigation Jeremy Linton
2019-02-28 18:14 ` Suzuki K Poulose
2019-02-28 18:21 ` Catalin Marinas
2019-02-28 18:25 ` Suzuki K Poulose
2019-03-01 6:54 ` Andre Przywara
2019-02-27 1:05 ` [PATCH v5 02/10] arm64: add sysfs vulnerability show for spectre v1 Jeremy Linton
2019-02-28 18:29 ` Suzuki K Poulose
2019-03-01 6:54 ` Andre Przywara
2019-02-27 1:05 ` [PATCH v5 03/10] arm64: add sysfs vulnerability show for meltdown Jeremy Linton
2019-02-28 18:33 ` Suzuki K Poulose
2019-03-01 7:11 ` Andre Przywara
2019-03-01 16:12 ` Jeremy Linton
2019-03-01 16:20 ` Catalin Marinas
2019-03-01 16:53 ` Jeremy Linton
2019-03-01 17:15 ` Catalin Marinas
2019-03-01 17:30 ` Andre Przywara
2019-02-27 1:05 ` [PATCH v5 04/10] arm64: Advertise mitigation of Spectre-v2, or lack thereof Jeremy Linton
2019-03-01 6:57 ` Andre Przywara
2019-02-27 1:05 ` [PATCH v5 05/10] arm64: Use firmware to detect CPUs that are not affected by Spectre-v2 Jeremy Linton
2019-03-01 6:58 ` Andre Przywara
2019-02-27 1:05 ` [PATCH v5 06/10] arm64: Always enable spectrev2 vulnerability detection Jeremy Linton
2019-03-01 6:58 ` Andre Przywara
2019-02-27 1:05 ` [PATCH v5 07/10] arm64: add sysfs vulnerability show for spectre v2 Jeremy Linton
2019-03-01 6:59 ` Andre Przywara
2019-02-27 1:05 ` [PATCH v5 08/10] arm64: Always enable ssb vulnerability detection Jeremy Linton
2019-03-01 7:02 ` Andre Przywara
2019-03-01 16:16 ` Jeremy Linton [this message]
2019-02-27 1:05 ` [PATCH v5 09/10] arm64: add sysfs vulnerability show for speculative store bypass Jeremy Linton
2019-03-01 7:02 ` Andre Przywara
2019-03-01 16:41 ` Jeremy Linton
2019-02-27 1:05 ` [PATCH v5 10/10] arm64: enable generic CPU vulnerabilites support Jeremy Linton
2019-03-01 7:03 ` Andre Przywara
2019-02-28 12:01 ` [PATCH v5 00/10] arm64: add system vulnerability sysfs entries Catalin Marinas
2019-03-01 19:35 ` Stefan Wahren
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=1b07e031-6b82-2a9e-9c0e-0617685b9ef3@arm.com \
--to=jeremy.linton@arm.com \
--cc=Dave.Martin@arm.com \
--cc=andre.przywara@arm.com \
--cc=catalin.marinas@arm.com \
--cc=julien.thierry@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=mlangsdo@redhat.com \
--cc=shankerd@codeaurora.org \
--cc=stefan.wahren@i2e.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
all inboxes | Powered by JetHome®