[v3,0/7] arm64: add system vulnerability sysfs entries

Message

Jeremy Linton Jan. 9, 2019, 11:55 p.m. UTC

Arm64 machines should be displaying a human readable
vulnerability status to speculative execution attacks in
/sys/devices/system/cpu/vulnerabilities 

This series enables that behavior by providing the expected
functions. Those functions expose the cpu errata and feature
states, as well as whether firmware is responding appropriately
to display the overall machine status. This means that in a
heterogeneous machine we will only claim the machine is mitigated
or safe if we are confident all booted cores are safe or
mitigated.

v2->v3:
	Remove "Unknown" states, replace with further blacklists
	       and default vulnerable/no affected states.
	Add the ability for an arch port to selectively export
	       sysfs vulnerabilities.

v1->v2:
	Add "Unknown" state to ABI/testing docs.
	Minor tweaks.
	
Jeremy Linton (4):
  sysfs/cpu: Allow individual architectures to select vulnerabilities
  arm64: add sysfs vulnerability show for meltdown
  arm64: add sysfs vulnerability show for spectre v2
  arm64: add sysfs vulnerability show for speculative store bypass

Mian Yousaf Kaukab (3):
  arm64: add sysfs vulnerability show for spectre v1
  arm64: kpti: move check for non-vulnerable CPUs to a function
  arm64: enable generic CPU vulnerabilites support

 arch/arm64/Kconfig             |   1 +
 arch/arm64/kernel/cpu_errata.c | 126 +++++++++++++++++++++++++++++++--
 arch/arm64/kernel/cpufeature.c |  45 +++++++++---
 drivers/base/cpu.c             |  19 +++++
 include/linux/cpu.h            |   7 ++
 5 files changed, 185 insertions(+), 13 deletions(-)

Comments

Stefan Wahren Jan. 15, 2019, 7:50 p.m. UTC | #1

Hi Jeremy,

> Jeremy Linton <[e-mail]> hat am 10. Januar 2019 um 00:55 geschrieben:
> 
> 
> Arm64 machines should be displaying a human readable
> vulnerability status to speculative execution attacks in
> /sys/devices/system/cpu/vulnerabilities 
> 
> This series enables that behavior by providing the expected
> functions. Those functions expose the cpu errata and feature
> states, as well as whether firmware is responding appropriately
> to display the overall machine status. This means that in a
> heterogeneous machine we will only claim the machine is mitigated
> or safe if we are confident all booted cores are safe or
> mitigated.
> 

i applied this v3 series and Marc's v2 series.

Now i'm getting the following on a Raspberry Pi 3 B+ :

meltdown:Not affected
spec_store_bypass:Not affected
spectre_v1:Mitigation: __user pointer sanitization

So the entries l1tf and spectre_v2 disappeared.

Stefan

Jeremy Linton Jan. 15, 2019, 9:21 p.m. UTC | #2

Hi,

On 01/15/2019 01:50 PM, Stefan Wahren wrote:
> Hi Jeremy,
> 
>> Jeremy Linton <[e-mail]> hat am 10. Januar 2019 um 00:55 geschrieben:
>>
>>
>> Arm64 machines should be displaying a human readable
>> vulnerability status to speculative execution attacks in
>> /sys/devices/system/cpu/vulnerabilities
>>
>> This series enables that behavior by providing the expected
>> functions. Those functions expose the cpu errata and feature
>> states, as well as whether firmware is responding appropriately
>> to display the overall machine status. This means that in a
>> heterogeneous machine we will only claim the machine is mitigated
>> or safe if we are confident all booted cores are safe or
>> mitigated.
>>
> 
> i applied this v3 series and Marc's v2 series.
> 
> Now i'm getting the following on a Raspberry Pi 3 B+ :
> 
> meltdown:Not affected
> spec_store_bypass:Not affected
> spectre_v1:Mitigation: __user pointer sanitization
> 
> So the entries l1tf and spectre_v2 disappeared.

Yes, the l1tf entry should be gone.

I believe there is a problem with the "1/2 advertise.." patch in that 
the 'arm64_requested_vuln_attrs |=' line needs to be hoisted  to the top 
of check_branch_predictor() and the '__spectrev2_safe = false' line 
needs to be hoisted 6 lines immediately above "/* Fallback to firmware 
detection*/"

That should re-enable the spectre_v2 entry.

Stefan Wahren Jan. 18, 2019, 6:05 p.m. UTC | #3

Hi,

> Jeremy Linton <[e-mail]> hat am 15. Januar 2019 um 22:21 geschrieben:
> 
> 
> Hi,
> 
> On 01/15/2019 01:50 PM, Stefan Wahren wrote:
> > Hi Jeremy,
> > 
> >> Jeremy Linton <[e-mail]> hat am 10. Januar 2019 um 00:55 geschrieben:
> >>
> >>
> >> Arm64 machines should be displaying a human readable
> >> vulnerability status to speculative execution attacks in
> >> /sys/devices/system/cpu/vulnerabilities
> >>
> >> This series enables that behavior by providing the expected
> >> functions. Those functions expose the cpu errata and feature
> >> states, as well as whether firmware is responding appropriately
> >> to display the overall machine status. This means that in a
> >> heterogeneous machine we will only claim the machine is mitigated
> >> or safe if we are confident all booted cores are safe or
> >> mitigated.
> >>
> > 
> > i applied this v3 series and Marc's v2 series.
> > 
> > Now i'm getting the following on a Raspberry Pi 3 B+ :
> > 
> > meltdown:Not affected
> > spec_store_bypass:Not affected
> > spectre_v1:Mitigation: __user pointer sanitization
> > 
> > So the entries l1tf and spectre_v2 disappeared.
> 
> Yes, the l1tf entry should be gone.
> 
> I believe there is a problem with the "1/2 advertise.." patch in that 
> the 'arm64_requested_vuln_attrs |=' line needs to be hoisted  to the top 
> of check_branch_predictor() and the '__spectrev2_safe = false' line 
> needs to be hoisted 6 lines immediately above "/* Fallback to firmware 
> detection*/"

a snippet or a new version would be nice

> 
> That should re-enable the spectre_v2 entry.

Jeremy Linton Jan. 18, 2019, 10:22 p.m. UTC | #4

On 01/18/2019 12:05 PM, Stefan Wahren wrote:
> Hi,
> 
>> Jeremy Linton <[e-mail]> hat am 15. Januar 2019 um 22:21 geschrieben:
>>
>>
>> Hi,
>>
>> On 01/15/2019 01:50 PM, Stefan Wahren wrote:
>>> Hi Jeremy,
>>>
>>>> Jeremy Linton <[e-mail]> hat am 10. Januar 2019 um 00:55 geschrieben:
>>>>
>>>>
>>>> Arm64 machines should be displaying a human readable
>>>> vulnerability status to speculative execution attacks in
>>>> /sys/devices/system/cpu/vulnerabilities
>>>>
>>>> This series enables that behavior by providing the expected
>>>> functions. Those functions expose the cpu errata and feature
>>>> states, as well as whether firmware is responding appropriately
>>>> to display the overall machine status. This means that in a
>>>> heterogeneous machine we will only claim the machine is mitigated
>>>> or safe if we are confident all booted cores are safe or
>>>> mitigated.
>>>>
>>>
>>> i applied this v3 series and Marc's v2 series.
>>>
>>> Now i'm getting the following on a Raspberry Pi 3 B+ :
>>>
>>> meltdown:Not affected
>>> spec_store_bypass:Not affected
>>> spectre_v1:Mitigation: __user pointer sanitization
>>>
>>> So the entries l1tf and spectre_v2 disappeared.
>>
>> Yes, the l1tf entry should be gone.
>>
>> I believe there is a problem with the "1/2 advertise.." patch in that
>> the 'arm64_requested_vuln_attrs |=' line needs to be hoisted  to the top
>> of check_branch_predictor() and the '__spectrev2_safe = false' line
>> needs to be hoisted 6 lines immediately above "/* Fallback to firmware
>> detection*/"
> 
> a snippet or a new version would be nice

Sure, I've got another version, to be posted soon (probably Tue of next 
week).

In the meantime, Marc's tree should work with the following fix:

diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index b44f87e7360d..7cfd34b2c0e5 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -286,11 +286,15 @@ static int detect_harden_bp_fw(void)
  }
  #endif /* CONFIG_HARDEN_BRANCH_PREDICTOR */

+#if defined(CONFIG_ARM64_SSBD) || \
+       defined(CONFIG_GENERIC_CPU_VULNERABILITIES)
+static bool __ssb_safe = true;
+#endif
+
  #ifdef CONFIG_ARM64_SSBD
  DEFINE_PER_CPU_READ_MOSTLY(u64, arm64_ssbd_callback_required);

  int ssbd_state __read_mostly = ARM64_SSBD_KERNEL;
-static bool __ssb_safe = true;

  static const struct ssbd_options {
         const char      *str;
@@ -569,6 +573,8 @@ check_branch_predictor(const struct 
arm64_cpu_capabilities *entry, int scope)

         WARN_ON(scope != SCOPE_LOCAL_CPU || preemptible());

+       arm64_requested_vuln_attrs |= VULN_SPECTREV2;
+
         /* If the CPU has CSV2 set, we're safe */
         if 
(cpuid_feature_extract_unsigned_field(read_cpuid(ID_AA64PFR0_EL1),
                                                  ID_AA64PFR0_CSV2_SHIFT))
@@ -578,17 +584,17 @@ check_branch_predictor(const struct 
arm64_cpu_capabilities *entry, int scope)
         if (is_midr_in_range_list(read_cpuid_id(), spectre_v2_safe_list))
                 return false;

+       __spectrev2_safe = false;
+
         /* Fallback to firmware detection */
         need_wa = detect_harden_bp_fw();
         if (!need_wa)
                 return false;

-       __spectrev2_safe = false;
-
         if (need_wa < 0)
                 pr_warn_once("ARM_SMCCC_ARCH_WORKAROUND_1 missing from 
firmware\n");

-       arm64_requested_vuln_attrs |= VULN_SPECTREV2;
+

         return (need_wa > 0);
  }

Stefan Wahren Jan. 19, 2019, 11:52 a.m. UTC | #5

> Jeremy Linton <[e-mail]> hat am 18. Januar 2019 um 23:22 geschrieben:
> 
> 
> On 01/18/2019 12:05 PM, Stefan Wahren wrote:
> > Hi,
> > 
> > ...
> > 
> > a snippet or a new version would be nice
> 
> Sure, I've got another version, to be posted soon (probably Tue of next 
> week).
> 
> In the meantime, Marc's tree should work with the following fix:
> 
> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> index b44f87e7360d..7cfd34b2c0e5 100644
> --- a/arch/arm64/kernel/cpu_errata.c
> +++ b/arch/arm64/kernel/cpu_errata.c
> @@ -286,11 +286,15 @@ static int detect_harden_bp_fw(void)
>   }
>   #endif /* CONFIG_HARDEN_BRANCH_PREDICTOR */
> 
> +#if defined(CONFIG_ARM64_SSBD) || \
> +       defined(CONFIG_GENERIC_CPU_VULNERABILITIES)
> +static bool __ssb_safe = true;
> +#endif
> +
>   #ifdef CONFIG_ARM64_SSBD
>   DEFINE_PER_CPU_READ_MOSTLY(u64, arm64_ssbd_callback_required);
> 
>   int ssbd_state __read_mostly = ARM64_SSBD_KERNEL;
> -static bool __ssb_safe = true;
> 
>   static const struct ssbd_options {
>          const char      *str;
> @@ -569,6 +573,8 @@ check_branch_predictor(const struct 
> arm64_cpu_capabilities *entry, int scope)
> 
>          WARN_ON(scope != SCOPE_LOCAL_CPU || preemptible());
> 
> +       arm64_requested_vuln_attrs |= VULN_SPECTREV2;
> +
>          /* If the CPU has CSV2 set, we're safe */
>          if 
> (cpuid_feature_extract_unsigned_field(read_cpuid(ID_AA64PFR0_EL1),
>                                                   ID_AA64PFR0_CSV2_SHIFT))
> @@ -578,17 +584,17 @@ check_branch_predictor(const struct 
> arm64_cpu_capabilities *entry, int scope)
>          if (is_midr_in_range_list(read_cpuid_id(), spectre_v2_safe_list))
>                  return false;
> 
> +       __spectrev2_safe = false;
> +
>          /* Fallback to firmware detection */
>          need_wa = detect_harden_bp_fw();
>          if (!need_wa)
>                  return false;
> 
> -       __spectrev2_safe = false;
> -
>          if (need_wa < 0)
>                  pr_warn_once("ARM_SMCCC_ARCH_WORKAROUND_1 missing from 
> firmware\n");
> 
> -       arm64_requested_vuln_attrs |= VULN_SPECTREV2;
> +
> 
>          return (need_wa > 0);
>   }
> 
>

fine with these changes i'm getting the following:

meltdown:Not affected
spec_store_bypass:Not affected
spectre_v1:Mitigation: __user pointer sanitization
spectre_v2:Not affected

Thanks
Stefan