Re: [PATCH v3 15/18] KVM: arm64: Reject host access to protected VM private state

[Fuad Tabba]

Hi Marc, Will,

On Sun, 27 Sept 2026 at 09:17, Marc Zyngier <maz@xxxxxxxxxx> wrote:
[...]
> > > > once the vCPU has run, the copy is the VMM's
> > > > boot state plus what the exit handlers copy out, and the VMM can't
> > > > distinguish them. x0 on MMIO is one of those fields, but the VMM reads
> > > > it from kvm_run->mmio. For LD64B, EL2 would copy the operands out the
> > > > same way and the error could be relaxed to those registers. Loosening
> > > > later breaks nobody. The comment and the message do overstate it by
> > > > calling the copy "not the guest's state", and I'll reword both in v4.
> > > > More on the kvmtool thread [1].
> > >
> > > A protected-aware VMM already knows it cannot obtain the registers.
> >
> > I think you can use that argument both ways: if the VMM knows it cannot
> > obtain the registers, then it's fine to return an error if the VMM does
> > something wrong.
[...]
> > If it's helpful, we can ask the crosvm developers here if they have
> > opinions for/against the two behaviours?
>
> I guess that'd be useful to know what they'd prefer, and also to look
> into what QEMU does in this case -- I'm not exactly a good judge when
> it comes to UAPI definition... ;-)

I asked Frederick Mayle (CC'ed, AVF/pKVM support in crosvm) about what
they think in crosvm. Their preference is an error rather than a
silent failure: an explicit failure is easier to debug, and the
earlier the error surfaces, the easier it is to correlate with the
misbehaviour. Frederick also raised the MMIO case as a concrete risk
of the silent option: a VMM could reasonably think it can complete an
MMIO access with SET_ONE_REG and never find out that it was a no-op.

Cheers,
/fuad