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

On Sun, 26 Jul 2026 at 15:54, <[email protected]> wrote:
>
> 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.

For both issues, protected VM state isolation is WIP upstream [1],
coming soon (fingers crossed).

/fuad

[1] https://lore.kernel.org/all/[email protected]/

> --
>
> --- Patch [1]: [PATCH 1/2] KVM: arm64: Flush external_mdscr_el1 to the pKVM hyp vCPU ---
> commit 11c3469e00f567f8f8ae658ca753847976608a5d
> Author: Fuad Tabba <[email protected]>
>
> 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/[email protected]?part=1