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 03/10] arm64: add sysfs vulnerability show for meltdown
Date: Fri, 1 Mar 2019 10:12:09 -0600 [thread overview]
Message-ID: <9cfb9cff-6a26-fff7-9374-82eea0f63a21@arm.com> (raw)
In-Reply-To: <c98ff98e-30e2-596b-39c5-8505ddef9496@foss.arm.com>
Hi,
On 3/1/19 1:11 AM, Andre Przywara wrote:
> Hi,
>
> On 2/26/19 7:05 PM, Jeremy Linton wrote:
>> Display the mitigation status if active, otherwise
>> assume the cpu is safe unless it doesn't have CSV3
>> and isn't in our whitelist.
>>
>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>> ---
>> arch/arm64/kernel/cpufeature.c | 47 ++++++++++++++++++++++++++--------
>> 1 file changed, 37 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/cpufeature.c
>> b/arch/arm64/kernel/cpufeature.c
>> index f6d84e2c92fe..d31bd770acba 100644
>> --- a/arch/arm64/kernel/cpufeature.c
>> +++ b/arch/arm64/kernel/cpufeature.c
>> @@ -944,7 +944,7 @@ has_useable_cnp(const struct
>> arm64_cpu_capabilities *entry, int scope)
>> return has_cpuid_feature(entry, scope);
>> }
>> -#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
>> +static bool __meltdown_safe = true;
>> static int __kpti_forced; /* 0: not forced, >0: forced on, <0:
>> forced off */
>> static bool unmap_kernel_at_el0(const struct arm64_cpu_capabilities
>> *entry,
>> @@ -963,6 +963,16 @@ static bool unmap_kernel_at_el0(const struct
>> arm64_cpu_capabilities *entry,
>> { /* sentinel */ }
>> };
>> char const *str = "command line option";
>> + bool meltdown_safe;
>> +
>> + meltdown_safe = is_midr_in_range_list(read_cpuid_id(),
>> kpti_safe_list);
>> +
>> + /* Defer to CPU feature registers */
>> + if (has_cpuid_feature(entry, scope))
>> + meltdown_safe = true;
>> +
>> + if (!meltdown_safe)
>> + __meltdown_safe = false;
>> /*
>> * For reasons that aren't entirely clear, enabling KPTI on Cavium
>> @@ -974,6 +984,11 @@ static bool unmap_kernel_at_el0(const struct
>> arm64_cpu_capabilities *entry,
>> __kpti_forced = -1;
>> }
>> + if (!IS_ENABLED(CONFIG_UNMAP_KERNEL_AT_EL0)) {
>> + pr_info_once("kernel page table isolation disabled by
>> CONFIG\n");
>> + return false;
>> + }
>> +
>> /* Forced? */
>> if (__kpti_forced) {
>> pr_info_once("kernel page table isolation forced %s by %s\n",
>> @@ -985,14 +1000,10 @@ static bool unmap_kernel_at_el0(const struct
>> arm64_cpu_capabilities *entry,
>> if (IS_ENABLED(CONFIG_RANDOMIZE_BASE))
>> return kaslr_offset() > 0;
>> - /* Don't force KPTI for CPUs that are not vulnerable */
>> - if (is_midr_in_range_list(read_cpuid_id(), kpti_safe_list))
>> - return false;
>> -
>> - /* Defer to CPU feature registers */
>> - return !has_cpuid_feature(entry, scope);
>> + return !meltdown_safe;
>> }
>> +#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
>> static void
>> kpti_install_ng_mappings(const struct arm64_cpu_capabilities *__unused)
>> {
>> @@ -1022,6 +1033,13 @@ kpti_install_ng_mappings(const struct
>> arm64_cpu_capabilities *__unused)
>> return;
>> }
>> +#else
>> +static void
>> +kpti_install_ng_mappings(const struct arm64_cpu_capabilities *__unused)
>> +{
>> +}
>> +#endif /* CONFIG_UNMAP_KERNEL_AT_EL0 */
>> +
>> static int __init parse_kpti(char *str)
>> {
>> @@ -1035,7 +1053,6 @@ static int __init parse_kpti(char *str)
>> return 0;
>> }
>> early_param("kpti", parse_kpti);
>> -#endif /* CONFIG_UNMAP_KERNEL_AT_EL0 */
>> #ifdef CONFIG_ARM64_HW_AFDBM
>> static inline void __cpu_enable_hw_dbm(void)
>> @@ -1286,7 +1303,6 @@ static const struct arm64_cpu_capabilities
>> arm64_features[] = {
>> .field_pos = ID_AA64PFR0_EL0_SHIFT,
>> .min_field_value = ID_AA64PFR0_EL0_32BIT_64BIT,
>> },
>> -#ifdef CONFIG_UNMAP_KERNEL_AT_EL0
>> {
>> .desc = "Kernel page table isolation (KPTI)",
>> .capability = ARM64_UNMAP_KERNEL_AT_EL0,
>> @@ -1302,7 +1318,6 @@ static const struct arm64_cpu_capabilities
>> arm64_features[] = {
>> .matches = unmap_kernel_at_el0,
>> .cpu_enable = kpti_install_ng_mappings,
>> },
>> -#endif
>> {
>> /* FP/SIMD is not implemented */
>> .capability = ARM64_HAS_NO_FPSIMD,
>> @@ -2063,3 +2078,15 @@ static int __init enable_mrs_emulation(void)
>> }
>> core_initcall(enable_mrs_emulation);
>> +
>> +ssize_t cpu_show_meltdown(struct device *dev, struct device_attribute
>> *attr,
>> + char *buf)
>> +{
>> + if (arm64_kernel_unmapped_at_el0())
>> + return sprintf(buf, "Mitigation: KPTI\n");
>> +
>> + if (__meltdown_safe)
>> + return sprintf(buf, "Not affected\n");
>
> Shall those two checks be swapped? So it doesn't report about a KPTI
> mitigation if the CPU is safe, but we enable KPTI because of KASLR
> having enabled it? Or is that a different knob?
Hmmm, I think having it this way reflects the fact that the machine is
mitigated independent of whether it needed it. The force on case is
similar. The machine may not have needed the mitigation but it was
forced on.
>
> Cheers,
> Andre.
>
>> +
>> + return sprintf(buf, "Vulnerable\n");
>> +}
>>
next prev parent reply other threads:[~2019-03-01 16:12 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 [this message]
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
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=9cfb9cff-6a26-fff7-9374-82eea0f63a21@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®