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

[Michael Roth]

On Thu, Jul 23, 2026 at 05:17:26PM +0200, Paolo Bonzini wrote:
> On 6/25/26 02:25, Sean Christopherson wrote:
> > On Wed, Jun 24, 2026, Michael Roth wrote:
> > > So maybe the bounce buffer approach would work for DBG_DECRYPT at
> > > least,
> > 
> > Yeah, DECRYPT worked fine, it's all the others that break.
> > 
> > > > pread() doesn't work, because the source or destination needs to be a userspace
> > > > address, and so any RMP #PFs will get eaten.  But copy_file_range() makes the
> > > > world go kablooie.
> > 
> > And the risk isn't limited to copy_file_range(), that just happens to be the first
> > syscall I found that did what I want.  E.g. any memory that is kernel allocated
> > and mapped into userspace would be problematic, because that memory could be fed
> > back into KVM.
> > 
> > So I don't think we can fix this by playing games in KVM.  Which is pretty much
> > why we ended up with guest_memfd: the only way to lock down memory to the point
> > where we're 100% certain it's safe to "poison" the pages is if KVM sequesters
> > them away in a dedicated file system.
> 
> Yes, I agree that it's basically the same issue that led to using
> guest_memfd for SNP.  Another one would be io_submit().
> 
> > > > I'm fairly certain the issue is that the encryption is salted with the physical
> > > > address, and so encrypting at X instead of Y will yield different ciphertext.
> > > > I.e. any command that encrypts the contents in the destination (or in theory,
> > > > decrypts, though AFAICT none of the commands do so) *can't* be bounce buffered.
> 
> Yep. :/
> 
> > > > 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?

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

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.

-Mike

> 
> Paolo
>