[svsm-devel] Potential project on implementing AMD SEV emulation in QEMU
Daniel P. Berrangé
berrange at redhat.com
Tue Apr 22 09:56:51 CEST 2025
On Fri, Apr 18, 2025 at 10:31:57AM +0200, Stefano Garzarella wrote:
> Hi Tom,
>
> On Thu, 17 Apr 2025 at 22:14, Tom Lendacky <thomas.lendacky at amd.com> wrote:
> >
> > On 4/17/25 10:26, Stefano Garzarella wrote:
> > > Hi Tom,
> >
> > Hi Stefano,
> >
> > > yesterday in the Coconut-SVSM community call we talked about a
> > > potential project with the University of Pisa to emulate AMD
> > > SEV/SEV-ES/SEV-SNP support in QEMU.
> > >
> > > Joerg rightly suggested having a step-by-step approach, supporting SEV
> > > initially, as supporting SEV-SNP directly might be too much for a
> > > master's thesis (about 6 months of work).
> > >
> > > We wondered if you knew of any attempts already made in this regard,
> >
> > Nothing that I'm aware of.
> >
> > > but especially if you think it's a feasible thing.
> >
> > Anything is possible I guess, but I'm not sure what it would take to
> > accomplish that. Attestation would tell you if you're on real hardware
> > vs emulated hardware.
>
> As I wrote to Dionna, I did not explain the ultimate goal well:
> Test/develop SVSM and guest OS interaction without having the hardware in place.
>
> So that's why IMO it's perfectly fine for attestation to be
> unsuccessful, plus I don't think it's even necessary to implement any
> encryption.
IMHO attestation is required to make this fully usable even for SVSM
dev. eg consider the work underway for persistent vTPM, which relies
on attestation during SVSM. It would also be required for any of the
guest OS / application layer to test/devel SEV(SNP) support fully.
I would consider attestation in scope for any QEMU impl, but I agree
that encryption of memory is not likely a priority.
With regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
More information about the Svsm-devel
mailing list