[PATCH 1/2] KVM: arm64: Sync HCR_EL2.VSE back to the host vCPU under pKVM

[PATCH 1/2] KVM: arm64: Sync HCR_EL2.VSE back to the host vCPU under pKVM

[Fuad Tabba]

flush_hyp_vcpu() copies HCR_EL2.VSE from the host vCPU into the hyp
vCPU on every entry, and nothing copies it back. Once the guest takes
the vSError the hyp vCPU's copy clears with the hardware bit while the
host's stays set, so the next entry pends the same SError again,
KVM_GET_VCPU_EVENTS keeps reporting it, and kvm_arch_vcpu_runnable()
never lets the vCPU block in WFI.

Reflect VSE back on every exit, which the flush-side comment already
promises.

Fixes: 734dc8c01c838 ("KVM: arm64: Implement lazy vCPU state sync for non-protected guests")
Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---
 arch/arm64/kvm/hyp/nvhe/hyp-main.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
index 65a7c735aa398..be35ff5958c82 100644
--- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
+++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
@@ -276,6 +276,10 @@ static void sync_hyp_vcpu(struct pkvm_hyp_vcpu *hyp_vcpu)
 
 	host_vcpu->arch.iflags		= hyp_vcpu->vcpu.arch.iflags;
 
+	/* Cleared by hardware once the guest takes the vSError. */
+	host_vcpu->arch.hcr_el2 &= ~HCR_VSE;
+	host_vcpu->arch.hcr_el2 |= hyp_vcpu->vcpu.arch.hcr_el2 & HCR_VSE;
+
 	sync_hyp_vgic_state(hyp_vcpu);
 }
 

base-commit: aa8e5dc6a7a2a1141ab40706a51010adcd0e57d2
-- 
2.39.5

[PATCH 2/2] KVM: arm64: selftests: Check SError is not pending after delivery

[Fuad Tabba]

test_serror() never looks at the vCPU after the SError is delivered, so
a stale pending SError goes unnoticed. Read the vCPU events back and
check the SError is no longer pending.

Signed-off-by: Fuad Tabba <fuad.tabba@linux.dev>
---
 tools/testing/selftests/kvm/arm64/external_aborts.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/tools/testing/selftests/kvm/arm64/external_aborts.c b/tools/testing/selftests/kvm/arm64/external_aborts.c
index d8fe17a6cc592..b276a4998a92c 100644
--- a/tools/testing/selftests/kvm/arm64/external_aborts.c
+++ b/tools/testing/selftests/kvm/arm64/external_aborts.c
@@ -239,6 +239,7 @@ static void test_serror_guest(void)
 
 static void test_serror(void)
 {
+	struct kvm_vcpu_events events;
 	struct kvm_vcpu *vcpu;
 	struct kvm_vm *vm = vm_create_with_dabt_handler(&vcpu, test_serror_guest,
 							unexpected_dabt_handler);
@@ -247,6 +248,11 @@ static void test_serror(void)
 
 	vcpu_inject_serror(vcpu);
 	vcpu_run_expect_done(vcpu);
+
+	vcpu_events_get(vcpu, &events);
+	TEST_ASSERT(!events.exception.serror_pending,
+		    "SError still pending after the guest took it");
+
 	kvm_vm_free(vm);
 }
 
-- 
2.39.5

Re: [PATCH 1/2] KVM: arm64: Sync HCR_EL2.VSE back to the host vCPU under pKVM

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:

Pre-existing issues:
- [Critical] pKVM unconditionally leaks and overwrites protected guest context (including general purpose registers, system registers, and trap configuration) to and from the untrusted host on every guest entry/exit.
--

commit 4f524814ed8b14fca5b29ea5c6eacae85dfdeb56
Author: Fuad Tabba <fuad.tabba@linux.dev>

KVM: arm64: Sync HCR_EL2.VSE back to the host vCPU under pKVM

This commit ensures that the HCR_EL2.VSE bit is synchronized from the hyp
vCPU back to the host vCPU on guest exit under pKVM. It prevents the same
virtual SError from being pended repeatedly.

> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> index 65a7c735aa398..be35ff5958c82 100644
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> @@ -276,6 +276,10 @@ static void sync_hyp_vcpu(struct pkvm_hyp_vcpu *hyp_vcpu)
>  
>  	host_vcpu->arch.iflags		= hyp_vcpu->vcpu.arch.iflags;
>  
> +	/* Cleared by hardware once the guest takes the vSError. */
> +	host_vcpu->arch.hcr_el2 &= ~HCR_VSE;
> +	host_vcpu->arch.hcr_el2 |= hyp_vcpu->vcpu.arch.hcr_el2 & HCR_VSE;
> +

[Severity: Critical]
This is a pre-existing issue, but does this code unconditionally leak and
overwrite protected guest context to and from the untrusted host on every
guest entry and exit?

In sync_hyp_vcpu(), just above the lines added here, the code copies the
confidential guest context back into host memory:

    if (pkvm_hyp_vcpu_is_protected(hyp_vcpu)) {
        host_vcpu->arch.ctxt = hyp_vcpu->vcpu.arch.ctxt;

This appears to leak protected guest register state to the host on each exit.

Additionally, on the entry path in flush_hyp_vcpu(), the untrusted host
context completely overwrites the protected guest's context:

    hyp_vcpu->vcpu.arch.ctxt = host_vcpu->arch.ctxt;

It also seems to allow the host to inject its own debug trap configuration:

    hyp_vcpu->vcpu.arch.mdcr_el2 = host_vcpu->arch.mdcr_el2;

Could this allow the untrusted host EL1 to read and write all protected
guest registers and inject debug traps, breaking the pKVM threat model
guarantee that host EL1 cannot read or modify protected-VM memory or
register state?

>  	sync_hyp_vgic_state(hyp_vcpu);
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260829071120.2522788-1-fuad.tabba@linux.dev?part=1

Re: [PATCH 1/2] KVM: arm64: Sync HCR_EL2.VSE back to the host vCPU under pKVM

[Fuad Tabba]

On Sat, 29 Aug 2026 at 08:21, <sashiko-bot@kernel.org> wrote:
>
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>
> Pre-existing issues:
> - [Critical] pKVM unconditionally leaks and overwrites protected guest context (including general purpose registers, system registers, and trap configuration) to and from the untrusted host on every guest entry/exit.

Coming soon Sashiko, I promise. This is in preparation for that.

Cheers,
/fuad

PS. I've been preparing for you...
> --
>
> commit 4f524814ed8b14fca5b29ea5c6eacae85dfdeb56
> Author: Fuad Tabba <fuad.tabba@linux.dev>
>
> KVM: arm64: Sync HCR_EL2.VSE back to the host vCPU under pKVM
>
> This commit ensures that the HCR_EL2.VSE bit is synchronized from the hyp
> vCPU back to the host vCPU on guest exit under pKVM. It prevents the same
> virtual SError from being pended repeatedly.
>
> > diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > index 65a7c735aa398..be35ff5958c82 100644
> > --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> > @@ -276,6 +276,10 @@ static void sync_hyp_vcpu(struct pkvm_hyp_vcpu *hyp_vcpu)
> >
> >       host_vcpu->arch.iflags          = hyp_vcpu->vcpu.arch.iflags;
> >
> > +     /* Cleared by hardware once the guest takes the vSError. */
> > +     host_vcpu->arch.hcr_el2 &= ~HCR_VSE;
> > +     host_vcpu->arch.hcr_el2 |= hyp_vcpu->vcpu.arch.hcr_el2 & HCR_VSE;
> > +
>
> [Severity: Critical]
> This is a pre-existing issue, but does this code unconditionally leak and
> overwrite protected guest context to and from the untrusted host on every
> guest entry and exit?
>
> In sync_hyp_vcpu(), just above the lines added here, the code copies the
> confidential guest context back into host memory:
>
>     if (pkvm_hyp_vcpu_is_protected(hyp_vcpu)) {
>         host_vcpu->arch.ctxt = hyp_vcpu->vcpu.arch.ctxt;
>
> This appears to leak protected guest register state to the host on each exit.
>
> Additionally, on the entry path in flush_hyp_vcpu(), the untrusted host
> context completely overwrites the protected guest's context:
>
>     hyp_vcpu->vcpu.arch.ctxt = host_vcpu->arch.ctxt;
>
> It also seems to allow the host to inject its own debug trap configuration:
>
>     hyp_vcpu->vcpu.arch.mdcr_el2 = host_vcpu->arch.mdcr_el2;
>
> Could this allow the untrusted host EL1 to read and write all protected
> guest registers and inject debug traps, breaking the pKVM threat model
> guarantee that host EL1 cannot read or modify protected-VM memory or
> register state?
>
> >       sync_hyp_vgic_state(hyp_vcpu);
> >  }
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260829071120.2522788-1-fuad.tabba@linux.dev?part=1