Closed roy-hopkins closed 1 month ago
Is the initial CPU state for SEV settable by the host or is it a well-defined starting location?
Is the initial CPU state for SEV settable by the host or is it a well-defined starting location?
The CPU state is outside the protection model for SEV but it can be configured by the host, so I suppose we could define this using IGVM although it does not form part of any guest measurement. We could just allow the SEV-ES/SEV-SNP initial CPU state to also be used for SEV if you think it is appropriate.
I wonder if it makes sense to use the NATIVE CPU state type then, since unlike TDX there's no requirement to be in a specific state? That at least makes more sense than the SNP VMSA page, since there's no measurement. What do you think?
I wonder if it makes sense to use the NATIVE CPU state type then, since unlike TDX there's no requirement to be in a specific state? That at least makes more sense than the SNP VMSA page, since there's no measurement. What do you think?
Yes, I think that makes sense. I've updated the description of IgvmNativeVpContextX64
to include this as well as set the VP context type for SEV to IgvmNativeVpContextX64
and updated the commit description.
Changes LGTM.
Currently, only SEV-SNP is supported as a platform type for SEV guests. However, there is no reason why IGVM cannot be used to configure both SEV and SEV-ES.
This commit adds two new platform types:
IgvmPlatformType::SEV
andIgvmPlatformType::SEV_ES
which allow IGVM files to specifically target these isolation technologies.Unlike SEV, SEV-ES allows the VP context to be specified. The structure for defining the context is binary compatible with SEV-SNP, therefore the SEV-ES platform type reuses IgvmDirectiveHeader::SnpVpContext to define the VMSA.