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

[Marc Zyngier]

On Wed, 16 Sep 2026 20:07:28 +0100,
Fuad Tabba <fuad.tabba@xxxxxxxxx> wrote:
> 
> Hi Marc,
> 
> On Wed, 16 Sept 2026 at 17:30, Marc Zyngier <maz@xxxxxxxxxx> wrote:
> [...]
> > > diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c
> [...]
> > > +/*
> > > + * Once a protected vCPU has run, the host copy is not the guest's state,
> > > + * and EL2 has read mp_state, which it does only at hyp vCPU creation.
> > > + */
> > > +static long pkvm_filter_vcpu_ioctl(struct kvm_vcpu *vcpu, unsigned int ioctl)
> > > +{
> > > +        switch (ioctl) {
> > > +        case KVM_ARM_VCPU_INIT:
> > > +        case KVM_SET_ONE_REG:
> > > +        case KVM_GET_ONE_REG:
> > > +                if (vcpu_is_protected(vcpu) && vcpu_has_run_once(vcpu))
> > > +                        return -EPERM;
> > > +        }
> > > +
> > > +        return 0;
> > > +}
> > > +
> >
> > I'm not keen on returning -EPERM for the ONE_REG stuff. For a start,
> > X0 *is* valid on MMIO, and when you want to support LD64B and co,
> > you'll need to show the actual data there.
> >
> > I'd rather return what is in the host vcpu structure, as normal.
> 
> I think we should keep the error, for the reason s390 returns -EINVAL
> from ONE_REG on a protected vCPU and x86 does from the register ioctls
> for protected VM types:

News flash, this is not x86, nor s390. I don't feel constrained by
other architecture, and we deviate *everywhere* already.

> 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 don't want to have to revisit the userspace interface once you have
to relax it, because I know for sure that you will have to.

As far as LD64B is concerned, there is no place to copy anything in
the run structure, and the relaxation would require to cover all the
GPRs, ESR, and FAR. At this stage, returning whatever is there is the
correct thing to do IMO.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.