[svsm-devel] Alternate Injection spec question

Jon Lange jlange at microsoft.com
Fri Dec 6 18:49:12 CET 2024 

If firmware is embedded in the IGVM file, then the IGVM file builder specific to the SVSM implementation can place any data it wants into SVSM memory (in COCONUT-SVSM, for example, look for uses of the IgvmParamBlockFwInfo structure).  The IGVM format would only need to change if we wanted the host to be able to inject an unmeasured parameter, which would introduce exactly the sort of security problem we're trying to avoid here.

-Jon

From: Lendacky, Thomas <Thomas.Lendacky at amd.com>
Sent: Friday, December 6, 2024 9:43 AM
To: Jon Lange <jlange at microsoft.com>; Wang, Huibo <Huibo.Wang at amd.com>; Joerg Roedel <jroedel at suse.de>
Cc: svsm-devel at coconut-svsm.dev
Subject: [EXTERNAL] RE: Alternate Injection spec question


[AMD Official Use Only - AMD Internal Distribution Only]

Ah, I think I remember that discussion, now. Yeah, we don't want the hypervisor to trick the SVSM into disabling the support.

I'm not too familiar with the details of IGVM, but is it reasonable to add something to the IGVM file that can be placed into SVSM memory telling the SVSM what it supports? Or should we rely on some form of metadata within the firmware object? In other words, we wouldn't want to enable alternate injection if the hardware supports secure AVIC and the firmware supports both alternate injection and secure AVIC. In that case, we want the firmware to be using the more performant secure AVIC.

Thanks,
Tom

From: Jon Lange <jlange at microsoft.com<mailto:jlange at microsoft.com>>
Sent: Friday, December 6, 2024 11:32 AM
To: Lendacky, Thomas <Thomas.Lendacky at amd.com<mailto:Thomas.Lendacky at amd.com>>; Wang, Huibo <Huibo.Wang at amd.com<mailto:Huibo.Wang at amd.com>>
Cc: svsm-devel at coconut-svsm.dev<mailto:svsm-devel at coconut-svsm.dev>; Joerg Roedel <jroedel at suse.de<mailto:jroedel at suse.de>>
Subject: RE: Alternate Injection spec question


[AMD Official Use Only - AMD Internal Distribution Only]

The SVSM doesn't know whether the guest accesses an APIC MSR unless it activates REFLECT_VC, and that is outside the scope of SVSM design (it's integral to paravisor mode, but an SVSM typically does not want to run as a paravisor).  The only way the SVSM would know whether the guest accesses an APIC MSR would be for the host to tell the SVSM that the guest was making such an attempt, but that would permit the host to lie and request disabling Alternate Injection even if the guest OS wanted it to be enabled.

-Jon

From: Lendacky, Thomas <Thomas.Lendacky at amd.com<mailto:Thomas.Lendacky at amd.com>>
Sent: Friday, December 6, 2024 9:25 AM
To: Jon Lange <jlange at microsoft.com<mailto:jlange at microsoft.com>>; Wang, Huibo <Huibo.Wang at amd.com<mailto:Huibo.Wang at amd.com>>
Cc: svsm-devel at coconut-svsm.dev<mailto:svsm-devel at coconut-svsm.dev>; Joerg Roedel <jroedel at suse.de<mailto:jroedel at suse.de>>
Subject: [EXTERNAL] RE: Alternate Injection spec question


[AMD Official Use Only - AMD Internal Distribution Only]

Hi Jon,

Does the SVSM really require having that knowledge? Can set the alternate injection feature in SEV_FEATURES and then assume that if the guest starts to access an xAPIC MMIO area or x2APIC MSR that it doesn't have support for alternate injection and have the SVSM disable it at that point? I don't know if we can place the requirement on the SVSM to have that kind of knowledge of the embedded firmware unless we make it part of the (current) metadata that the SVSM can parse, which is reasonable, I think. We can probably extend the SNP metadata to have a supported features entry.

Thanks,
Tom

From: Jon Lange <jlange at microsoft.com<mailto:jlange at microsoft.com>>
Sent: Thursday, December 5, 2024 6:40 PM
To: Wang, Huibo <Huibo.Wang at amd.com<mailto:Huibo.Wang at amd.com>>
Cc: svsm-devel at coconut-svsm.dev<mailto:svsm-devel at coconut-svsm.dev>; Joerg Roedel <jroedel at suse.de<mailto:jroedel at suse.de>>; Lendacky, Thomas <Thomas.Lendacky at amd.com<mailto:Thomas.Lendacky at amd.com>>
Subject: RE: Alternate Injection spec question

The language from the spec says the following:
The SVSM is required to have knowledge of whether the first component that executes can support the Alternate Injection protocol.

I thought "required to have knowledge" would be clear.  What additional information are you hoping to see in the spec?

-Jon

From: Wang, Huibo <Huibo.Wang at amd.com<mailto:Huibo.Wang at amd.com>>
Sent: Thursday, December 5, 2024 1:20 PM
To: Jon Lange <jlange at microsoft.com<mailto:jlange at microsoft.com>>
Cc: svsm-devel at coconut-svsm.dev<mailto:svsm-devel at coconut-svsm.dev>; Joerg Roedel <jroedel at suse.de<mailto:jroedel at suse.de>>; Lendacky, Thomas <Thomas.Lendacky at amd.com<mailto:Thomas.Lendacky at amd.com>>
Subject: [EXTERNAL] Re: Alternate Injection spec question

Hi Jon,

Thanks a lot, perhaps the spec should be extended with that info as it is not obvious at the moment.

Thanks,
Melody

________________________________
From: Jon Lange <jlange at microsoft.com<mailto:jlange at microsoft.com>>
Sent: Wednesday, December 4, 2024 9:01 PM
To: Wang, Huibo <Huibo.Wang at amd.com<mailto:Huibo.Wang at amd.com>>
Cc: svsm-devel at coconut-svsm.dev<mailto:svsm-devel at coconut-svsm.dev> <svsm-devel at coconut-svsm.dev<mailto:svsm-devel at coconut-svsm.dev>>; Joerg Roedel <jroedel at suse.de<mailto:jroedel at suse.de>>; Lendacky, Thomas <Thomas.Lendacky at amd.com<mailto:Thomas.Lendacky at amd.com>>
Subject: RE: Alternate Injection spec question


[AMD Official Use Only - AMD Internal Distribution Only]


Melody,



As stated in the spec, Alternate Injection can only provide strong security guarantees if it is active from the first instruction of the guest firmware.  This means that the firmware cannot negotiate the use of Alternate Injection - it must already be active by the time firmware starts executing.  The expectation is that there is a strong coupling between the SVSM image and the firmware image - after all, the initial launch measurements always include both, so it is reasonable to assume that the SVSM has knowledge of how the embedded firmware is going to operate.  Therefore, the SVSM must be configured to configure Alternate Injection based on the design of the firmware.  If the firmware is capable of using Alternate Injection, then the SVSM should configure the initial guest VMSA to enable Alternate Injection.  Any firmware image that is capable of using Alternate Injection should be smart enough to read SEV_FEATURES to detect whether it is enabled and to call the SVSM to disable Alternate Injection if it doesn't want the feature enabled.  On the other hand, if the firmware is not capable of using Alternate Injection, then the SVSM should create the initial guest VMSA without enabling Alternate Injection.



To put it another way, more closely related to the spec language, the SVSM is supposed to know what the "first component" is, and what that first component expects, and the SVSM is supposed to be built with that configuration in mind.



Regarding INIT/SIPI - I think you are correct; the spec is missing the word "not".  INIT/SIPI should only be used by the guest if it knows that the SVSM APIC supports INIT/SIPI.



-Jon



From: Wang, Huibo <Huibo.Wang at amd.com<mailto:Huibo.Wang at amd.com>>
Sent: Tuesday, December 3, 2024 10:20 PM
To: Jon Lange <jlange at microsoft.com<mailto:jlange at microsoft.com>>
Cc: svsm-devel at coconut-svsm.dev<mailto:svsm-devel at coconut-svsm.dev>; Joerg Roedel <jroedel at suse.de<mailto:jroedel at suse.de>>; Lendacky, Thomas <Thomas.Lendacky at amd.com<mailto:Thomas.Lendacky at amd.com>>
Subject: [EXTERNAL] Re: Alternate Injection spec question



You don't often get email from huibo.wang at amd.com<mailto:huibo.wang at amd.com>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>

[AMD Official Use Only - AMD Internal Distribution Only]



Hi Jon,



I have a couple questions about the spec.



1.  For the mechanism transferring control from guest firmware to guest OS,
   from the flow I read, I wonder how the firmware (first component) can
   register the use of Alternate Injection.

   I see there are 3 forms of the SVSM_APIC_CONFIGURE_EMULATION call:

    1. ECX[1:0] = 0b00, disable Alternate Injection if reg count == 0
    2. ECX[1:0] = 0b01, deregister the guest, if reg_count == 0, disable AI
    3. ECX[1:0] = 0b10, register the guest, no change to AI setting

So how does the firmware (first component) register? Or, could you help me
understand how do you envision this process to happen?

There's text related to that in the beginning of the spec:

"The SVSM is required to have knowledge of whether the first component that
executes can support the Alternate Injection protocol. If the SVSM does not
know that the first component to execute will support the SVSM APIC Protocol,
then it must not enable Alternate Injection in the guest VMSA. If the SVSM
does know that the first component to execute will support the SVSM APIC
Protocol, then it will enable Alternate Injection prior to the first guest
entry; the first guest component must either make use of the protocol or it
must request that the protocol be disabled."

I *think* this "make use of the protocol" is how you want the SVSM to detect
that the first component is going to use AI and I think that "make use" is by
doing SVSM_APIC_CONFIGURE_EMULATION but as far as I'm reading it, I can't find
an ECX[1:0] setting which says, "I'm the first component, I'm going to use
AI"?

Or do you mean the first component should use some other SVSM APIC protocol
call like SVSM_APIC_QUERY_FEATURES, for example?

2. In SVSM APIC Protocol - Query Features section,

   "Bit 1 indicates support for INIT and SIPI delivery. If INIT and SIPI
   delivery are not supported, the guest may use INIT and SIPI signals to
   start additional vCPUs within the invoking VMPL.  Note that even if INIT
   and SIPI are supported, the guest must still use the VMSA creation calls of
   the SVSM Core Protocol to start additional vCPUs so that the Calling Area
   address for each vCPU can be configured correctly."

Is it possible that the marked here means "may not use" instead of "may use"?



Thanks,

Melody





________________________________

From: Wang, Huibo
Sent: Wednesday, November 13, 2024 5:42 PM
To: Jon Lange <jlange at microsoft.com<mailto:jlange at microsoft.com>>
Cc: svsm-devel at coconut-svsm.dev<mailto:svsm-devel at coconut-svsm.dev> <svsm-devel at coconut-svsm.dev<mailto:svsm-devel at coconut-svsm.dev>>; Joerg Roedel <jroedel at suse.de<mailto:jroedel at suse.de>>; Lendacky, Thomas <Thomas.Lendacky at amd.com<mailto:Thomas.Lendacky at amd.com>>
Subject: Alternate Injection spec question



Hi Jon,

Yeah, the one I have is version of May, thank you for the update.

Thanks
Melody

-----Original Message-----
From: Jon Lange <jlange at microsoft.com<mailto:jlange at microsoft.com>>
Sent: Wednesday, November 13, 2024 5:23 PM
To: Wang, Huibo <Huibo.Wang at amd.com<mailto:Huibo.Wang at amd.com>>
Cc: svsm-devel at coconut-svsm.dev<mailto:svsm-devel at coconut-svsm.dev>; Joerg Roedel <jroedel at suse.de<mailto:jroedel at suse.de>>; Lendacky, Thomas <Thomas.Lendacky at amd.com<mailto:Thomas.Lendacky at amd.com>>
Subject: RE: Svsm-devel Digest, Vol 10, Issue 19

[AMD Official Use Only - AMD Internal Distribution Only]

I think you have an old version of the spec.  The latest version (attached) has all five calls.

-Jon

-----Original Message-----
From: Wang, Huibo <Huibo.Wang at amd.com<mailto:Huibo.Wang at amd.com>>
Sent: Wednesday, November 13, 2024 12:32 PM
To: Jon Lange <jlange at microsoft.com<mailto:jlange at microsoft.com>>
Cc: svsm-devel at coconut-svsm.dev<mailto:svsm-devel at coconut-svsm.dev>; Joerg Roedel <jroedel at suse.de<mailto:jroedel at suse.de>>; Lendacky, Thomas <Thomas.Lendacky at amd.com<mailto:Thomas.Lendacky at amd.com>>
Subject: [EXTERNAL] RE: Svsm-devel Digest, Vol 10, Issue 19

[You don't often get email from huibo.wang at amd.com<mailto:huibo.wang at amd.com>. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

[AMD Official Use Only - AMD Internal Distribution Only]

Hi Jon,

For SVSM APIC Protocol changes, there are 4 listed in the spec, SVSM_APIC_QUERY_FEATURES, SVSM_APIC_READ_REGISTER, SVSM_APIC_WRITE_REGISTER, SVSM_APIC_CONFIGURE_VECTOR. In the coconut svsm github, there is one more "const SVSM_REQ_APIC_CONFIGURE: u32 = 1", should this one also be included in the spec?

Thanks
Melody

-----Original Message-----
From: Svsm-devel <svsm-devel-bounces at coconut-svsm.dev<mailto:svsm-devel-bounces at coconut-svsm.dev>> On Behalf Of svsm-devel-request at coconut-svsm.dev<mailto:svsm-devel-request at coconut-svsm.dev>
Sent: Friday, May 17, 2024 12:09 AM
To: svsm-devel at coconut-svsm.dev<mailto:svsm-devel at coconut-svsm.dev>
Subject: Svsm-devel Digest, Vol 10, Issue 19

Send Svsm-devel mailing list submissions to
        svsm-devel at coconut-svsm.dev<mailto:svsm-devel at coconut-svsm.dev>

To subscribe or unsubscribe via the World Wide Web, visit
        https://mail.8bytes.org/cgi-bin/mailman/listinfo/svsm-devel
or, via email, send a message with subject or body 'help' to
        svsm-devel-request at coconut-svsm.dev<mailto:svsm-devel-request at coconut-svsm.dev>

You can reach the person managing the list at
        svsm-devel-owner at coconut-svsm.dev<mailto:svsm-devel-owner at coconut-svsm.dev>

When replying, please edit your Subject line so it is more specific than "Re: Contents of Svsm-devel digest..."


Today's Topics:

   1. RFC: Alternate Injection SVSM support (Jon Lange)


----------------------------------------------------------------------

Message: 1
Date: Fri, 17 May 2024 04:40:24 +0000
From: Jon Lange <jlange at microsoft.com<mailto:jlange at microsoft.com>>
To: "amd-sev-snp at lists.suse.com<mailto:amd-sev-snp at lists.suse.com>" <amd-sev-snp at lists.suse.com<mailto:amd-sev-snp at lists.suse.com>>,
        "svsm-devel at coconut-svsm.dev<mailto:svsm-devel at coconut-svsm.dev>" <svsm-devel at coconut-svsm.dev<mailto:svsm-devel at coconut-svsm.dev>>
Subject: [svsm-devel] RFC: Alternate Injection SVSM support
Message-ID:
        <DS7PR21MB352462BA31B209F93F296A17CAEE2 at DS7PR21MB3524.namprd21.prod.outlook.com<mailto:DS7PR21MB352462BA31B209F93F296A17CAEE2 at DS7PR21MB3524.namprd21.prod.outlook.com>>

Content-Type: text/plain; charset="us-ascii"

Attached is a specification I am proposing to handle support for Alternate Injection in SNP guests through the use of an SVSM.  This document proposes changes to the AMD GHCB specification and to the AMD SVSM specification to enable the negotiation required to make Alternate Injection work correctly.

Support for this protocol will not be possible in KVM until KVM is able to include native support for multiple VMPLs with separate interrupt sources for each.  That work is underway elsewhere, and my expectation is that this proposed specification will align with the capabilities that KVM will be introducing as part of the multi-VMPL support.

I will be submitting changes to COCONUT-SVSM to implement this protocol.  I welcome all feedback to the spec, and will update the code to match whatever spec changes are agreed upon.

-Jon



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.8bytes.org/pipermail/svsm-devel/attachments/20240517/e74aeb2f/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Alternate Injection Support for SEV-SNP 20240513.pdf
Type: application/pdf
Size: 114718 bytes
Desc: Alternate Injection Support for SEV-SNP 20240513.pdf
URL: <http://mail.8bytes.org/pipermail/svsm-devel/attachments/20240517/e74aeb2f/attachment.pdf>

------------------------------

Subject: Digest Footer

Svsm-devel mailing list
Svsm-devel at coconut-svsm.dev<mailto:Svsm-devel at coconut-svsm.dev>
https://mail.8bytes.org/cgi-bin/mailman/listinfo/svsm-devel


------------------------------

End of Svsm-devel Digest, Vol 10, Issue 19
******************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.8bytes.org/pipermail/svsm-devel/attachments/20241206/fdab7f03/attachment-0001.htm>

More information about the Svsm-devel mailing list