[svsm-devel] Potential project on implementing AMD SEV emulation in QEMU

[Daniel P. Berrangé]

On Tue, Apr 22, 2025 at 12:32:18PM +0200, Stefano Garzarella wrote:
> On Tue, Apr 22, 2025 at 08:56:51AM +0100, Daniel P. Berrangé wrote:
> > 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.
> 
> Yeah, I agree with that, by “unsuccessful attestation” I meant that it is
> perfectly fine for the attestation process to tell you that you are not on a
> real hw, but emulated.
> 
> Anyway, I agree that we should emulate the generation of the attestation
> report, obviously signed with a self-generated certificate (or even
> unsigned, but I don't know if this is expected).

Yep, attestation should be able to work, provided applications that validate
attestation reports have a way to configure an alternative root certs instead
of AMD's genuine ones.


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