From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Stefano Garzarella <sgarzare@redhat.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>,
coconut-svsm@lists.linux.dev, svsm-devel@coconut-svsm.dev
Subject: Re: [svsm-devel] Potential project on implementing AMD SEV emulation in QEMU
Date: Tue, 22 Apr 2025 08:56:51 +0100 [thread overview]
Message-ID: <aAdLw-1y-Zcz7mme@redhat.com> (raw)
In-Reply-To: <CAGxU2F7=TuWMrbUAE0fqwfpb4A82pNqtaf63Fq59P=7h6U8tdQ@mail.gmail.com>
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@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 :|
next prev parent reply other threads:[~2025-04-22 7:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-17 15:26 Potential project on implementing AMD SEV emulation in QEMU Stefano Garzarella
2025-04-17 16:08 ` Dionna Amalie Glaze
2025-04-18 8:12 ` Stefano Garzarella
2025-04-17 20:14 ` Tom Lendacky
2025-04-18 8:31 ` Stefano Garzarella
2025-04-22 7:56 ` Daniel P. Berrangé [this message]
2025-04-22 10:32 ` [svsm-devel] " Stefano Garzarella
2025-04-22 10:35 ` Daniel P. Berrangé
2025-04-22 7:52 ` Daniel P. Berrangé
2025-04-22 10:45 ` Stefano Garzarella
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aAdLw-1y-Zcz7mme@redhat.com \
--to=berrange@redhat.com \
--cc=coconut-svsm@lists.linux.dev \
--cc=sgarzare@redhat.com \
--cc=svsm-devel@coconut-svsm.dev \
--cc=thomas.lendacky@amd.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.