Re: [PATCH v2 2/6] KVM: selftests: Add a test to verify SEV {en,de}crypt debug ioctls

[Sean Christopherson <seanjc@google.com>]

On Thu, Jul 23, 2026, Michael Roth wrote:
> On Thu, Jul 23, 2026 at 05:17:26PM +0200, Paolo Bonzini wrote:
> > > > > I don't see a way to salvage SEV/SEV-ES on SNP systems, short of requiring
> > > > > CAP_SYS_BOOT or some other elevated permission to do *anything*.  Or redo SEV/SEV-ES
> > > > > support to require guest_memfd for operations that require putting pages into
> > > > > Firmware state.
> > > > 
> > > > Yah, short of maybe the above approach, I don't see any way around it atm :(
> > > > If you think it's worth pursuing though I can give that a shot on my
> > > > end.
> > 
> > The unavoidable ones include, if I understand correctly, not just
> > DBG_ENCRYPT but also LAUNCH_UPDATE_DATA?
> 
> That was my understanding, e.g. a user could try to use the HVA to
> trigger the copy_file_range() path right after
> snp_map_cmd_buf_desc()->rmp_mark_pages_firmware() is performed as
> part of servicing the KVM_SEV_LAUNCH_UPDATE_DATA request, and it seems
> like that would trigger the same issue. And bounce buffers wouldn't work
> for that one either.
> 
> and it's kinda important =/
> 
> > For encrypt the destination is the guest memory, so how would adding
> > guest_memfd support for SEV/SEV-ES work?  The guest doesn't have a
> > page-state-change call and neither does it have RMP nested page faults, so
> > how would you communicate the private<->shared switch to userspace?

Yeah, I was spitballing, I don't think guest_memfd has a viable path forward.  

> During early SNP hypervisor development (when guest_memfd was called
> "restricted_mem"), the patches were actually based on top of some patches
> from Nikunj that added guest_memfd/restricted_mem support for SEV-ES.
> One nice thing about that is it brought about support for lazy page
> allocation instead of relying on KVM_MEMORY_ENCRYPT_REG_REGION.
> 
> The support piggybacks off the KVM_HC_MAP_GPA RANGE hypercall that was
> added on the guest side to enable SEV live migration so the VMM could
> distinguish between shared/private (and punt private page handling to
> something else). By coincedence, that's also what SNP/TDX ended up using
> to forward conversion requests to userspace.
> 
> However, since SEV live migration never became a thing upstream there's
> potential that the KVM_HC_MAP_GPA_RANGE handling might miss some of the
> newer cases, which would lead to silent corruption (though with SNP
> enabled we might still get an indicator of whether or not the guest had
> the C-bit set, so we could detect a mismatch that way and maybe even
> be able to handle implicit conversion requests).
> 
> The big issue with this approach though is hugepages: we'd be dropping
> existing SEV support for both hugetlb/THP unless we implemented in-place
> conversion support for SEV-ES so it could eventually benefit from the
> hugetlb patches at least, but if in the meantime it's 4K-only I'm not
> sure anyone is going to get much use out of that, or still care about
> this support when gmem+hugepages is eventually enabled.
> 
> > 
> > > I say we wait for Paolo to get back from holiday (in a few weeks) before doing
> > > anything drastic.  I'll send a patch to fix the existing selftest though, no
> > > reason to leave that hole open.
> > 
> > Well, everything is drastic.  "Fortunately" AMD helped us with the firmware
> > update that already hides SEV-ES on SNP machines (CVE-2025-48514), so at
> > least there's a precedent.
> > 
> > Could we say CAP_SYS_BOOT is only be required to create the VM, after which
> > it's up to userspace to not screw up?  Probably not, because userspace can
> > then drop privileges and operate on the file descriptor; which is the actual
> > dangerous part.

Hmm, but there may be a path forward with CAP_SYS_BOOT.  It might require some
heavy lifting in userspace, but IIRC, LAUNCH_FINISH is typically called before
doing KVM_RUN on any vCPU.  So while it's not simply KVM_CREATE_VM, I do think
that "users" that care deeply enough about security/stability could implement a
VM builder that runs with elevated privileges, and then drops priveleges (or hands
off the VM) to actually run the guest.

> > The only not-horrible alternative would be a default-disabled module
> > parameter that allows SEV/SEV-ES on SNP systems but adds TAINT_USER when you
> > create one.  And downstreams that don't like the idea can just rip out the
> > taint.

What if we have the module param require CAP_SYS_BOOT for the affected iotcls?
Then TAINT_USER if it's disabled.  That way, if someone is sufficiently motivated
to harden their runtime-VMM, they can implement the builder without having to
manually remove the taint, and without having to completely trust the VMM (because
it's more than just a potential DoS; I wouldn't be at all surprised if someone
can turn this in a local privilege escalation).

> It might not be as elegant, but either of these seems more useful as a means
> to allow users to continue to be able to run existing workloads if they
> trust their userspace/VMMs. I'm worried the guest_memfd support would end up
> being mostly-wasted effort at this point since it's not a
> straightforward/drop-in replacement.