diff mbox series

[v8,27/40] x86/boot: Add Confidential Computing type to setup_data

Message ID 20211210154332.11526-28-brijesh.singh@amd.com (mailing list archive)
State New
Headers show
Series Add AMD Secure Nested Paging (SEV-SNP) Guest Support | expand

Commit Message

Brijesh Singh Dec. 10, 2021, 3:43 p.m. UTC
While launching the encrypted guests, the hypervisor may need to provide
some additional information during the guest boot. When booting under the
EFI based BIOS, the EFI configuration table contains an entry for the
confidential computing blob that contains the required information.

To support booting encrypted guests on non-EFI VM, the hypervisor needs to
pass this additional information to the kernel with a different method.

For this purpose, introduce SETUP_CC_BLOB type in setup_data to hold the
physical address of the confidential computing blob location. The boot
loader or hypervisor may choose to use this method instead of EFI
configuration table. The CC blob location scanning should give preference
to setup_data data over the EFI configuration table.

In AMD SEV-SNP, the CC blob contains the address of the secrets and CPUID
pages. The secrets page includes information such as a VM to PSP
communication key and CPUID page contains PSP filtered CPUID values.
Define the AMD SEV confidential computing blob structure.

While at it, define the EFI GUID for the confidential computing blob.

Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
---
 arch/x86/include/asm/sev.h            | 12 ++++++++++++
 arch/x86/include/uapi/asm/bootparam.h |  1 +
 include/linux/efi.h                   |  1 +
 3 files changed, 14 insertions(+)

Comments

Dave Hansen Dec. 10, 2021, 7:12 p.m. UTC | #1
On 12/10/21 7:43 AM, Brijesh Singh wrote:
> +/* AMD SEV Confidential computing blob structure */
> +#define CC_BLOB_SEV_HDR_MAGIC	0x45444d41
> +struct cc_blob_sev_info {
> +	u32 magic;
> +	u16 version;
> +	u16 reserved;
> +	u64 secrets_phys;
> +	u32 secrets_len;
> +	u64 cpuid_phys;
> +	u32 cpuid_len;
> +};

This is an ABI structure rather than some purely kernel construct, right?

I searched through all of the specs to which you linked in the cover
letter.  I looked for "blob", "guid", the magic and part of the GUID
itself trying to find where this is defined to see if the struct is correct.

I couldn't find anything.

Where is the spec for this blob?  How large is it?  Did you mean to
leave a 4-byte hole after secrets_len and before cpuid_phys?
Dave Hansen Dec. 10, 2021, 8:30 p.m. UTC | #2
On 12/10/21 12:18 PM, Brijesh Singh wrote:
> On 12/10/21 1:12 PM, Dave Hansen wrote:
>> On 12/10/21 7:43 AM, Brijesh Singh wrote:
>>> +/* AMD SEV Confidential computing blob structure */
>>> +#define CC_BLOB_SEV_HDR_MAGIC	0x45444d41
>>> +struct cc_blob_sev_info {
>>> +	u32 magic;
>>> +	u16 version;
>>> +	u16 reserved;
>>> +	u64 secrets_phys;
>>> +	u32 secrets_len;
>>> +	u64 cpuid_phys;
>>> +	u32 cpuid_len;
>>> +};
>> This is an ABI structure rather than some purely kernel construct, right?
> 
> This is ABI between the guest BIOS and Guest OS. It is defined in the OVMF.
> 
> https://github.com/tianocore/edk2/blob/master/OvmfPkg/Include/Guid/ConfidentialComputingSevSnpBlob.h
> 
> SEV-SNP FW spec does not have it documented; it's up to the guest BIOS
> on how it wants to communicate the Secrets and CPUID page location to
> guest OS.

Well, no matter where it is defined, could we please make it a bit
easier for folks to find it in the future?

>> I searched through all of the specs to which you linked in the cover
>> letter.  I looked for "blob", "guid", the magic and part of the GUID
>> itself trying to find where this is defined to see if the struct is correct.
>>
>> I couldn't find anything.
>>
>> Where is the spec for this blob?  How large is it?  Did you mean to
>> leave a 4-byte hole after secrets_len and before cpuid_phys?
> Yes, the length is never going to be > 4GB.

I was more concerned that this structure could change sizes if it were
compiled on 32-bit versus 64-bit code.  For kernel ABIs, we try not to
do that.

Is this somehow OK when talking to firmware?  Or can a 32-bit OS and
64-bit firmware never interact?
Brijesh Singh Dec. 13, 2021, 2:49 p.m. UTC | #3
On 12/10/21 2:30 PM, Dave Hansen wrote:
> On 12/10/21 12:18 PM, Brijesh Singh wrote:
>> On 12/10/21 1:12 PM, Dave Hansen wrote:
>>> On 12/10/21 7:43 AM, Brijesh Singh wrote:
>>>> +/* AMD SEV Confidential computing blob structure */
>>>> +#define CC_BLOB_SEV_HDR_MAGIC	0x45444d41
>>>> +struct cc_blob_sev_info {
>>>> +	u32 magic;
>>>> +	u16 version;
>>>> +	u16 reserved;
>>>> +	u64 secrets_phys;
>>>> +	u32 secrets_len;
>>>> +	u64 cpuid_phys;
>>>> +	u32 cpuid_len;
>>>> +};
>>> This is an ABI structure rather than some purely kernel construct, right?
>>
>> This is ABI between the guest BIOS and Guest OS. It is defined in the OVMF.
>>
>> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Ftianocore%2Fedk2%2Fblob%2Fmaster%2FOvmfPkg%2FInclude%2FGuid%2FConfidentialComputingSevSnpBlob.h&amp;data=04%7C01%7Cbrijesh.singh%40amd.com%7C460f6abff7f04e065c9108d9bc1bfcf7%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637747650681544593%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=GI1fAngRJ%2Bj4hcM91UutVXlS1F7kfk2xxtG6I%2BL%2FRYc%3D&amp;reserved=0
>>
>> SEV-SNP FW spec does not have it documented; it's up to the guest BIOS
>> on how it wants to communicate the Secrets and CPUID page location to
>> guest OS.
> 
> Well, no matter where it is defined, could we please make it a bit
> easier for folks to find it in the future?
> 

Noted, I will add a comment so that readers can find it easily. 
Additionally, I will create a doc and get it published on 
developer.amd.com/sev so that information is documented outside the 
source code files.

>>> I searched through all of the specs to which you linked in the cover
>>> letter.  I looked for "blob", "guid", the magic and part of the GUID
>>> itself trying to find where this is defined to see if the struct is correct.
>>>
>>> I couldn't find anything.
>>>
>>> Where is the spec for this blob?  How large is it?  Did you mean to
>>> leave a 4-byte hole after secrets_len and before cpuid_phys?
>> Yes, the length is never going to be > 4GB.
> 
> I was more concerned that this structure could change sizes if it were
> compiled on 32-bit versus 64-bit code.  For kernel ABIs, we try not to
> do that.
> 
> Is this somehow OK when talking to firmware?  Or can a 32-bit OS and
> 64-bit firmware never interact?
> 

For SNP, both the firmware and OS need to be 64-bit. IIRC, both the 
Linux and OVMF do not enable the memory encryption for the 32-bit.

thanks
Dave Hansen Dec. 13, 2021, 3:08 p.m. UTC | #4
On 12/13/21 6:49 AM, Brijesh Singh wrote:
>> I was more concerned that this structure could change sizes if it were
>> compiled on 32-bit versus 64-bit code.  For kernel ABIs, we try not to
>> do that.
>>
>> Is this somehow OK when talking to firmware?  Or can a 32-bit OS and
>> 64-bit firmware never interact?
> 
> For SNP, both the firmware and OS need to be 64-bit. IIRC, both the
> Linux and OVMF do not enable the memory encryption for the 32-bit.

Could you please make the structure's size invariant?  That's great if
there's no problem in today's implementation, but it's best no to leave
little land mines like this around.  Let's say someone copies your code
as an example of something that interacts with a firmware table a few
years or months down the road.
Brijesh Singh Dec. 13, 2021, 3:55 p.m. UTC | #5
On 12/13/21 9:08 AM, Dave Hansen wrote:
> On 12/13/21 6:49 AM, Brijesh Singh wrote:
>>> I was more concerned that this structure could change sizes if it were
>>> compiled on 32-bit versus 64-bit code.  For kernel ABIs, we try not to
>>> do that.
>>>
>>> Is this somehow OK when talking to firmware?  Or can a 32-bit OS and
>>> 64-bit firmware never interact?
>>
>> For SNP, both the firmware and OS need to be 64-bit. IIRC, both the
>> Linux and OVMF do not enable the memory encryption for the 32-bit.
> 
> Could you please make the structure's size invariant?  

Ack. I will make the required changes.

That's great if
> there's no problem in today's implementation, but it's best no to leave
> little land mines like this around.  Let's say someone copies your code
> as an example of something that interacts with a firmware table a few
> years or months down the road.
>
Venu Busireddy Jan. 6, 2022, 10:48 p.m. UTC | #6
On 2021-12-10 09:43:19 -0600, Brijesh Singh wrote:
> While launching the encrypted guests, the hypervisor may need to provide
> some additional information during the guest boot. When booting under the
> EFI based BIOS, the EFI configuration table contains an entry for the
> confidential computing blob that contains the required information.
> 
> To support booting encrypted guests on non-EFI VM, the hypervisor needs to
> pass this additional information to the kernel with a different method.
> 
> For this purpose, introduce SETUP_CC_BLOB type in setup_data to hold the
> physical address of the confidential computing blob location. The boot
> loader or hypervisor may choose to use this method instead of EFI
> configuration table. The CC blob location scanning should give preference
> to setup_data data over the EFI configuration table.
> 
> In AMD SEV-SNP, the CC blob contains the address of the secrets and CPUID
> pages. The secrets page includes information such as a VM to PSP
> communication key and CPUID page contains PSP filtered CPUID values.
> Define the AMD SEV confidential computing blob structure.
> 
> While at it, define the EFI GUID for the confidential computing blob.
> 
> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>

Reviewed-by: Venu Busireddy <venu.busireddy@oracle.com>

> ---
>  arch/x86/include/asm/sev.h            | 12 ++++++++++++
>  arch/x86/include/uapi/asm/bootparam.h |  1 +
>  include/linux/efi.h                   |  1 +
>  3 files changed, 14 insertions(+)
> 
> diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
> index f7cbd5164136..f42fbe3c332f 100644
> --- a/arch/x86/include/asm/sev.h
> +++ b/arch/x86/include/asm/sev.h
> @@ -44,6 +44,18 @@ struct es_em_ctxt {
>  
>  void do_vc_no_ghcb(struct pt_regs *regs, unsigned long exit_code);
>  
> +/* AMD SEV Confidential computing blob structure */
> +#define CC_BLOB_SEV_HDR_MAGIC	0x45444d41
> +struct cc_blob_sev_info {
> +	u32 magic;
> +	u16 version;
> +	u16 reserved;
> +	u64 secrets_phys;
> +	u32 secrets_len;
> +	u64 cpuid_phys;
> +	u32 cpuid_len;
> +};
> +
>  static inline u64 lower_bits(u64 val, unsigned int bits)
>  {
>  	u64 mask = (1ULL << bits) - 1;
> diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
> index b25d3f82c2f3..1ac5acca72ce 100644
> --- a/arch/x86/include/uapi/asm/bootparam.h
> +++ b/arch/x86/include/uapi/asm/bootparam.h
> @@ -10,6 +10,7 @@
>  #define SETUP_EFI			4
>  #define SETUP_APPLE_PROPERTIES		5
>  #define SETUP_JAILHOUSE			6
> +#define SETUP_CC_BLOB			7
>  
>  #define SETUP_INDIRECT			(1<<31)
>  
> diff --git a/include/linux/efi.h b/include/linux/efi.h
> index dbd39b20e034..a022aed7adb3 100644
> --- a/include/linux/efi.h
> +++ b/include/linux/efi.h
> @@ -344,6 +344,7 @@ void efi_native_runtime_setup(void);
>  #define EFI_CERT_SHA256_GUID			EFI_GUID(0xc1c41626, 0x504c, 0x4092, 0xac, 0xa9, 0x41, 0xf9, 0x36, 0x93, 0x43, 0x28)
>  #define EFI_CERT_X509_GUID			EFI_GUID(0xa5c059a1, 0x94e4, 0x4aa7, 0x87, 0xb5, 0xab, 0x15, 0x5c, 0x2b, 0xf0, 0x72)
>  #define EFI_CERT_X509_SHA256_GUID		EFI_GUID(0x3bd2a492, 0x96c0, 0x4079, 0xb4, 0x20, 0xfc, 0xf9, 0x8e, 0xf1, 0x03, 0xed)
> +#define EFI_CC_BLOB_GUID			EFI_GUID(0x067b1f5f, 0xcf26, 0x44c5, 0x85, 0x54, 0x93, 0xd7, 0x77, 0x91, 0x2d, 0x42)
>  
>  /*
>   * This GUID is used to pass to the kernel proper the struct screen_info
> -- 
> 2.25.1
>
diff mbox series

Patch

diff --git a/arch/x86/include/asm/sev.h b/arch/x86/include/asm/sev.h
index f7cbd5164136..f42fbe3c332f 100644
--- a/arch/x86/include/asm/sev.h
+++ b/arch/x86/include/asm/sev.h
@@ -44,6 +44,18 @@  struct es_em_ctxt {
 
 void do_vc_no_ghcb(struct pt_regs *regs, unsigned long exit_code);
 
+/* AMD SEV Confidential computing blob structure */
+#define CC_BLOB_SEV_HDR_MAGIC	0x45444d41
+struct cc_blob_sev_info {
+	u32 magic;
+	u16 version;
+	u16 reserved;
+	u64 secrets_phys;
+	u32 secrets_len;
+	u64 cpuid_phys;
+	u32 cpuid_len;
+};
+
 static inline u64 lower_bits(u64 val, unsigned int bits)
 {
 	u64 mask = (1ULL << bits) - 1;
diff --git a/arch/x86/include/uapi/asm/bootparam.h b/arch/x86/include/uapi/asm/bootparam.h
index b25d3f82c2f3..1ac5acca72ce 100644
--- a/arch/x86/include/uapi/asm/bootparam.h
+++ b/arch/x86/include/uapi/asm/bootparam.h
@@ -10,6 +10,7 @@ 
 #define SETUP_EFI			4
 #define SETUP_APPLE_PROPERTIES		5
 #define SETUP_JAILHOUSE			6
+#define SETUP_CC_BLOB			7
 
 #define SETUP_INDIRECT			(1<<31)
 
diff --git a/include/linux/efi.h b/include/linux/efi.h
index dbd39b20e034..a022aed7adb3 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -344,6 +344,7 @@  void efi_native_runtime_setup(void);
 #define EFI_CERT_SHA256_GUID			EFI_GUID(0xc1c41626, 0x504c, 0x4092, 0xac, 0xa9, 0x41, 0xf9, 0x36, 0x93, 0x43, 0x28)
 #define EFI_CERT_X509_GUID			EFI_GUID(0xa5c059a1, 0x94e4, 0x4aa7, 0x87, 0xb5, 0xab, 0x15, 0x5c, 0x2b, 0xf0, 0x72)
 #define EFI_CERT_X509_SHA256_GUID		EFI_GUID(0x3bd2a492, 0x96c0, 0x4079, 0xb4, 0x20, 0xfc, 0xf9, 0x8e, 0xf1, 0x03, 0xed)
+#define EFI_CC_BLOB_GUID			EFI_GUID(0x067b1f5f, 0xcf26, 0x44c5, 0x85, 0x54, 0x93, 0xd7, 0x77, 0x91, 0x2d, 0x42)
 
 /*
  * This GUID is used to pass to the kernel proper the struct screen_info