* [PATCH 0/2] arm64: Fixes for spectre-v2 detection in guest kernels
@ 2020-10-20 21:45 Stephen Boyd
2020-10-20 21:45 ` [PATCH 1/2] arm64: ARM_SMCCC_ARCH_WORKAROUND_1 doesn't return SMCCC_RET_NOT_REQUIRED Stephen Boyd
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Stephen Boyd @ 2020-10-20 21:45 UTC (permalink / raw)
To: Will Deacon, Catalin Marinas
Cc: linux-kernel, linux-arm-kernel, Andre Przywara, Steven Price,
Marc Zyngier, stable
The first patch fixes a problem with spectre-v2 detection in guest
kernels found on v5.4 and the second patch fixes an outdated comment.
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Steven Price <steven.price@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Stephen Boyd (2):
arm64: ARM_SMCCC_ARCH_WORKAROUND_1 doesn't return
SMCCC_RET_NOT_REQUIRED
arm64: proton-pack: Update comment to reflect new function name
arch/arm64/kernel/proton-pack.c | 7 +++----
arch/arm64/kvm/hypercalls.c | 2 +-
2 files changed, 4 insertions(+), 5 deletions(-)
base-commit: 38525c6919e2f6b27c1855905f342a0def3cbdcf
--
Sent by a computer, using git, on the internet
^ permalink raw reply [flat|nested] 12+ messages in thread
* [PATCH 1/2] arm64: ARM_SMCCC_ARCH_WORKAROUND_1 doesn't return SMCCC_RET_NOT_REQUIRED
2020-10-20 21:45 [PATCH 0/2] arm64: Fixes for spectre-v2 detection in guest kernels Stephen Boyd
@ 2020-10-20 21:45 ` Stephen Boyd
2020-10-21 7:57 ` Will Deacon
2020-10-20 21:45 ` [PATCH 2/2] arm64: proton-pack: Update comment to reflect new function name Stephen Boyd
2020-10-21 15:44 ` [PATCH 0/2] arm64: Fixes for spectre-v2 detection in guest kernels Will Deacon
2 siblings, 1 reply; 12+ messages in thread
From: Stephen Boyd @ 2020-10-20 21:45 UTC (permalink / raw)
To: Will Deacon, Catalin Marinas
Cc: linux-kernel, linux-arm-kernel, Andre Przywara, Steven Price,
Marc Zyngier, stable
According to the SMCCC spec (7.5.2 Discovery) the
ARM_SMCCC_ARCH_WORKAROUND_1 function id only returns 0, 1, and
SMCCC_RET_NOT_SUPPORTED corresponding to "workaround required",
"workaround not required but implemented", and "who knows, you're on
your own" respectively. For kvm hypercalls (hvc), we've implemented this
function id to return SMCCC_RET_NOT_SUPPORTED, 1, and
SMCCC_RET_NOT_REQUIRED. The SMCCC_RET_NOT_REQUIRED return value is not a
thing for this function id, and is probably copy/pasted from the
SMCCC_ARCH_WORKAROUND_2 function id that does support it.
Clean this up by returning 0, 1, and SMCCC_RET_NOT_SUPPORTED
appropriately. Changing this exposes the problem that
spectre_v2_get_cpu_fw_mitigation_state() assumes a
SMCCC_RET_NOT_SUPPORTED return value means we are vulnerable, but really
it means we have no idea and should assume we can't do anything about
mitigation. Put another way, it better be unaffected because it can't be
mitigated in the firmware (in this case kvm) as the call isn't
implemented!
Cc: Andre Przywara <andre.przywara@arm.com>
Cc: Steven Price <steven.price@arm.com>
Cc: Marc Zyngier <maz@kernel.org>
Cc: stable@vger.kernel.org
Fixes: c118bbb52743 ("arm64: KVM: Propagate full Spectre v2 workaround state to KVM guests")
Fixes: 73f381660959 ("arm64: Advertise mitigation of Spectre-v2, or lack thereof")
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
---
This will require a slightly different backport to stable kernels, but
at least it looks like this is a problem given that this return value
isn't valid per the spec and we've been going around it by returning
something invalid for some time.
arch/arm64/kernel/proton-pack.c | 3 +--
arch/arm64/kvm/hypercalls.c | 2 +-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/arm64/kernel/proton-pack.c b/arch/arm64/kernel/proton-pack.c
index 68b710f1b43f..00bd54f63f4f 100644
--- a/arch/arm64/kernel/proton-pack.c
+++ b/arch/arm64/kernel/proton-pack.c
@@ -149,10 +149,9 @@ static enum mitigation_state spectre_v2_get_cpu_fw_mitigation_state(void)
case SMCCC_RET_SUCCESS:
return SPECTRE_MITIGATED;
case SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED:
+ case SMCCC_RET_NOT_SUPPORTED: /* Good luck w/ the Gatekeeper of Gozer */
return SPECTRE_UNAFFECTED;
default:
- fallthrough;
- case SMCCC_RET_NOT_SUPPORTED:
return SPECTRE_VULNERABLE;
}
}
diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
index 9824025ccc5c..868486957808 100644
--- a/arch/arm64/kvm/hypercalls.c
+++ b/arch/arm64/kvm/hypercalls.c
@@ -31,7 +31,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
val = SMCCC_RET_SUCCESS;
break;
case SPECTRE_UNAFFECTED:
- val = SMCCC_RET_NOT_REQUIRED;
+ val = SMCCC_RET_NOT_SUPPORTED;
break;
}
break;
--
Sent by a computer, using git, on the internet
^ permalink raw reply related [flat|nested] 12+ messages in thread
* [PATCH 2/2] arm64: proton-pack: Update comment to reflect new function name
2020-10-20 21:45 [PATCH 0/2] arm64: Fixes for spectre-v2 detection in guest kernels Stephen Boyd
2020-10-20 21:45 ` [PATCH 1/2] arm64: ARM_SMCCC_ARCH_WORKAROUND_1 doesn't return SMCCC_RET_NOT_REQUIRED Stephen Boyd
@ 2020-10-20 21:45 ` Stephen Boyd
2020-10-21 15:44 ` [PATCH 0/2] arm64: Fixes for spectre-v2 detection in guest kernels Will Deacon
2 siblings, 0 replies; 12+ messages in thread
From: Stephen Boyd @ 2020-10-20 21:45 UTC (permalink / raw)
To: Will Deacon, Catalin Marinas; +Cc: linux-kernel, linux-arm-kernel, Marc Zyngier
The function detect_harden_bp_fw() is gone after commit d4647f0a2ad7
("arm64: Rewrite Spectre-v2 mitigation code"). Update this comment to
reflect the new state of affairs.
Cc: Marc Zyngier <maz@kernel.org>
Fixes: d4647f0a2ad7 ("arm64: Rewrite Spectre-v2 mitigation code")
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
---
arch/arm64/kernel/proton-pack.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/kernel/proton-pack.c b/arch/arm64/kernel/proton-pack.c
index 00bd54f63f4f..106857685145 100644
--- a/arch/arm64/kernel/proton-pack.c
+++ b/arch/arm64/kernel/proton-pack.c
@@ -203,8 +203,8 @@ static void install_bp_hardening_cb(bp_hardening_cb_t fn)
__SMCCC_WORKAROUND_1_SMC_SZ;
/*
- * detect_harden_bp_fw() passes NULL for the hyp_vecs start/end if
- * we're a guest. Skip the hyp-vectors work.
+ * Vinz Clortho takes the hyp_vecs start/end "keys" at
+ * the door when we're a guest. Skip the hyp-vectors work.
*/
if (!is_hyp_mode_available()) {
__this_cpu_write(bp_hardening_data.fn, fn);
--
Sent by a computer, using git, on the internet
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH 1/2] arm64: ARM_SMCCC_ARCH_WORKAROUND_1 doesn't return SMCCC_RET_NOT_REQUIRED
2020-10-20 21:45 ` [PATCH 1/2] arm64: ARM_SMCCC_ARCH_WORKAROUND_1 doesn't return SMCCC_RET_NOT_REQUIRED Stephen Boyd
@ 2020-10-21 7:57 ` Will Deacon
2020-10-21 10:23 ` Marc Zyngier
2020-10-21 15:23 ` Stephen Boyd
0 siblings, 2 replies; 12+ messages in thread
From: Will Deacon @ 2020-10-21 7:57 UTC (permalink / raw)
To: Stephen Boyd
Cc: Catalin Marinas, linux-kernel, linux-arm-kernel, Andre Przywara,
Steven Price, Marc Zyngier, stable
On Tue, Oct 20, 2020 at 02:45:43PM -0700, Stephen Boyd wrote:
> According to the SMCCC spec (7.5.2 Discovery) the
> ARM_SMCCC_ARCH_WORKAROUND_1 function id only returns 0, 1, and
> SMCCC_RET_NOT_SUPPORTED corresponding to "workaround required",
> "workaround not required but implemented", and "who knows, you're on
> your own" respectively. For kvm hypercalls (hvc), we've implemented this
> function id to return SMCCC_RET_NOT_SUPPORTED, 1, and
> SMCCC_RET_NOT_REQUIRED. The SMCCC_RET_NOT_REQUIRED return value is not a
> thing for this function id, and is probably copy/pasted from the
> SMCCC_ARCH_WORKAROUND_2 function id that does support it.
>
> Clean this up by returning 0, 1, and SMCCC_RET_NOT_SUPPORTED
> appropriately. Changing this exposes the problem that
> spectre_v2_get_cpu_fw_mitigation_state() assumes a
> SMCCC_RET_NOT_SUPPORTED return value means we are vulnerable, but really
> it means we have no idea and should assume we can't do anything about
> mitigation. Put another way, it better be unaffected because it can't be
> mitigated in the firmware (in this case kvm) as the call isn't
> implemented!
>
> Cc: Andre Przywara <andre.przywara@arm.com>
> Cc: Steven Price <steven.price@arm.com>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: stable@vger.kernel.org
> Fixes: c118bbb52743 ("arm64: KVM: Propagate full Spectre v2 workaround state to KVM guests")
> Fixes: 73f381660959 ("arm64: Advertise mitigation of Spectre-v2, or lack thereof")
> Signed-off-by: Stephen Boyd <swboyd@chromium.org>
> ---
>
> This will require a slightly different backport to stable kernels, but
> at least it looks like this is a problem given that this return value
> isn't valid per the spec and we've been going around it by returning
> something invalid for some time.
>
> arch/arm64/kernel/proton-pack.c | 3 +--
> arch/arm64/kvm/hypercalls.c | 2 +-
> 2 files changed, 2 insertions(+), 3 deletions(-)
>
> diff --git a/arch/arm64/kernel/proton-pack.c b/arch/arm64/kernel/proton-pack.c
> index 68b710f1b43f..00bd54f63f4f 100644
> --- a/arch/arm64/kernel/proton-pack.c
> +++ b/arch/arm64/kernel/proton-pack.c
> @@ -149,10 +149,9 @@ static enum mitigation_state spectre_v2_get_cpu_fw_mitigation_state(void)
> case SMCCC_RET_SUCCESS:
> return SPECTRE_MITIGATED;
> case SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED:
> + case SMCCC_RET_NOT_SUPPORTED: /* Good luck w/ the Gatekeeper of Gozer */
> return SPECTRE_UNAFFECTED;
Hmm, I'm not sure this is correct. The SMCCC spec is terrifically
unhelpful:
NOT_SUPPORTED:
Either:
* None of the PEs in the system require firmware mitigation for CVE-2017-5715.
* The system contains at least 1 PE affected by CVE-2017-5715 that has no firmware
mitigation available.
* The firmware does not provide any information about whether firmware mitigation is
required.
so we can't tell whether the thing is vulnerable or not in this case, and
have to assume that it is.
> default:
> - fallthrough;
> - case SMCCC_RET_NOT_SUPPORTED:
> return SPECTRE_VULNERABLE;
> }
> }
> diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> index 9824025ccc5c..868486957808 100644
> --- a/arch/arm64/kvm/hypercalls.c
> +++ b/arch/arm64/kvm/hypercalls.c
> @@ -31,7 +31,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> val = SMCCC_RET_SUCCESS;
> break;
> case SPECTRE_UNAFFECTED:
> - val = SMCCC_RET_NOT_REQUIRED;
> + val = SMCCC_RET_NOT_SUPPORTED;
Which means we need to return SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED here, I
suppose?
Will
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/2] arm64: ARM_SMCCC_ARCH_WORKAROUND_1 doesn't return SMCCC_RET_NOT_REQUIRED
2020-10-21 7:57 ` Will Deacon
@ 2020-10-21 10:23 ` Marc Zyngier
2020-10-21 12:43 ` Will Deacon
2020-10-21 15:23 ` Stephen Boyd
1 sibling, 1 reply; 12+ messages in thread
From: Marc Zyngier @ 2020-10-21 10:23 UTC (permalink / raw)
To: Will Deacon
Cc: Stephen Boyd, Catalin Marinas, linux-kernel, linux-arm-kernel,
Andre Przywara, Steven Price, stable
On 2020-10-21 08:57, Will Deacon wrote:
> On Tue, Oct 20, 2020 at 02:45:43PM -0700, Stephen Boyd wrote:
>> According to the SMCCC spec (7.5.2 Discovery) the
>> ARM_SMCCC_ARCH_WORKAROUND_1 function id only returns 0, 1, and
>> SMCCC_RET_NOT_SUPPORTED corresponding to "workaround required",
>> "workaround not required but implemented", and "who knows, you're on
>> your own" respectively. For kvm hypercalls (hvc), we've implemented
>> this
>> function id to return SMCCC_RET_NOT_SUPPORTED, 1, and
>> SMCCC_RET_NOT_REQUIRED. The SMCCC_RET_NOT_REQUIRED return value is not
>> a
>> thing for this function id, and is probably copy/pasted from the
>> SMCCC_ARCH_WORKAROUND_2 function id that does support it.
>>
>> Clean this up by returning 0, 1, and SMCCC_RET_NOT_SUPPORTED
>> appropriately. Changing this exposes the problem that
>> spectre_v2_get_cpu_fw_mitigation_state() assumes a
>> SMCCC_RET_NOT_SUPPORTED return value means we are vulnerable, but
>> really
>> it means we have no idea and should assume we can't do anything about
>> mitigation. Put another way, it better be unaffected because it can't
>> be
>> mitigated in the firmware (in this case kvm) as the call isn't
>> implemented!
>>
>> Cc: Andre Przywara <andre.przywara@arm.com>
>> Cc: Steven Price <steven.price@arm.com>
>> Cc: Marc Zyngier <maz@kernel.org>
>> Cc: stable@vger.kernel.org
>> Fixes: c118bbb52743 ("arm64: KVM: Propagate full Spectre v2 workaround
>> state to KVM guests")
>> Fixes: 73f381660959 ("arm64: Advertise mitigation of Spectre-v2, or
>> lack thereof")
>> Signed-off-by: Stephen Boyd <swboyd@chromium.org>
>> ---
>>
>> This will require a slightly different backport to stable kernels, but
>> at least it looks like this is a problem given that this return value
>> isn't valid per the spec and we've been going around it by returning
>> something invalid for some time.
>>
>> arch/arm64/kernel/proton-pack.c | 3 +--
>> arch/arm64/kvm/hypercalls.c | 2 +-
>> 2 files changed, 2 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/proton-pack.c
>> b/arch/arm64/kernel/proton-pack.c
>> index 68b710f1b43f..00bd54f63f4f 100644
>> --- a/arch/arm64/kernel/proton-pack.c
>> +++ b/arch/arm64/kernel/proton-pack.c
>> @@ -149,10 +149,9 @@ static enum mitigation_state
>> spectre_v2_get_cpu_fw_mitigation_state(void)
>> case SMCCC_RET_SUCCESS:
>> return SPECTRE_MITIGATED;
>> case SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED:
>> + case SMCCC_RET_NOT_SUPPORTED: /* Good luck w/ the Gatekeeper of
>> Gozer */
>> return SPECTRE_UNAFFECTED;
>
> Hmm, I'm not sure this is correct. The SMCCC spec is terrifically
> unhelpful:
>
> NOT_SUPPORTED:
> Either:
> * None of the PEs in the system require firmware mitigation for
> CVE-2017-5715.
> * The system contains at least 1 PE affected by CVE-2017-5715 that
> has no firmware
> mitigation available.
> * The firmware does not provide any information about whether
> firmware mitigation is
> required.
>
> so we can't tell whether the thing is vulnerable or not in this case,
> and
> have to assume that it is.
>
>> default:
>> - fallthrough;
>> - case SMCCC_RET_NOT_SUPPORTED:
>> return SPECTRE_VULNERABLE;
>> }
>> }
>> diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
>> index 9824025ccc5c..868486957808 100644
>> --- a/arch/arm64/kvm/hypercalls.c
>> +++ b/arch/arm64/kvm/hypercalls.c
>> @@ -31,7 +31,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
>> val = SMCCC_RET_SUCCESS;
>> break;
>> case SPECTRE_UNAFFECTED:
>> - val = SMCCC_RET_NOT_REQUIRED;
>> + val = SMCCC_RET_NOT_SUPPORTED;
>
> Which means we need to return SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED
> here, I
> suppose?
Gahh, I keep mixing Spectre-v2 and WA2. Not good. I *think* the patch
below is enough, but I need to give it a go...
M.
diff --git a/arch/arm64/kernel/proton-pack.c
b/arch/arm64/kernel/proton-pack.c
index 68b710f1b43f..3f417d6305ef 100644
--- a/arch/arm64/kernel/proton-pack.c
+++ b/arch/arm64/kernel/proton-pack.c
@@ -134,8 +134,6 @@ static enum mitigation_state
spectre_v2_get_cpu_hw_mitigation_state(void)
return SPECTRE_VULNERABLE;
}
-#define SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED (1)
-
static enum mitigation_state
spectre_v2_get_cpu_fw_mitigation_state(void)
{
int ret;
@@ -148,7 +146,7 @@ static enum mitigation_state
spectre_v2_get_cpu_fw_mitigation_state(void)
switch (ret) {
case SMCCC_RET_SUCCESS:
return SPECTRE_MITIGATED;
- case SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED:
+ case SMCCC_RET_UNAFFECTED:
return SPECTRE_UNAFFECTED;
default:
fallthrough;
@@ -474,7 +472,7 @@ static enum mitigation_state
spectre_v4_get_cpu_fw_mitigation_state(void)
switch (ret) {
case SMCCC_RET_SUCCESS:
return SPECTRE_MITIGATED;
- case SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED:
+ case SMCCC_RET_UNAFFECTED:
fallthrough;
case SMCCC_RET_NOT_REQUIRED:
return SPECTRE_UNAFFECTED;
diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
index 9824025ccc5c..792824de5d27 100644
--- a/arch/arm64/kvm/hypercalls.c
+++ b/arch/arm64/kvm/hypercalls.c
@@ -31,7 +31,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
val = SMCCC_RET_SUCCESS;
break;
case SPECTRE_UNAFFECTED:
- val = SMCCC_RET_NOT_REQUIRED;
+ val = SMCCC_RET_UNAFFECTED;
break;
}
break;
diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
index 885c9ffc835c..6b4902dde822 100644
--- a/include/linux/arm-smccc.h
+++ b/include/linux/arm-smccc.h
@@ -104,6 +104,7 @@
* Return codes defined in ARM DEN 0070A
* ARM DEN 0070A is now merged/consolidated into ARM DEN 0028 C
*/
+#define SMCCC_RET_UNAFFECTED 1
#define SMCCC_RET_SUCCESS 0
#define SMCCC_RET_NOT_SUPPORTED -1
#define SMCCC_RET_NOT_REQUIRED -2
--
Jazz is not dead. It just smells funny...
^ permalink raw reply related [flat|nested] 12+ messages in thread
* Re: [PATCH 1/2] arm64: ARM_SMCCC_ARCH_WORKAROUND_1 doesn't return SMCCC_RET_NOT_REQUIRED
2020-10-21 10:23 ` Marc Zyngier
@ 2020-10-21 12:43 ` Will Deacon
0 siblings, 0 replies; 12+ messages in thread
From: Will Deacon @ 2020-10-21 12:43 UTC (permalink / raw)
To: Marc Zyngier
Cc: Stephen Boyd, Catalin Marinas, linux-kernel, linux-arm-kernel,
Andre Przywara, Steven Price, stable
On Wed, Oct 21, 2020 at 11:23:34AM +0100, Marc Zyngier wrote:
> On 2020-10-21 08:57, Will Deacon wrote:
> > On Tue, Oct 20, 2020 at 02:45:43PM -0700, Stephen Boyd wrote:
> > > According to the SMCCC spec (7.5.2 Discovery) the
> > > ARM_SMCCC_ARCH_WORKAROUND_1 function id only returns 0, 1, and
> > > SMCCC_RET_NOT_SUPPORTED corresponding to "workaround required",
> > > "workaround not required but implemented", and "who knows, you're on
> > > your own" respectively. For kvm hypercalls (hvc), we've implemented
> > > this
> > > function id to return SMCCC_RET_NOT_SUPPORTED, 1, and
> > > SMCCC_RET_NOT_REQUIRED. The SMCCC_RET_NOT_REQUIRED return value is
> > > not a
> > > thing for this function id, and is probably copy/pasted from the
> > > SMCCC_ARCH_WORKAROUND_2 function id that does support it.
> > >
> > > Clean this up by returning 0, 1, and SMCCC_RET_NOT_SUPPORTED
> > > appropriately. Changing this exposes the problem that
> > > spectre_v2_get_cpu_fw_mitigation_state() assumes a
> > > SMCCC_RET_NOT_SUPPORTED return value means we are vulnerable, but
> > > really
> > > it means we have no idea and should assume we can't do anything about
> > > mitigation. Put another way, it better be unaffected because it
> > > can't be
> > > mitigated in the firmware (in this case kvm) as the call isn't
> > > implemented!
> > >
> > > Cc: Andre Przywara <andre.przywara@arm.com>
> > > Cc: Steven Price <steven.price@arm.com>
> > > Cc: Marc Zyngier <maz@kernel.org>
> > > Cc: stable@vger.kernel.org
> > > Fixes: c118bbb52743 ("arm64: KVM: Propagate full Spectre v2
> > > workaround state to KVM guests")
> > > Fixes: 73f381660959 ("arm64: Advertise mitigation of Spectre-v2, or
> > > lack thereof")
> > > Signed-off-by: Stephen Boyd <swboyd@chromium.org>
> > > ---
> > >
> > > This will require a slightly different backport to stable kernels, but
> > > at least it looks like this is a problem given that this return value
> > > isn't valid per the spec and we've been going around it by returning
> > > something invalid for some time.
> > >
> > > arch/arm64/kernel/proton-pack.c | 3 +--
> > > arch/arm64/kvm/hypercalls.c | 2 +-
> > > 2 files changed, 2 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/arm64/kernel/proton-pack.c
> > > b/arch/arm64/kernel/proton-pack.c
> > > index 68b710f1b43f..00bd54f63f4f 100644
> > > --- a/arch/arm64/kernel/proton-pack.c
> > > +++ b/arch/arm64/kernel/proton-pack.c
> > > @@ -149,10 +149,9 @@ static enum mitigation_state
> > > spectre_v2_get_cpu_fw_mitigation_state(void)
> > > case SMCCC_RET_SUCCESS:
> > > return SPECTRE_MITIGATED;
> > > case SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED:
> > > + case SMCCC_RET_NOT_SUPPORTED: /* Good luck w/ the Gatekeeper of
> > > Gozer */
> > > return SPECTRE_UNAFFECTED;
> >
> > Hmm, I'm not sure this is correct. The SMCCC spec is terrifically
> > unhelpful:
> >
> > NOT_SUPPORTED:
> > Either:
> > * None of the PEs in the system require firmware mitigation for
> > CVE-2017-5715.
> > * The system contains at least 1 PE affected by CVE-2017-5715 that
> > has no firmware
> > mitigation available.
> > * The firmware does not provide any information about whether
> > firmware mitigation is
> > required.
> >
> > so we can't tell whether the thing is vulnerable or not in this case,
> > and
> > have to assume that it is.
> >
> > > default:
> > > - fallthrough;
> > > - case SMCCC_RET_NOT_SUPPORTED:
> > > return SPECTRE_VULNERABLE;
> > > }
> > > }
> > > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > > index 9824025ccc5c..868486957808 100644
> > > --- a/arch/arm64/kvm/hypercalls.c
> > > +++ b/arch/arm64/kvm/hypercalls.c
> > > @@ -31,7 +31,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > > val = SMCCC_RET_SUCCESS;
> > > break;
> > > case SPECTRE_UNAFFECTED:
> > > - val = SMCCC_RET_NOT_REQUIRED;
> > > + val = SMCCC_RET_NOT_SUPPORTED;
> >
> > Which means we need to return SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED here,
> > I
> > suppose?
>
> Gahh, I keep mixing Spectre-v2 and WA2. Not good. I *think* the patch
> below is enough, but I need to give it a go...
Yeah, and me. We should've named them 2 and 4 back in the day.
> diff --git a/arch/arm64/kernel/proton-pack.c
> b/arch/arm64/kernel/proton-pack.c
> index 68b710f1b43f..3f417d6305ef 100644
> --- a/arch/arm64/kernel/proton-pack.c
> +++ b/arch/arm64/kernel/proton-pack.c
> @@ -134,8 +134,6 @@ static enum mitigation_state
> spectre_v2_get_cpu_hw_mitigation_state(void)
> return SPECTRE_VULNERABLE;
> }
>
> -#define SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED (1)
Unfortunately, I think this value _is_ specific to the ARCH_WORKAROUND
calls, so it should stay like it is (i.e. other calls in SMCCC can return 1
to indicate other things)
But the semantic bit here:
> diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> index 9824025ccc5c..792824de5d27 100644
> --- a/arch/arm64/kvm/hypercalls.c
> +++ b/arch/arm64/kvm/hypercalls.c
> @@ -31,7 +31,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> val = SMCCC_RET_SUCCESS;
> break;
> case SPECTRE_UNAFFECTED:
> - val = SMCCC_RET_NOT_REQUIRED;
> + val = SMCCC_RET_UNAFFECTED;
Looks correct to me.
Will
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/2] arm64: ARM_SMCCC_ARCH_WORKAROUND_1 doesn't return SMCCC_RET_NOT_REQUIRED
2020-10-21 7:57 ` Will Deacon
2020-10-21 10:23 ` Marc Zyngier
@ 2020-10-21 15:23 ` Stephen Boyd
2020-10-21 15:49 ` Will Deacon
1 sibling, 1 reply; 12+ messages in thread
From: Stephen Boyd @ 2020-10-21 15:23 UTC (permalink / raw)
To: Will Deacon
Cc: Catalin Marinas, linux-kernel, linux-arm-kernel, Andre Przywara,
Steven Price, Marc Zyngier, stable
Quoting Will Deacon (2020-10-21 00:57:23)
> On Tue, Oct 20, 2020 at 02:45:43PM -0700, Stephen Boyd wrote:
> > According to the SMCCC spec (7.5.2 Discovery) the
> > ARM_SMCCC_ARCH_WORKAROUND_1 function id only returns 0, 1, and
> > SMCCC_RET_NOT_SUPPORTED corresponding to "workaround required",
> > "workaround not required but implemented", and "who knows, you're on
> > your own" respectively. For kvm hypercalls (hvc), we've implemented this
> > function id to return SMCCC_RET_NOT_SUPPORTED, 1, and
> > SMCCC_RET_NOT_REQUIRED. The SMCCC_RET_NOT_REQUIRED return value is not a
> > thing for this function id, and is probably copy/pasted from the
> > SMCCC_ARCH_WORKAROUND_2 function id that does support it.
> >
> > Clean this up by returning 0, 1, and SMCCC_RET_NOT_SUPPORTED
> > appropriately. Changing this exposes the problem that
> > spectre_v2_get_cpu_fw_mitigation_state() assumes a
> > SMCCC_RET_NOT_SUPPORTED return value means we are vulnerable, but really
> > it means we have no idea and should assume we can't do anything about
> > mitigation. Put another way, it better be unaffected because it can't be
> > mitigated in the firmware (in this case kvm) as the call isn't
> > implemented!
> >
> > Cc: Andre Przywara <andre.przywara@arm.com>
> > Cc: Steven Price <steven.price@arm.com>
> > Cc: Marc Zyngier <maz@kernel.org>
> > Cc: stable@vger.kernel.org
> > Fixes: c118bbb52743 ("arm64: KVM: Propagate full Spectre v2 workaround state to KVM guests")
> > Fixes: 73f381660959 ("arm64: Advertise mitigation of Spectre-v2, or lack thereof")
> > Signed-off-by: Stephen Boyd <swboyd@chromium.org>
> > ---
> >
> > This will require a slightly different backport to stable kernels, but
> > at least it looks like this is a problem given that this return value
> > isn't valid per the spec and we've been going around it by returning
> > something invalid for some time.
> >
> > arch/arm64/kernel/proton-pack.c | 3 +--
> > arch/arm64/kvm/hypercalls.c | 2 +-
> > 2 files changed, 2 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm64/kernel/proton-pack.c b/arch/arm64/kernel/proton-pack.c
> > index 68b710f1b43f..00bd54f63f4f 100644
> > --- a/arch/arm64/kernel/proton-pack.c
> > +++ b/arch/arm64/kernel/proton-pack.c
> > @@ -149,10 +149,9 @@ static enum mitigation_state spectre_v2_get_cpu_fw_mitigation_state(void)
> > case SMCCC_RET_SUCCESS:
> > return SPECTRE_MITIGATED;
> > case SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED:
> > + case SMCCC_RET_NOT_SUPPORTED: /* Good luck w/ the Gatekeeper of Gozer */
> > return SPECTRE_UNAFFECTED;
>
> Hmm, I'm not sure this is correct. The SMCCC spec is terrifically
> unhelpful:
>
> NOT_SUPPORTED:
> Either:
> * None of the PEs in the system require firmware mitigation for CVE-2017-5715.
> * The system contains at least 1 PE affected by CVE-2017-5715 that has no firmware
> mitigation available.
> * The firmware does not provide any information about whether firmware mitigation is
> required.
>
> so we can't tell whether the thing is vulnerable or not in this case, and
> have to assume that it is.
If I'm reading the TF-A code correctly it looks like this will return
SMC_UNK if the platform decides that "This flag can be set to 0 by the
platform if none of the PEs in the system need the workaround." Where
the flag is WORKAROUND_CVE_2017_5715 and the call handler returns 1 if
the errata doesn't apply but the config is enabled, 0 if the errata
applies and the config is enabled, or SMC_UNK (I guess this is
NOT_SUPPORTED?) if the config is disabled[2].
So TF-A could disable this config and then the kernel would think it is
vulnerable when it actually isn't? The spec is a pile of ectoplasma
here.
>
> > default:
> > - fallthrough;
> > - case SMCCC_RET_NOT_SUPPORTED:
> > return SPECTRE_VULNERABLE;
> > }
> > }
> > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > index 9824025ccc5c..868486957808 100644
> > --- a/arch/arm64/kvm/hypercalls.c
> > +++ b/arch/arm64/kvm/hypercalls.c
> > @@ -31,7 +31,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > val = SMCCC_RET_SUCCESS;
> > break;
> > case SPECTRE_UNAFFECTED:
> > - val = SMCCC_RET_NOT_REQUIRED;
> > + val = SMCCC_RET_NOT_SUPPORTED;
>
> Which means we need to return SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED here, I
> suppose?
>
Does the kernel implement a workaround in the case that no guest PE is
affected? If so then returning 1 sounds OK to me, but otherwise
NOT_SUPPORTED should work per the spec.
[1] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/docs/design/cpu-specific-build-macros.rst#n14
[2] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/services/arm_arch_svc/arm_arch_svc_setup.c#n30
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 0/2] arm64: Fixes for spectre-v2 detection in guest kernels
2020-10-20 21:45 [PATCH 0/2] arm64: Fixes for spectre-v2 detection in guest kernels Stephen Boyd
2020-10-20 21:45 ` [PATCH 1/2] arm64: ARM_SMCCC_ARCH_WORKAROUND_1 doesn't return SMCCC_RET_NOT_REQUIRED Stephen Boyd
2020-10-20 21:45 ` [PATCH 2/2] arm64: proton-pack: Update comment to reflect new function name Stephen Boyd
@ 2020-10-21 15:44 ` Will Deacon
2 siblings, 0 replies; 12+ messages in thread
From: Will Deacon @ 2020-10-21 15:44 UTC (permalink / raw)
To: Stephen Boyd, Catalin Marinas
Cc: kernel-team, Will Deacon, Steven Price, linux-arm-kernel, stable,
linux-kernel, Andre Przywara, Marc Zyngier
On Tue, 20 Oct 2020 14:45:42 -0700, Stephen Boyd wrote:
> The first patch fixes a problem with spectre-v2 detection in guest
> kernels found on v5.4 and the second patch fixes an outdated comment.
>
> Cc: Andre Przywara <andre.przywara@arm.com>
> Cc: Steven Price <steven.price@arm.com>
> Cc: Marc Zyngier <maz@kernel.org>
> Cc: stable@vger.kernel.org
>
> [...]
Applied just the second patch to arm64 (for-next/core), thanks!
[2/2] arm64: proton-pack: Update comment to reflect new function name
https://git.kernel.org/arm64/c/66dd3474702a
Cheers,
--
Will
https://fixes.arm64.dev
https://next.arm64.dev
https://will.arm64.dev
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/2] arm64: ARM_SMCCC_ARCH_WORKAROUND_1 doesn't return SMCCC_RET_NOT_REQUIRED
2020-10-21 15:23 ` Stephen Boyd
@ 2020-10-21 15:49 ` Will Deacon
2020-10-21 16:12 ` Stephen Boyd
0 siblings, 1 reply; 12+ messages in thread
From: Will Deacon @ 2020-10-21 15:49 UTC (permalink / raw)
To: Stephen Boyd
Cc: Catalin Marinas, linux-kernel, linux-arm-kernel, Andre Przywara,
Steven Price, Marc Zyngier, stable
On Wed, Oct 21, 2020 at 08:23:54AM -0700, Stephen Boyd wrote:
> Quoting Will Deacon (2020-10-21 00:57:23)
> > On Tue, Oct 20, 2020 at 02:45:43PM -0700, Stephen Boyd wrote:
> > > According to the SMCCC spec (7.5.2 Discovery) the
> > > ARM_SMCCC_ARCH_WORKAROUND_1 function id only returns 0, 1, and
> > > SMCCC_RET_NOT_SUPPORTED corresponding to "workaround required",
> > > "workaround not required but implemented", and "who knows, you're on
> > > your own" respectively. For kvm hypercalls (hvc), we've implemented this
> > > function id to return SMCCC_RET_NOT_SUPPORTED, 1, and
> > > SMCCC_RET_NOT_REQUIRED. The SMCCC_RET_NOT_REQUIRED return value is not a
> > > thing for this function id, and is probably copy/pasted from the
> > > SMCCC_ARCH_WORKAROUND_2 function id that does support it.
> > >
> > > Clean this up by returning 0, 1, and SMCCC_RET_NOT_SUPPORTED
> > > appropriately. Changing this exposes the problem that
> > > spectre_v2_get_cpu_fw_mitigation_state() assumes a
> > > SMCCC_RET_NOT_SUPPORTED return value means we are vulnerable, but really
> > > it means we have no idea and should assume we can't do anything about
> > > mitigation. Put another way, it better be unaffected because it can't be
> > > mitigated in the firmware (in this case kvm) as the call isn't
> > > implemented!
> > >
> > > Cc: Andre Przywara <andre.przywara@arm.com>
> > > Cc: Steven Price <steven.price@arm.com>
> > > Cc: Marc Zyngier <maz@kernel.org>
> > > Cc: stable@vger.kernel.org
> > > Fixes: c118bbb52743 ("arm64: KVM: Propagate full Spectre v2 workaround state to KVM guests")
> > > Fixes: 73f381660959 ("arm64: Advertise mitigation of Spectre-v2, or lack thereof")
> > > Signed-off-by: Stephen Boyd <swboyd@chromium.org>
> > > ---
> > >
> > > This will require a slightly different backport to stable kernels, but
> > > at least it looks like this is a problem given that this return value
> > > isn't valid per the spec and we've been going around it by returning
> > > something invalid for some time.
> > >
> > > arch/arm64/kernel/proton-pack.c | 3 +--
> > > arch/arm64/kvm/hypercalls.c | 2 +-
> > > 2 files changed, 2 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/arm64/kernel/proton-pack.c b/arch/arm64/kernel/proton-pack.c
> > > index 68b710f1b43f..00bd54f63f4f 100644
> > > --- a/arch/arm64/kernel/proton-pack.c
> > > +++ b/arch/arm64/kernel/proton-pack.c
> > > @@ -149,10 +149,9 @@ static enum mitigation_state spectre_v2_get_cpu_fw_mitigation_state(void)
> > > case SMCCC_RET_SUCCESS:
> > > return SPECTRE_MITIGATED;
> > > case SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED:
> > > + case SMCCC_RET_NOT_SUPPORTED: /* Good luck w/ the Gatekeeper of Gozer */
> > > return SPECTRE_UNAFFECTED;
> >
> > Hmm, I'm not sure this is correct. The SMCCC spec is terrifically
> > unhelpful:
> >
> > NOT_SUPPORTED:
> > Either:
> > * None of the PEs in the system require firmware mitigation for CVE-2017-5715.
> > * The system contains at least 1 PE affected by CVE-2017-5715 that has no firmware
> > mitigation available.
> > * The firmware does not provide any information about whether firmware mitigation is
> > required.
> >
> > so we can't tell whether the thing is vulnerable or not in this case, and
> > have to assume that it is.
>
> If I'm reading the TF-A code correctly it looks like this will return
> SMC_UNK if the platform decides that "This flag can be set to 0 by the
> platform if none of the PEs in the system need the workaround." Where
> the flag is WORKAROUND_CVE_2017_5715 and the call handler returns 1 if
> the errata doesn't apply but the config is enabled, 0 if the errata
> applies and the config is enabled, or SMC_UNK (I guess this is
> NOT_SUPPORTED?) if the config is disabled[2].
>
> So TF-A could disable this config and then the kernel would think it is
> vulnerable when it actually isn't? The spec is a pile of ectoplasma
> here.
Yes, but there's not a lot we can do in that case as we rely on the
firmware to tell us whether or not we're affected. We do have the
"safelist" as a last resort, but that's about it.
> > > default:
> > > - fallthrough;
> > > - case SMCCC_RET_NOT_SUPPORTED:
> > > return SPECTRE_VULNERABLE;
> > > }
> > > }
> > > diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> > > index 9824025ccc5c..868486957808 100644
> > > --- a/arch/arm64/kvm/hypercalls.c
> > > +++ b/arch/arm64/kvm/hypercalls.c
> > > @@ -31,7 +31,7 @@ int kvm_hvc_call_handler(struct kvm_vcpu *vcpu)
> > > val = SMCCC_RET_SUCCESS;
> > > break;
> > > case SPECTRE_UNAFFECTED:
> > > - val = SMCCC_RET_NOT_REQUIRED;
> > > + val = SMCCC_RET_NOT_SUPPORTED;
> >
> > Which means we need to return SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED here, I
> > suppose?
> >
>
> Does the kernel implement a workaround in the case that no guest PE is
> affected? If so then returning 1 sounds OK to me, but otherwise
> NOT_SUPPORTED should work per the spec.
I don't follow you here. The spec says that "SMCCC_RET_NOT_SUPPORTED" is
valid return code in the case that "The system contains at least 1 PE
affected by CVE-2017-5715 that has no firmware mitigation available."
and do the guest would end up in the "vulnerable" state.
Will
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/2] arm64: ARM_SMCCC_ARCH_WORKAROUND_1 doesn't return SMCCC_RET_NOT_REQUIRED
2020-10-21 15:49 ` Will Deacon
@ 2020-10-21 16:12 ` Stephen Boyd
2020-10-21 21:13 ` Will Deacon
0 siblings, 1 reply; 12+ messages in thread
From: Stephen Boyd @ 2020-10-21 16:12 UTC (permalink / raw)
To: Will Deacon
Cc: Catalin Marinas, linux-kernel, linux-arm-kernel, Andre Przywara,
Steven Price, Marc Zyngier, stable
Quoting Will Deacon (2020-10-21 08:49:09)
> On Wed, Oct 21, 2020 at 08:23:54AM -0700, Stephen Boyd wrote:
> >
> > If I'm reading the TF-A code correctly it looks like this will return
> > SMC_UNK if the platform decides that "This flag can be set to 0 by the
> > platform if none of the PEs in the system need the workaround." Where
> > the flag is WORKAROUND_CVE_2017_5715 and the call handler returns 1 if
> > the errata doesn't apply but the config is enabled, 0 if the errata
> > applies and the config is enabled, or SMC_UNK (I guess this is
> > NOT_SUPPORTED?) if the config is disabled[2].
> >
> > So TF-A could disable this config and then the kernel would think it is
> > vulnerable when it actually isn't? The spec is a pile of ectoplasma
> > here.
>
> Yes, but there's not a lot we can do in that case as we rely on the
> firmware to tell us whether or not we're affected. We do have the
> "safelist" as a last resort, but that's about it.
There are quite a few platforms that set this config to 0. Should they
be setting it to 1?
tf-a $ git grep WORKAROUND_CVE_2017_5715 -- **/platform.mk | wc -l
17
This looks like a disconnect between kernel and TF-A but I'm not aware
of all the details here.
>
> >
> > Does the kernel implement a workaround in the case that no guest PE is
> > affected? If so then returning 1 sounds OK to me, but otherwise
> > NOT_SUPPORTED should work per the spec.
>
> I don't follow you here. The spec says that "SMCCC_RET_NOT_SUPPORTED" is
> valid return code in the case that "The system contains at least 1 PE
> affected by CVE-2017-5715 that has no firmware mitigation available."
> and do the guest would end up in the "vulnerable" state.
>
Returning 1 says "SMCCC_ARCH_WORKAROUND_1 can be invoked safely on all
PEs in the system" so I am not sure that invoking it is from a guest is
safe on systems that don't require the workaround? If it is always safe
to invoke the call from guest to host then returning 1 should be fine
here.
My read of the spec was that the intent is to remove the call at some
point and have the removal of the call mean that it isn't vulnerable.
Because NOT_SUPPORTED per the spec means "not needed", "maybe needed",
or "firmware doesn't know". Aha maybe they wanted us to make the call on
each CPU (i.e. PE) and then if any of them return 0 we should consider
it vulnerable and if they return NOT_SUPPORTED we should keep calling
for each CPU until we are sure we don't see a 0 and only see a 1 or
NOT_SUPPORTED? Looks like a saturating value sort of thing, across CPUs
that we care/know about.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/2] arm64: ARM_SMCCC_ARCH_WORKAROUND_1 doesn't return SMCCC_RET_NOT_REQUIRED
2020-10-21 16:12 ` Stephen Boyd
@ 2020-10-21 21:13 ` Will Deacon
2020-10-21 22:06 ` Stephen Boyd
0 siblings, 1 reply; 12+ messages in thread
From: Will Deacon @ 2020-10-21 21:13 UTC (permalink / raw)
To: Stephen Boyd
Cc: Catalin Marinas, linux-kernel, linux-arm-kernel, Andre Przywara,
Steven Price, Marc Zyngier, stable
On Wed, Oct 21, 2020 at 09:12:02AM -0700, Stephen Boyd wrote:
> Quoting Will Deacon (2020-10-21 08:49:09)
> > On Wed, Oct 21, 2020 at 08:23:54AM -0700, Stephen Boyd wrote:
> > >
> > > If I'm reading the TF-A code correctly it looks like this will return
> > > SMC_UNK if the platform decides that "This flag can be set to 0 by the
> > > platform if none of the PEs in the system need the workaround." Where
> > > the flag is WORKAROUND_CVE_2017_5715 and the call handler returns 1 if
> > > the errata doesn't apply but the config is enabled, 0 if the errata
> > > applies and the config is enabled, or SMC_UNK (I guess this is
> > > NOT_SUPPORTED?) if the config is disabled[2].
> > >
> > > So TF-A could disable this config and then the kernel would think it is
> > > vulnerable when it actually isn't? The spec is a pile of ectoplasma
> > > here.
> >
> > Yes, but there's not a lot we can do in that case as we rely on the
> > firmware to tell us whether or not we're affected. We do have the
> > "safelist" as a last resort, but that's about it.
>
> There are quite a few platforms that set this config to 0. Should they
> be setting it to 1?
>
> tf-a $ git grep WORKAROUND_CVE_2017_5715 -- **/platform.mk | wc -l
> 17
A quick skim suggests that most (all?) of these are A53-based, so that's
on the safelist and will be fine.
> This looks like a disconnect between kernel and TF-A but I'm not aware
> of all the details here.
I think it's alright, as it's just a legacy problem (newer cores should
have CSV2 set) and older cores are safelisted.
> > > Does the kernel implement a workaround in the case that no guest PE is
> > > affected? If so then returning 1 sounds OK to me, but otherwise
> > > NOT_SUPPORTED should work per the spec.
> >
> > I don't follow you here. The spec says that "SMCCC_RET_NOT_SUPPORTED" is
> > valid return code in the case that "The system contains at least 1 PE
> > affected by CVE-2017-5715 that has no firmware mitigation available."
> > and do the guest would end up in the "vulnerable" state.
> >
>
> Returning 1 says "SMCCC_ARCH_WORKAROUND_1 can be invoked safely on all
> PEs in the system" so I am not sure that invoking it is from a guest is
> safe on systems that don't require the workaround? If it is always safe
> to invoke the call from guest to host then returning 1 should be fine
> here.
I think it's fine, as KVM will pick that up.
> My read of the spec was that the intent is to remove the call at some
> point and have the removal of the call mean that it isn't vulnerable.
No, the CSV2 field in whichever ID register is for that. We check that in
spectre_v2_get_cpu_hw_mitigation_state().
> Because NOT_SUPPORTED per the spec means "not needed", "maybe needed",
> or "firmware doesn't know". Aha maybe they wanted us to make the call on
> each CPU (i.e. PE) and then if any of them return 0 we should consider
> it vulnerable and if they return NOT_SUPPORTED we should keep calling
> for each CPU until we are sure we don't see a 0 and only see a 1 or
> NOT_SUPPORTED? Looks like a saturating value sort of thing, across CPUs
> that we care/know about.
The mitigation state is always per-cpu because of big/little systems, there
just isn't a short-cut for the firmware to say "all CPUs are unaffected"
like there is for SMCCC_ARCH_WORKAROUND_2 with its "NOT_REQUIRED" return
code.
Will
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [PATCH 1/2] arm64: ARM_SMCCC_ARCH_WORKAROUND_1 doesn't return SMCCC_RET_NOT_REQUIRED
2020-10-21 21:13 ` Will Deacon
@ 2020-10-21 22:06 ` Stephen Boyd
0 siblings, 0 replies; 12+ messages in thread
From: Stephen Boyd @ 2020-10-21 22:06 UTC (permalink / raw)
To: Will Deacon
Cc: Catalin Marinas, linux-kernel, linux-arm-kernel, Andre Przywara,
Steven Price, Marc Zyngier, stable
Quoting Will Deacon (2020-10-21 14:13:26)
> On Wed, Oct 21, 2020 at 09:12:02AM -0700, Stephen Boyd wrote:
>
> > My read of the spec was that the intent is to remove the call at some
> > point and have the removal of the call mean that it isn't vulnerable.
>
> No, the CSV2 field in whichever ID register is for that. We check that in
> spectre_v2_get_cpu_hw_mitigation_state().
Alright, makes sense!
>
> > Because NOT_SUPPORTED per the spec means "not needed", "maybe needed",
> > or "firmware doesn't know". Aha maybe they wanted us to make the call on
> > each CPU (i.e. PE) and then if any of them return 0 we should consider
> > it vulnerable and if they return NOT_SUPPORTED we should keep calling
> > for each CPU until we are sure we don't see a 0 and only see a 1 or
> > NOT_SUPPORTED? Looks like a saturating value sort of thing, across CPUs
> > that we care/know about.
>
> The mitigation state is always per-cpu because of big/little systems, there
> just isn't a short-cut for the firmware to say "all CPUs are unaffected"
> like there is for SMCCC_ARCH_WORKAROUND_2 with its "NOT_REQUIRED" return
> code.
>
Ok. Can/should kvm be emulating the CSV2 bit that the guest sees? Just
wondering why I'm falling into this (ghost) trap in the first place.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-10-21 22:06 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-10-20 21:45 [PATCH 0/2] arm64: Fixes for spectre-v2 detection in guest kernels Stephen Boyd
2020-10-20 21:45 ` [PATCH 1/2] arm64: ARM_SMCCC_ARCH_WORKAROUND_1 doesn't return SMCCC_RET_NOT_REQUIRED Stephen Boyd
2020-10-21 7:57 ` Will Deacon
2020-10-21 10:23 ` Marc Zyngier
2020-10-21 12:43 ` Will Deacon
2020-10-21 15:23 ` Stephen Boyd
2020-10-21 15:49 ` Will Deacon
2020-10-21 16:12 ` Stephen Boyd
2020-10-21 21:13 ` Will Deacon
2020-10-21 22:06 ` Stephen Boyd
2020-10-20 21:45 ` [PATCH 2/2] arm64: proton-pack: Update comment to reflect new function name Stephen Boyd
2020-10-21 15:44 ` [PATCH 0/2] arm64: Fixes for spectre-v2 detection in guest kernels Will Deacon
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).