Re: [PATCH 1/2] KVM: arm64: Flush external_mdscr_el1 to the pKVM hyp vCPU

[sashiko-bot@kernel.org]

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

New issues:
- [Critical] The patch breaks pKVM guest isolation by allowing the host to arm hardware debug exceptions against a protected VM.

Pre-existing issues:
- [Critical] The hypervisor unconditionally copies trap configurations and debug states between the untrusted host and the protected VM on every entry and exit, violating pKVM state isolation and confidentiality.
--

--- Patch [1]: [PATCH 1/2] KVM: arm64: Flush external_mdscr_el1 to the pKVM hyp vCPU ---
commit 11c3469e00f567f8f8ae658ca753847976608a5d
Author: Fuad Tabba <fuad.tabba@linux.dev>

KVM: arm64: Flush external_mdscr_el1 to the pKVM hyp vCPU

This commit propagates the external_mdscr_el1 register state to the pKVM
hyp vCPU during flush_debug_state(). This ensures that a non-protected guest
runs with the correct hardware flags set by the host.

> diff --git a/arch/arm64/kvm/hyp/nvhe/hyp-main.c b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> --- a/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> +++ b/arch/arm64/kvm/hyp/nvhe/hyp-main.c
> @@ -108,10 +108,16 @@ static void flush_debug_state(struct pkvm_hyp_vcpu *hyp_vcpu)
>  
>  	hyp_vcpu->vcpu.arch.debug_owner = host_vcpu->arch.debug_owner;

[Severity: Critical]
This is a pre-existing issue, but does this allow the host to hijack debug
ownership for a protected VM?

The hypervisor unconditionally copies the untrusted host's debug_owner here
on every guest entry.

Additionally, similar unconditional copying occurs for trap configurations 
and debug states from the host structure:

arch/arm64/kvm/hyp/nvhe/hyp-main.c:flush_hyp_vcpu() {
    ...
    hyp_vcpu->vcpu.arch.mdcr_el2 = host_vcpu->arch.mdcr_el2;
    ...
}

And on guest exit, state is copied back out to the host:

arch/arm64/kvm/hyp/nvhe/hyp-main.c:sync_debug_state() {
    ...
    if (kvm_guest_owns_debug_regs(&hyp_vcpu->vcpu))
        host_vcpu->arch.vcpu_debug_state = hyp_vcpu->vcpu.arch.vcpu_debug_state;
    ...
}

Could this allow the host to reconfigure the protected guest's execution
environment via mdcr_el2, and leak private hardware debug register state 
back to the untrusted host?

> -	if (kvm_guest_owns_debug_regs(&hyp_vcpu->vcpu))
> +	if (kvm_guest_owns_debug_regs(&hyp_vcpu->vcpu)) {
>  		hyp_vcpu->vcpu.arch.vcpu_debug_state = host_vcpu->arch.vcpu_debug_state;
> -	else if (kvm_host_owns_debug_regs(&hyp_vcpu->vcpu))
> +	} else if (kvm_host_owns_debug_regs(&hyp_vcpu->vcpu)) {
>  		hyp_vcpu->vcpu.arch.external_debug_state = host_vcpu->arch.external_debug_state;
> +		/*
> +		 * The world switch loads MDSCR_EL1 from external_mdscr_el1
> +		 * (ctxt_mdscr_el1()).
> +		 */
> +		hyp_vcpu->vcpu.arch.external_mdscr_el1 = host_vcpu->arch.external_mdscr_el1;

[Severity: Critical]
Is this a regression that breaks pKVM guest isolation by allowing the host to 
arm hardware debug exceptions against a protected VM?

By copying external_mdscr_el1 from the untrusted host to the EL2 private
state unconditionally, a malicious host could populate external_mdscr_el1
with debug flags (e.g., MDE=1 and SS=1) prior to KVM_RUN.

The world switch would then load these host-controlled values directly into 
the hardware MDSCR_EL1 register. Under the pKVM threat model, could this 
allow the host to intercept execution, extract register state, and modify 
control flow of a protected VM?

> +	}
>  }

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