[PATCH v3] KVM: arm64: ARM_SMCCC_ARCH_WORKAROUND_1 doesn't return SMCCC_RET_NOT_REQUIRED

Will Deacon will at kernel.org
Mon Oct 26 09:25:33 EDT 2020


On Fri, Oct 23, 2020 at 08:47:50AM -0700, Stephen Boyd wrote:
> According to the SMCCC spec[1](7.5.2 Discovery) the
> ARM_SMCCC_ARCH_WORKAROUND_1 function id only returns 0, 1, and
> SMCCC_RET_NOT_SUPPORTED.
> 
>  0 is "workaround required and safe to call this function"
>  1 is "workaround not required but safe to call this function"
>  SMCCC_RET_NOT_SUPPORTED is "might be vulnerable or might not be, who knows, I give up!"
> 
> SMCCC_RET_NOT_SUPPORTED might as well mean "workaround required, except
> calling this function may not work because it isn't implemented in some
> cases". Wonderful. We map this SMC call to
> 
>  0 is SPECTRE_MITIGATED
>  1 is SPECTRE_UNAFFECTED
>  SMCCC_RET_NOT_SUPPORTED is SPECTRE_VULNERABLE
> 
> For KVM hypercalls (hvc), we've implemented this function id to return
> SMCCC_RET_NOT_SUPPORTED, 0, and SMCCC_RET_NOT_REQUIRED. One of those
> isn't supposed to be there. Per the code we call
> arm64_get_spectre_v2_state() to figure out what to return for this
> feature discovery call.
> 
>  0 is SPECTRE_MITIGATED
>  SMCCC_RET_NOT_REQUIRED is SPECTRE_UNAFFECTED
>  SMCCC_RET_NOT_SUPPORTED is SPECTRE_VULNERABLE
> 
> Let's clean this up so that KVM tells the guest this mapping:
> 
>  0 is SPECTRE_MITIGATED
>  1 is SPECTRE_UNAFFECTED
>  SMCCC_RET_NOT_SUPPORTED is SPECTRE_VULNERABLE
> 
> Note: SMCCC_RET_NOT_AFFECTED is 1 but isn't part of the SMCCC spec
> 
> Cc: Andre Przywara <andre.przywara at arm.com>
> Cc: Steven Price <steven.price at arm.com>
> Cc: Marc Zyngier <maz at kernel.org>
> Cc: stable at vger.kernel.org
> Link: https://developer.arm.com/documentation/den0028/latest [1]
> Fixes: c118bbb52743 ("arm64: KVM: Propagate full Spectre v2 workaround state to KVM guests")
> Signed-off-by: Stephen Boyd <swboyd at chromium.org>
> ---
> 
> I see that before commit c118bbb52743 ("arm64: KVM: Propagate full
> Spectre v2 workaround state to KVM guests") we had this mapping:
> 
>  0 is SPECTRE_MITIGATED
>  SMCCC_RET_NOT_SUPPORTED is SPECTRE_VULNERABLE
> 
> so the return value '1' wasn't there then. Once the commit was merged we
> introduced the notion of NOT_REQUIRED here when it shouldn't have been
> introduced.
> 
> Changes from v2:
>  * Moved define to header file and used it
> 
> Changes from v1:
>  * Way longer commit text, more background (sorry)
>  * Dropped proton-pack part because it was wrong
>  * Rebased onto other patch accepted upstream
> 
>  arch/arm64/kernel/proton-pack.c | 2 --
>  arch/arm64/kvm/hypercalls.c     | 2 +-
>  include/linux/arm-smccc.h       | 2 ++
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/kernel/proton-pack.c b/arch/arm64/kernel/proton-pack.c
> index 25f3c80b5ffe..c18eb7d41274 100644
> --- a/arch/arm64/kernel/proton-pack.c
> +++ b/arch/arm64/kernel/proton-pack.c
> @@ -135,8 +135,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;
> diff --git a/arch/arm64/kvm/hypercalls.c b/arch/arm64/kvm/hypercalls.c
> index 9824025ccc5c..25ea4ecb6449 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_ARCH_WORKAROUND_RET_UNAFFECTED;
>  				break;
>  			}
>  			break;
> diff --git a/include/linux/arm-smccc.h b/include/linux/arm-smccc.h
> index 15c706fb0a37..0e50ba3e88d7 100644
> --- a/include/linux/arm-smccc.h
> +++ b/include/linux/arm-smccc.h
> @@ -86,6 +86,8 @@
>  			   ARM_SMCCC_SMC_32,				\
>  			   0, 0x7fff)
>  
> +#define SMCCC_ARCH_WORKAROUND_RET_UNAFFECTED	1

I thought we'd stick this in asm/spectre.h, but here is also good:

Acked-by: Will Deacon <will at kernel.org>

Will



More information about the linux-arm-kernel mailing list