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

[Marc Zyngier <maz@kernel.org>]

Hi Will,

Sorry for the delay replying, I'm catching up on email between
travels...

On Fri, 18 Sep 2026 14:21:31 +0100,
Will Deacon <will@kernel.org> wrote:
> 
> Hi Marc, Fuad,

[...]

> > > > 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 just wanted to chuck my thoughts in here, as some of this is my fault
> and it would be really helpful to discuss it on the list. As you probably
> know, on Android, pKVM has the semantics you describe above: the ONE_REG
> calls succeed, but the register state isn't propagated to the guest once
> it's started running. I think we largely did it this way because we were
> solving a million problems at once during the initial development and
> having to pipe-clean VMMs wasn't particularly appealing at the time.
> It's also worth adding that, to my knowledge, we've never had any issues
> in Android because of this decision.
> 
> So, based on that, it really sounds like it's the best option. If it ain't
> broke, don't fix it!
> 
> *However*, I can't think of another upstream interface that behaves like
> that and, when we came to document it, it was quite difficult to explain
> it in a way that could be extended in the future. If we say that ONE_REG
> doesn't propagate to the vCPU after first run and returns whatever was
> last written, then userspace could (even accidentally) rely on that. If
> we wanted to extend it, I think we'd not only need a method to advertise
> the new behaviour (which I think you probably want even if ONE_REG
> returned an error before) but also an opt-in for userspace to say that
> it's ok with the new behaviour. In some ways, it feels a bit like the
> "unchecked flags" problem for syscall arguments.

My take on this is that by asking for a protected VM, userspace has
already acknowledged that it may not be able to access the guest state
at all, and that trying to access it could result in stale data being
obtained.

For example, we don't have any particular "buy-in" for the anonymous
memory that the guest has mapped and that userspace then tries to
access. We don't slap it on the wrist, but instead give it a page full
of zeroes.

[...]

> > > 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.

But this is introducing unnecessary friction for userspace to support
pKVM/CCA/whatever hypervisors.

> 
> In our recent investigation, it turned out that both kvmtool and crosvm
> were perfectly happy with ONE_REG returning an error in normal operation
> but we needed a handful of fixes for kvmtool [1] to handle things like
> the 'debug' command.
> 
> 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 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.
> 
> I think we'll have to do that either way, no? The VMM needs a way to
> know that ONE_REG works and the situations in which it works. If the old
> behaviour wasn't to return an error, it's also going to need a way to
> enable the new behaviour.

As above: my take is that this is being covered by creating a
protected VM. But let's find out from the VMM folks what behaviour
they prefer. After all, they have to deal with this...

Thanks,

	M.

-- 
Jazz isn't dead. It just smells funny.