linux-kernel - Re: [PATCH v15 3/6] KVM: arm64: Forward GCS exceptions to nested guests

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <87ldndk5c2.wl-maz@kernel.org>
Date: Wed, 20 Aug 2025 23:15:25 +0100
From: Marc Zyngier <maz@...nel.org>
To: Mark Brown <broonie@...nel.org>
Cc: Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>,
	Oliver Upton <oliver.upton@...ux.dev>,
	Joey Gouly <joey.gouly@....com>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Shuah Khan <shuah@...nel.org>,
	linux-arm-kernel@...ts.infradead.org,
	linux-doc@...r.kernel.org,
	kvmarm@...ts.linux.dev,
	linux-kselftest@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v15 3/6] KVM: arm64: Forward GCS exceptions to nested guests

On Wed, 20 Aug 2025 15:14:43 +0100,
Mark Brown <broonie@...nel.org> wrote:
> 
> GCS can generate exceptions with an EC of 0x2D (GCS Data Check
> Exception) when data validation checks fail.  When running a nested
> guest which has access to GCS such exceptions can be directed from EL0
> to EL2 and therefore need to be forwarded to the guest hypervisor, add
> handling for this.

Why is it so? A GCS exception from EL0 should be routed to EL1, no
matter what (either this is an L1 guest with EL1 pretending to be EL2,
or this is an L2 guest that has its own EL1).

Can you describe the case where we need to reinject the exception?

>
> Signed-off-by: Mark Brown <broonie@...nel.org>
> ---
>  arch/arm64/kvm/handle_exit.c | 14 +++++++++++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/kvm/handle_exit.c b/arch/arm64/kvm/handle_exit.c
> index a598072f36d2..2f5aef84b294 100644
> --- a/arch/arm64/kvm/handle_exit.c
> +++ b/arch/arm64/kvm/handle_exit.c
> @@ -301,10 +301,18 @@ static int handle_svc(struct kvm_vcpu *vcpu)
>  
>  static int kvm_handle_gcs(struct kvm_vcpu *vcpu)
>  {
> -	/* We don't expect GCS, so treat it with contempt */
> -	if (kvm_has_feat(vcpu->kvm, ID_AA64PFR1_EL1, GCS, IMP))
> -		WARN_ON_ONCE(1);
> +	if (!kvm_has_gcs(vcpu->kvm)) {
> +		kvm_inject_undefined(vcpu);
> +		return 1;
> +	}
>  
> +	if (vcpu_has_nv(vcpu) && !is_hyp_ctxt(vcpu)) {

We now have is_nested_ctxt(), which is more obvious.

> +		kvm_inject_nested_sync(vcpu, kvm_vcpu_get_esr(vcpu));
> +		return 1;
> +	}
> +
> +	/* We shouldn't have generated a trap in this case */
> +	WARN_ON_ONCE(1);
>  	kvm_inject_undefined(vcpu);
>  	return 1;
>  }
> 

Thanks,

	M.

-- 
Jazz isn't dead. It just smells funny.