Re: [PATCH] KVM: SEV: Return INVALID_INPUT on SNP req/resp buffer access failure

[Jacky Li]

On Tue, Sep 15, 2026 at 8:21 AM Tom Lendacky <thomas.lendacky@xxxxxxx> wrote:
>
> On 9/15/26 09:31, Sean Christopherson wrote:
> > What if we keep this one as -EIO (or better, change it to -EFAULT in a separate
> > patch?), but add a comment explaning why KVM needs to exit to userspace in this
> > particular case?  That would be a good compromise; if the guest is attempting to
> > access non-existent memory, the initial READ will fail, i.e. we still get most
> > of the behavior Jacky wants.  The only fatal case would be where either userspace
> > really did screw up, or the guest managed to find read-only memory (though I
> > would probably argue that's likely also a userspace bug?).
>
> That sounds good to me.

Thinking through the sequence number and VMM bug concerns, I'd still argue
that returning INVALID_INPUT on kvm_write_guest() failure is preferable to
exiting to userspace:

1. req_gpa and resp_gpa are two independent guest inputs, so a guest can pass
   a valid req_gpa and a resp_gpa that isn't backed by any memslot to sail
   through the initial read and fail only on the write.  Exiting to userspace
   on write failure therefore still lets a guest kill the VM at will.

2. Comparing the two outcomes after a kvm_write_guest() failure:

   - Case 1 (exit to userspace with -EFAULT/-EIO): unrecoverable.  The PSP's
     response is lost, and userspace can't rewind the PSP's sequence number,
     so retrying KVM_RUN would just fail that check.  There is nothing
     userspace can do other than kill the VM.

   - Case 2 (return INVALID_INPUT to the guest): the guest disables the VMPCK
     and moves on to the next one, as Tom mentioned.  The worst case, once all
     four VMPCKs are exhausted, is that the guest can no longer issue guest
     requests, but the VM keeps running.

   Neither is ideal, but Case 2 seems to be better: a localized loss of
   functionality instead of the entire VM dying over a single bad request.
   It also leaves the decision to the guest, which can carry on with whatever
   doesn't depend on attestation, wind down cleanly, and shut itself down on
   its own terms instead of being killed abruptly.

3. More generally, when KVM can't tell a guest error apart from a VMM bug at a
   hypercall boundary, reporting the error to the guest seems to be the safer
   default: failing the guest request degrades one service while keeping the
   VM alive and debuggable, whereas exiting to userspace turns a single failed
   request into a dead VM, and hands an untrusted guest a way to terminate it.

   And in the context of SNP the guest doesn't trust the VMM anyway, so a VMM
   that fails to deliver a response is indistinguishable from one that refuses
   to, and the guest already deals with that by disabling the VMPCK on a
   VMGEXIT error.  Letting a host problem bleed into the guest is arguably
   "fine" here, since the guest is designed to cope with it regardless.