Potential project on implementing AMD SEV emulation in QEMU

Potential project on implementing AMD SEV emulation in QEMU

[Stefano Garzarella]

Hi Tom,
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,
but especially if you think it's a feasible thing.

Suggestions, ideas or partial works that can be reused are very welcome!

Thanks,
Stefano

Re: Potential project on implementing AMD SEV emulation in QEMU

[Dionna Amalie Glaze]

What do you mean by emulate? Fake the MSRs and CPUID, or actually
provide some memory protection value like the pKVM project?

On Thu, Apr 17, 2025 at 8:26 AM Stefano Garzarella <sgarzare@redhat.com> wrote:
>
> Hi Tom,
> 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,
> but especially if you think it's a feasible thing.
>
> Suggestions, ideas or partial works that can be reused are very welcome!
>
> Thanks,
> Stefano
>
>


-- 
-Dionna Glaze, PhD, CISSP, CCSP (she/her)

Re: Potential project on implementing AMD SEV emulation in QEMU

[Tom Lendacky]

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.

Thanks,
Tom

> 
> Suggestions, ideas or partial works that can be reused are very welcome!
> 
> Thanks,
> Stefano
> 

Re: Potential project on implementing AMD SEV emulation in QEMU

[Stefano Garzarella]

On Thu, 17 Apr 2025 at 18:08, Dionna Amalie Glaze
<dionnaglaze@google.com> wrote:
>
> What do you mean by emulate? Fake the MSRs and CPUID, or actually
> provide some memory protection value like the pKVM project?

The first, perhaps I should have explained the ultimate goal better:
Test/develop SVSM and guest OS interaction without having the hardware in place.

Stefano

>
> On Thu, Apr 17, 2025 at 8:26 AM Stefano Garzarella <sgarzare@redhat.com> wrote:
> >
> > Hi Tom,
> > 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,
> > but especially if you think it's a feasible thing.
> >
> > Suggestions, ideas or partial works that can be reused are very welcome!
> >
> > Thanks,
> > Stefano
> >
> >
>
>
> --
> -Dionna Glaze, PhD, CISSP, CCSP (she/her)
>

Re: Potential project on implementing AMD SEV emulation in QEMU

[Stefano Garzarella]

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.

Thanks,
Stefano

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

[Daniel P. Berrangé]

On Thu, Apr 17, 2025 at 05:26:15PM +0200, Stefano Garzarella wrote:
> Hi Tom,
> 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).

Agreed, from the QEMU maintainer side we'd very likely want to see an
incremental set of patches rather than a "big bang" attempting todo
everything in one go. Staging patch submissions for SEV, then ES
then SNP would make conceptual sense, to enable something useful to
be delivered at each step.

> We wondered if you knew of any attempts already made in this regard,
> but especially if you think it's a feasible thing.

I think 6 months is possibly on the optimistic side.

Non-trivial feature proposals have a habit of taking longer than people
expect upfront. They might get lucky, but I equally it wouldn't surprise
me to see patches go through 6-9 months of reviews, on top of the initial
time needed to write a first impl before submission, with multiple
repostings needed before being merged. IOW it could be 6 months,  it
could be 12 months.

I don't mean that to discourage an attempt. Just that non-trivial open
source contributions with fixed timelines are not a reliable combination.
IOW, plan for what happens if it takes longer than expected, exceeding
the 6 month thesis timeframe.

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

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

[Daniel P. Berrangé]

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

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

[Stefano Garzarella]

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

Thanks,
Stefano

Re: [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@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 :|

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

[Stefano Garzarella]

On Tue, Apr 22, 2025 at 08:52:49AM +0100, Daniel P. Berrangé wrote:
>On Thu, Apr 17, 2025 at 05:26:15PM +0200, Stefano Garzarella wrote:
>> Hi Tom,
>> 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).
>
>Agreed, from the QEMU maintainer side we'd very likely want to see an
>incremental set of patches rather than a "big bang" attempting todo
>everything in one go. Staging patch submissions for SEV, then ES
>then SNP would make conceptual sense, to enable something useful to
>be delivered at each step.

I see, thanks for confirming!

>
>> We wondered if you knew of any attempts already made in this regard,
>> but especially if you think it's a feasible thing.
>
>I think 6 months is possibly on the optimistic side.
>
>Non-trivial feature proposals have a habit of taking longer than people
>expect upfront. They might get lucky, but I equally it wouldn't surprise
>me to see patches go through 6-9 months of reviews, on top of the initial
>time needed to write a first impl before submission, with multiple
>repostings needed before being merged. IOW it could be 6 months,  it
>could be 12 months.

Yes, I understand what you mean and I will point it out. Anyway, as with 
GSoC as well, IMHO the time of the thesis, it doesn't have to be 
perfectly aligned with the time it takes to merge everything upstream.
Obviously I will make sure that this will be the ultimate goal.

Eventually, if by the university the thesis is ready and the student has 
other priorities, we can help with the process for upstreaming, as we 
have sometimes done for GSoC projects.

>
>I don't mean that to discourage an attempt. Just that non-trivial open
>source contributions with fixed timelines are not a reliable combination.
>IOW, plan for what happens if it takes longer than expected, exceeding
>the 6 month thesis timeframe.

I agree, I will point it out!

Thank you so much for your valuable feedback!
Stefano