diff mbox series

[v6,09/10] arm64: add sysfs vulnerability show for speculative store bypass

Message ID 20190321230557.45107-10-jeremy.linton@arm.com (mailing list archive)
State New, archived
Headers show
Series arm64: add system vulnerability sysfs entries | expand

Commit Message

Jeremy Linton March 21, 2019, 11:05 p.m. UTC
Return status based on ssbd_state and the arm64 SSBS feature. If
the mitigation is disabled, or the firmware isn't responding then
return the expected machine state based on a new blacklist of known
vulnerable cores.

Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Reviewed-by: Andre Przywara <andre.przywara@arm.com>
Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
---
 arch/arm64/kernel/cpu_errata.c | 44 ++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)

Comments

Will Deacon April 3, 2019, 4:50 p.m. UTC | #1
Hi Jeremy,

On Thu, Mar 21, 2019 at 06:05:56PM -0500, Jeremy Linton wrote:
> Return status based on ssbd_state and the arm64 SSBS feature. If
> the mitigation is disabled, or the firmware isn't responding then
> return the expected machine state based on a new blacklist of known
> vulnerable cores.
> 
> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
> ---
>  arch/arm64/kernel/cpu_errata.c | 44 ++++++++++++++++++++++++++++++++++
>  1 file changed, 44 insertions(+)
> 
> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> index 6958dcdabf7d..172ffbabd597 100644
> --- a/arch/arm64/kernel/cpu_errata.c
> +++ b/arch/arm64/kernel/cpu_errata.c
> @@ -278,6 +278,7 @@ static int detect_harden_bp_fw(void)
>  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;
> @@ -386,6 +387,9 @@ static bool has_ssbd_mitigation(const struct arm64_cpu_capabilities *entry,
>  
>  	WARN_ON(scope != SCOPE_LOCAL_CPU || preemptible());
>  
> +	if (is_midr_in_range_list(read_cpuid_id(), entry->midr_range_list))
> +		__ssb_safe = false;
> +

Does this mean that we assume that CPUs not present in our table are not
affected by speculative store bypass? I don't think that's a good
assumption, because we don't necessary have knowledge about partner or
future CPU implementations, so I think any CPU lists really have to be
whitelists like they are for the other vulnerabilities.

>  	if (this_cpu_has_cap(ARM64_SSBS)) {
>  		required = false;
>  		goto out_printmsg;
> @@ -419,12 +423,14 @@ static bool has_ssbd_mitigation(const struct arm64_cpu_capabilities *entry,
>  		ssbd_state = ARM64_SSBD_UNKNOWN;
>  		return false;
>  
> +	/* machines with mixed mitigation requirements must not return this */
>  	case SMCCC_RET_NOT_REQUIRED:
>  		pr_info_once("%s mitigation not required\n", entry->desc);
>  		ssbd_state = ARM64_SSBD_MITIGATED;
>  		return false;
>  
>  	case SMCCC_RET_SUCCESS:
> +		__ssb_safe = false;
>  		required = true;
>  		break;
>  
> @@ -474,6 +480,16 @@ static bool has_ssbd_mitigation(const struct arm64_cpu_capabilities *entry,
>  	return required;
>  }
>  
> +/* known vulnerable cores */
> +static const struct midr_range arm64_ssb_cpus[] = {
> +	MIDR_ALL_VERSIONS(MIDR_CORTEX_A57),
> +	MIDR_ALL_VERSIONS(MIDR_CORTEX_A72),
> +	MIDR_ALL_VERSIONS(MIDR_CORTEX_A73),
> +	MIDR_ALL_VERSIONS(MIDR_CORTEX_A75),
> +	MIDR_ALL_VERSIONS(MIDR_CORTEX_A76),
> +	{},
> +};
> +
>  static void __maybe_unused
>  cpu_enable_cache_maint_trap(const struct arm64_cpu_capabilities *__unused)
>  {
> @@ -769,6 +785,7 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
>  		.capability = ARM64_SSBD,
>  		.type = ARM64_CPUCAP_LOCAL_CPU_ERRATUM,
>  		.matches = has_ssbd_mitigation,
> +		.midr_range_list = arm64_ssb_cpus,
>  	},
>  #ifdef CONFIG_ARM64_ERRATUM_1188873
>  	{
> @@ -807,3 +824,30 @@ ssize_t cpu_show_spectre_v2(struct device *dev, struct device_attribute *attr,
>  
>  	return sprintf(buf, "Vulnerable\n");
>  }
> +
> +ssize_t cpu_show_spec_store_bypass(struct device *dev,
> +		struct device_attribute *attr, char *buf)
> +{
> +	/*
> +	 *  Two assumptions: First, ssbd_state reflects the worse case
> +	 *  for heterogeneous machines, and that if SSBS is supported its
> +	 *  supported by all cores.
> +	 */
> +	switch (ssbd_state) {
> +	case ARM64_SSBD_MITIGATED:
> +		return sprintf(buf, "Not affected\n");
> +
> +	case ARM64_SSBD_KERNEL:
> +	case ARM64_SSBD_FORCE_ENABLE:
> +		if (cpus_have_cap(ARM64_SSBS))
> +			return sprintf(buf, "Not affected\n");
> +		if (IS_ENABLED(CONFIG_ARM64_SSBD))
> +			return sprintf(buf,
> +			    "Mitigation: Speculative Store Bypass disabled\n");

x86 has a message about the prctl(), which we also support.

Will
Andre Przywara April 5, 2019, 10:10 a.m. UTC | #2
On Wed, 3 Apr 2019 17:50:05 +0100
Will Deacon <will.deacon@arm.com> wrote:

> Hi Jeremy,
> 
> On Thu, Mar 21, 2019 at 06:05:56PM -0500, Jeremy Linton wrote:
> > Return status based on ssbd_state and the arm64 SSBS feature. If
> > the mitigation is disabled, or the firmware isn't responding then
> > return the expected machine state based on a new blacklist of known
> > vulnerable cores.
> > 
> > Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> > Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> > Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
> > ---
> >  arch/arm64/kernel/cpu_errata.c | 44 ++++++++++++++++++++++++++++++++++
> >  1 file changed, 44 insertions(+)
> > 
> > diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> > index 6958dcdabf7d..172ffbabd597 100644
> > --- a/arch/arm64/kernel/cpu_errata.c
> > +++ b/arch/arm64/kernel/cpu_errata.c
> > @@ -278,6 +278,7 @@ static int detect_harden_bp_fw(void)
> >  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;
> > @@ -386,6 +387,9 @@ static bool has_ssbd_mitigation(const struct arm64_cpu_capabilities *entry,
> >  
> >  	WARN_ON(scope != SCOPE_LOCAL_CPU || preemptible());
> >  
> > +	if (is_midr_in_range_list(read_cpuid_id(), entry->midr_range_list))
> > +		__ssb_safe = false;
> > +  
> 
> Does this mean that we assume that CPUs not present in our table are not
> affected by speculative store bypass?

No, not affected are only those where we either have SSBS or the firmware
explicitly returns SMCCC_RET_NOT_REQUIRED. This is governed by ssbd_state.
So this doesn't affect correctness.

__ssb_safe is an additional state just used for the sysfs output. But
indeed it looks like this is wrong if the CPU is both not listed and the
system doesn't provide the firmware interface: AFAICS we would report "Not
affected" in this case.

> I don't think that's a good
> assumption, because we don't necessary have knowledge about partner or
> future CPU implementations, so I think any CPU lists really have to be
> whitelists like they are for the other vulnerabilities.

I think the idea was to cover all those "legacy" systems which have
older cores (no SSBS), but didn't get an firmware update. So your old Seattle
would truthfully report "Vulnerable", but any random A53 device would
report "Not affected", even with ancient firmware.

Cheers,
Andre.

> >  	if (this_cpu_has_cap(ARM64_SSBS)) {
> >  		required = false;
> >  		goto out_printmsg;
> > @@ -419,12 +423,14 @@ static bool has_ssbd_mitigation(const struct arm64_cpu_capabilities *entry,
> >  		ssbd_state = ARM64_SSBD_UNKNOWN;
> >  		return false;
> >  
> > +	/* machines with mixed mitigation requirements must not return this */
> >  	case SMCCC_RET_NOT_REQUIRED:
> >  		pr_info_once("%s mitigation not required\n", entry->desc);
> >  		ssbd_state = ARM64_SSBD_MITIGATED;
> >  		return false;
> >  
> >  	case SMCCC_RET_SUCCESS:
> > +		__ssb_safe = false;
> >  		required = true;
> >  		break;
> >  
> > @@ -474,6 +480,16 @@ static bool has_ssbd_mitigation(const struct arm64_cpu_capabilities *entry,
> >  	return required;
> >  }
> >  
> > +/* known vulnerable cores */
> > +static const struct midr_range arm64_ssb_cpus[] = {
> > +	MIDR_ALL_VERSIONS(MIDR_CORTEX_A57),
> > +	MIDR_ALL_VERSIONS(MIDR_CORTEX_A72),
> > +	MIDR_ALL_VERSIONS(MIDR_CORTEX_A73),
> > +	MIDR_ALL_VERSIONS(MIDR_CORTEX_A75),
> > +	MIDR_ALL_VERSIONS(MIDR_CORTEX_A76),
> > +	{},
> > +};
> > +
> >  static void __maybe_unused
> >  cpu_enable_cache_maint_trap(const struct arm64_cpu_capabilities *__unused)
> >  {
> > @@ -769,6 +785,7 @@ const struct arm64_cpu_capabilities arm64_errata[] = {
> >  		.capability = ARM64_SSBD,
> >  		.type = ARM64_CPUCAP_LOCAL_CPU_ERRATUM,
> >  		.matches = has_ssbd_mitigation,
> > +		.midr_range_list = arm64_ssb_cpus,
> >  	},
> >  #ifdef CONFIG_ARM64_ERRATUM_1188873
> >  	{
> > @@ -807,3 +824,30 @@ ssize_t cpu_show_spectre_v2(struct device *dev, struct device_attribute *attr,
> >  
> >  	return sprintf(buf, "Vulnerable\n");
> >  }
> > +
> > +ssize_t cpu_show_spec_store_bypass(struct device *dev,
> > +		struct device_attribute *attr, char *buf)
> > +{
> > +	/*
> > +	 *  Two assumptions: First, ssbd_state reflects the worse case
> > +	 *  for heterogeneous machines, and that if SSBS is supported its
> > +	 *  supported by all cores.
> > +	 */
> > +	switch (ssbd_state) {
> > +	case ARM64_SSBD_MITIGATED:
> > +		return sprintf(buf, "Not affected\n");
> > +
> > +	case ARM64_SSBD_KERNEL:
> > +	case ARM64_SSBD_FORCE_ENABLE:
> > +		if (cpus_have_cap(ARM64_SSBS))
> > +			return sprintf(buf, "Not affected\n");
> > +		if (IS_ENABLED(CONFIG_ARM64_SSBD))
> > +			return sprintf(buf,
> > +			    "Mitigation: Speculative Store Bypass disabled\n");  
> 
> x86 has a message about the prctl(), which we also support.
> 
> Will
Will Deacon April 5, 2019, 2:43 p.m. UTC | #3
On Fri, Apr 05, 2019 at 11:10:22AM +0100, Andre Przywara wrote:
> On Wed, 3 Apr 2019 17:50:05 +0100
> Will Deacon <will.deacon@arm.com> wrote:
> 
> > Hi Jeremy,
> > 
> > On Thu, Mar 21, 2019 at 06:05:56PM -0500, Jeremy Linton wrote:
> > > Return status based on ssbd_state and the arm64 SSBS feature. If
> > > the mitigation is disabled, or the firmware isn't responding then
> > > return the expected machine state based on a new blacklist of known
> > > vulnerable cores.
> > > 
> > > Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> > > Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> > > Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
> > > ---
> > >  arch/arm64/kernel/cpu_errata.c | 44 ++++++++++++++++++++++++++++++++++
> > >  1 file changed, 44 insertions(+)
> > > 
> > > diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> > > index 6958dcdabf7d..172ffbabd597 100644
> > > --- a/arch/arm64/kernel/cpu_errata.c
> > > +++ b/arch/arm64/kernel/cpu_errata.c
> > > @@ -278,6 +278,7 @@ static int detect_harden_bp_fw(void)
> > >  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;
> > > @@ -386,6 +387,9 @@ static bool has_ssbd_mitigation(const struct arm64_cpu_capabilities *entry,
> > >  
> > >  	WARN_ON(scope != SCOPE_LOCAL_CPU || preemptible());
> > >  
> > > +	if (is_midr_in_range_list(read_cpuid_id(), entry->midr_range_list))
> > > +		__ssb_safe = false;
> > > +  
> > 
> > Does this mean that we assume that CPUs not present in our table are not
> > affected by speculative store bypass?
> 
> No, not affected are only those where we either have SSBS or the firmware
> explicitly returns SMCCC_RET_NOT_REQUIRED. This is governed by ssbd_state.
> So this doesn't affect correctness.

I don't think that's true. My TX2, for example, says "Not affected" for
spec_store_bypass, but we don't actually know whether it's affected or
not and so it should report "Vulnerable" instead, like we do for spectre_v2
on the same machine.

> __ssb_safe is an additional state just used for the sysfs output. But
> indeed it looks like this is wrong if the CPU is both not listed and the
> system doesn't provide the firmware interface: AFAICS we would report "Not
> affected" in this case.

Yes, that's what I was getting at.

> > I don't think that's a good
> > assumption, because we don't necessary have knowledge about partner or
> > future CPU implementations, so I think any CPU lists really have to be
> > whitelists like they are for the other vulnerabilities.
> 
> I think the idea was to cover all those "legacy" systems which have
> older cores (no SSBS), but didn't get an firmware update. So your old Seattle
> would truthfully report "Vulnerable", but any random A53 device would
> report "Not affected", even with ancient firmware.

The only manageable way to deal with this is to use a whitelist, just like
we do for the other vulnerabilities. We shouldn't have to update it for
long because newer cores should have SSBS.

Will
Andre Przywara April 5, 2019, 3:18 p.m. UTC | #4
On Fri, 5 Apr 2019 15:43:10 +0100
Will Deacon <will.deacon@arm.com> wrote:

> On Fri, Apr 05, 2019 at 11:10:22AM +0100, Andre Przywara wrote:
> > On Wed, 3 Apr 2019 17:50:05 +0100
> > Will Deacon <will.deacon@arm.com> wrote:
> >   
> > > Hi Jeremy,
> > > 
> > > On Thu, Mar 21, 2019 at 06:05:56PM -0500, Jeremy Linton wrote:  
> > > > Return status based on ssbd_state and the arm64 SSBS feature. If
> > > > the mitigation is disabled, or the firmware isn't responding then
> > > > return the expected machine state based on a new blacklist of known
> > > > vulnerable cores.
> > > > 
> > > > Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
> > > > Reviewed-by: Andre Przywara <andre.przywara@arm.com>
> > > > Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
> > > > ---
> > > >  arch/arm64/kernel/cpu_errata.c | 44 ++++++++++++++++++++++++++++++++++
> > > >  1 file changed, 44 insertions(+)
> > > > 
> > > > diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
> > > > index 6958dcdabf7d..172ffbabd597 100644
> > > > --- a/arch/arm64/kernel/cpu_errata.c
> > > > +++ b/arch/arm64/kernel/cpu_errata.c
> > > > @@ -278,6 +278,7 @@ static int detect_harden_bp_fw(void)
> > > >  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;
> > > > @@ -386,6 +387,9 @@ static bool has_ssbd_mitigation(const struct arm64_cpu_capabilities *entry,
> > > >  
> > > >  	WARN_ON(scope != SCOPE_LOCAL_CPU || preemptible());
> > > >  
> > > > +	if (is_midr_in_range_list(read_cpuid_id(), entry->midr_range_list))
> > > > +		__ssb_safe = false;
> > > > +    
> > > 
> > > Does this mean that we assume that CPUs not present in our table are not
> > > affected by speculative store bypass?  
> > 
> > No, not affected are only those where we either have SSBS or the firmware
> > explicitly returns SMCCC_RET_NOT_REQUIRED. This is governed by ssbd_state.
> > So this doesn't affect correctness.  
> 
> I don't think that's true. My TX2, for example, says "Not affected" for
> spec_store_bypass, but we don't actually know whether it's affected or
> not and so it should report "Vulnerable" instead, like we do for spectre_v2
> on the same machine.

Yeah, what I actually meant was that this list doesn't affect whether the workaround gets applied or not. But indeed the reporting is wrong.

> > __ssb_safe is an additional state just used for the sysfs output. But
> > indeed it looks like this is wrong if the CPU is both not listed and the
> > system doesn't provide the firmware interface: AFAICS we would report "Not
> > affected" in this case.  
> 
> Yes, that's what I was getting at.
> 
> > > I don't think that's a good
> > > assumption, because we don't necessary have knowledge about partner or
> > > future CPU implementations, so I think any CPU lists really have to be
> > > whitelists like they are for the other vulnerabilities.  
> > 
> > I think the idea was to cover all those "legacy" systems which have
> > older cores (no SSBS), but didn't get an firmware update. So your old Seattle
> > would truthfully report "Vulnerable", but any random A53 device would
> > report "Not affected", even with ancient firmware.  
> 
> The only manageable way to deal with this is to use a whitelist, just like
> we do for the other vulnerabilities. We shouldn't have to update it for
> long because newer cores should have SSBS.

Agreed. We should start with __ssb_safe = false, and work from there. Seems much safer.

Cheers,
Andre.
Jeremy Linton April 5, 2019, 4:01 p.m. UTC | #5
Hi,


On 4/5/19 10:18 AM, Andre Przywara wrote:
> On Fri, 5 Apr 2019 15:43:10 +0100
> Will Deacon <will.deacon@arm.com> wrote:
> 
>> On Fri, Apr 05, 2019 at 11:10:22AM +0100, Andre Przywara wrote:
>>> On Wed, 3 Apr 2019 17:50:05 +0100
>>> Will Deacon <will.deacon@arm.com> wrote:
>>>    
>>>> Hi Jeremy,
>>>>
>>>> On Thu, Mar 21, 2019 at 06:05:56PM -0500, Jeremy Linton wrote:
>>>>> Return status based on ssbd_state and the arm64 SSBS feature. If
>>>>> the mitigation is disabled, or the firmware isn't responding then
>>>>> return the expected machine state based on a new blacklist of known
>>>>> vulnerable cores.
>>>>>
>>>>> Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
>>>>> Reviewed-by: Andre Przywara <andre.przywara@arm.com>
>>>>> Tested-by: Stefan Wahren <stefan.wahren@i2se.com>
>>>>> ---
>>>>>   arch/arm64/kernel/cpu_errata.c | 44 ++++++++++++++++++++++++++++++++++
>>>>>   1 file changed, 44 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
>>>>> index 6958dcdabf7d..172ffbabd597 100644
>>>>> --- a/arch/arm64/kernel/cpu_errata.c
>>>>> +++ b/arch/arm64/kernel/cpu_errata.c
>>>>> @@ -278,6 +278,7 @@ static int detect_harden_bp_fw(void)
>>>>>   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;
>>>>> @@ -386,6 +387,9 @@ static bool has_ssbd_mitigation(const struct arm64_cpu_capabilities *entry,
>>>>>   
>>>>>   	WARN_ON(scope != SCOPE_LOCAL_CPU || preemptible());
>>>>>   
>>>>> +	if (is_midr_in_range_list(read_cpuid_id(), entry->midr_range_list))
>>>>> +		__ssb_safe = false;
>>>>> +
>>>>
>>>> Does this mean that we assume that CPUs not present in our table are not
>>>> affected by speculative store bypass?
>>>
>>> No, not affected are only those where we either have SSBS or the firmware
>>> explicitly returns SMCCC_RET_NOT_REQUIRED. This is governed by ssbd_state.
>>> So this doesn't affect correctness.
>>
>> I don't think that's true. My TX2, for example, says "Not affected" for
>> spec_store_bypass, but we don't actually know whether it's affected or
>> not and so it should report "Vulnerable" instead, like we do for spectre_v2
>> on the same machine.
> 
> Yeah, what I actually meant was that this list doesn't affect whether the workaround gets applied or not. But indeed the reporting is wrong.
> 
>>> __ssb_safe is an additional state just used for the sysfs output. But
>>> indeed it looks like this is wrong if the CPU is both not listed and the
>>> system doesn't provide the firmware interface: AFAICS we would report "Not
>>> affected" in this case.
>>
>> Yes, that's what I was getting at.
>>
>>>> I don't think that's a good
>>>> assumption, because we don't necessary have knowledge about partner or
>>>> future CPU implementations, so I think any CPU lists really have to be
>>>> whitelists like they are for the other vulnerabilities.
>>>
>>> I think the idea was to cover all those "legacy" systems which have
>>> older cores (no SSBS), but didn't get an firmware update. So your old Seattle
>>> would truthfully report "Vulnerable", but any random A53 device would
>>> report "Not affected", even with ancient firmware.
>>
>> The only manageable way to deal with this is to use a whitelist, just like
>> we do for the other vulnerabilities. We shouldn't have to update it for
>> long because newer cores should have SSBS.
> 
> Agreed. We should start with __ssb_safe = false, and work from there. Seems much safer.

I tended to view this with a more charitable view (aka vendors with 
vulnerable machines would have put the effort in to get their firmware 
working). But that does violate the "if you don't know, its vulnerable" 
statements made earlier. I guess the advantage of claiming machines are 
vulnerable which aren't is that it strongly encourages vendors which are 
not vulnerable to come out and say so.

I will invert this logic and repost in the next day or so.

Thanks,
diff mbox series

Patch

diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 6958dcdabf7d..172ffbabd597 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -278,6 +278,7 @@  static int detect_harden_bp_fw(void)
 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;
@@ -386,6 +387,9 @@  static bool has_ssbd_mitigation(const struct arm64_cpu_capabilities *entry,
 
 	WARN_ON(scope != SCOPE_LOCAL_CPU || preemptible());
 
+	if (is_midr_in_range_list(read_cpuid_id(), entry->midr_range_list))
+		__ssb_safe = false;
+
 	if (this_cpu_has_cap(ARM64_SSBS)) {
 		required = false;
 		goto out_printmsg;
@@ -419,12 +423,14 @@  static bool has_ssbd_mitigation(const struct arm64_cpu_capabilities *entry,
 		ssbd_state = ARM64_SSBD_UNKNOWN;
 		return false;
 
+	/* machines with mixed mitigation requirements must not return this */
 	case SMCCC_RET_NOT_REQUIRED:
 		pr_info_once("%s mitigation not required\n", entry->desc);
 		ssbd_state = ARM64_SSBD_MITIGATED;
 		return false;
 
 	case SMCCC_RET_SUCCESS:
+		__ssb_safe = false;
 		required = true;
 		break;
 
@@ -474,6 +480,16 @@  static bool has_ssbd_mitigation(const struct arm64_cpu_capabilities *entry,
 	return required;
 }
 
+/* known vulnerable cores */
+static const struct midr_range arm64_ssb_cpus[] = {
+	MIDR_ALL_VERSIONS(MIDR_CORTEX_A57),
+	MIDR_ALL_VERSIONS(MIDR_CORTEX_A72),
+	MIDR_ALL_VERSIONS(MIDR_CORTEX_A73),
+	MIDR_ALL_VERSIONS(MIDR_CORTEX_A75),
+	MIDR_ALL_VERSIONS(MIDR_CORTEX_A76),
+	{},
+};
+
 static void __maybe_unused
 cpu_enable_cache_maint_trap(const struct arm64_cpu_capabilities *__unused)
 {
@@ -769,6 +785,7 @@  const struct arm64_cpu_capabilities arm64_errata[] = {
 		.capability = ARM64_SSBD,
 		.type = ARM64_CPUCAP_LOCAL_CPU_ERRATUM,
 		.matches = has_ssbd_mitigation,
+		.midr_range_list = arm64_ssb_cpus,
 	},
 #ifdef CONFIG_ARM64_ERRATUM_1188873
 	{
@@ -807,3 +824,30 @@  ssize_t cpu_show_spectre_v2(struct device *dev, struct device_attribute *attr,
 
 	return sprintf(buf, "Vulnerable\n");
 }
+
+ssize_t cpu_show_spec_store_bypass(struct device *dev,
+		struct device_attribute *attr, char *buf)
+{
+	/*
+	 *  Two assumptions: First, ssbd_state reflects the worse case
+	 *  for heterogeneous machines, and that if SSBS is supported its
+	 *  supported by all cores.
+	 */
+	switch (ssbd_state) {
+	case ARM64_SSBD_MITIGATED:
+		return sprintf(buf, "Not affected\n");
+
+	case ARM64_SSBD_KERNEL:
+	case ARM64_SSBD_FORCE_ENABLE:
+		if (cpus_have_cap(ARM64_SSBS))
+			return sprintf(buf, "Not affected\n");
+		if (IS_ENABLED(CONFIG_ARM64_SSBD))
+			return sprintf(buf,
+			    "Mitigation: Speculative Store Bypass disabled\n");
+	}
+
+	if (__ssb_safe)
+		return sprintf(buf, "Not affected\n");
+
+	return sprintf(buf, "Vulnerable\n");
+}