mbox series

[Part1,RFC,v4,00/36] Add AMD Secure Nested Paging (SEV-SNP) Guest Support

Message ID 20210707181506.30489-1-brijesh.singh@amd.com
Headers show
Series Add AMD Secure Nested Paging (SEV-SNP) Guest Support | expand

Message

Brijesh Singh July 7, 2021, 6:14 p.m. UTC
This part of Secure Encrypted Paging (SEV-SNP) series focuses on the changes
required in a guest OS for SEV-SNP support.

SEV-SNP builds upon existing SEV and SEV-ES functionality while adding
new hardware-based memory protections. SEV-SNP adds strong memory integrity
protection to help prevent malicious hypervisor-based attacks like data
replay, memory re-mapping and more in order to create an isolated memory
encryption environment.
 
This series provides the basic building blocks to support booting the SEV-SNP
VMs, it does not cover all the security enhancement introduced by the SEV-SNP
such as interrupt protection.

Many of the integrity guarantees of SEV-SNP are enforced through a new
structure called the Reverse Map Table (RMP). Adding a new page to SEV-SNP
VM requires a 2-step process. First, the hypervisor assigns a page to the
guest using the new RMPUPDATE instruction. This transitions the page to
guest-invalid. Second, the guest validates the page using the new PVALIDATE
instruction. The SEV-SNP VMs can use the new "Page State Change Request NAE"
defined in the GHCB specification to ask hypervisor to add or remove page
from the RMP table.

Each page assigned to the SEV-SNP VM can either be validated or unvalidated,
as indicated by the Validated flag in the page's RMP entry. There are two
approaches that can be taken for the page validation: Pre-validation and
Lazy Validation.

Under pre-validation, the pages are validated prior to first use. And under
lazy validation, pages are validated when first accessed. An access to a
unvalidated page results in a #VC exception, at which time the exception
handler may validate the page. Lazy validation requires careful tracking of
the validated pages to avoid validating the same GPA more than once. The
recently introduced "Unaccepted" memory type can be used to communicate the
unvalidated memory ranges to the Guest OS.

At this time we only sypport the pre-validation, the OVMF guest BIOS
validates the entire RAM before the control is handed over to the guest kernel.
The early_set_memory_{encrypt,decrypt} and set_memory_{encrypt,decrypt} are
enlightened to perform the page validation or invalidation while setting or
clearing the encryption attribute from the page table.

This series does not provide support for the following SEV-SNP features yet:

* Lazy validation
* Interrupt security

The series is based on tip/master
  e53fbd0a2509 (origin/master) Merge branch 'core/urgent'

Additional resources
---------------------
SEV-SNP whitepaper
https://www.amd.com/system/files/TechDocs/SEV-SNP-strengthening-vm-isolation-with-integrity-protection-and-more.pdf
 
APM 2: https://www.amd.com/system/files/TechDocs/24593.pdf
(section 15.36)

GHCB spec:
https://developer.amd.com/wp-content/resources/56421.pdf

SEV-SNP firmware specification:
https://developer.amd.com/sev/

Changes since v3:
 * Add support to use the PSP filtered CPUID.
 * Add support for the extended guest request.
 * Move sevguest driver in driver/virt/coco.
 * Add documentation for sevguest ioctl.
 * Add support to check the vmpl0.
 * Pass the VM encryption key and id to be used for encrypting guest messages
   through the platform drv data.
 * Multiple cleanup and fixes to address the review feedbacks.

Changes since v2:
 * Add support for AP startup using SNP specific vmgexit.
 * Add snp_prep_memory() helper.
 * Drop sev_snp_active() helper.
 * Add sev_feature_enabled() helper to check which SEV feature is active.
 * Sync the SNP guest message request header with latest SNP FW spec.
 * Multiple cleanup and fixes to address the review feedbacks.

Changes since v1:
 * Integerate the SNP support in sev.{ch}.
 * Add support to query the hypervisor feature and detect whether SNP is supported.
 * Define Linux specific reason code for the SNP guest termination.
 * Extend the setup_header provide a way for hypervisor to pass secret and cpuid page.
 * Add support to create a platform device and driver to query the attestation report
   and the derive a key.
 * Multiple cleanup and fixes to address Boris's review fedback.

Brijesh Singh (23):
  x86/sev: shorten GHCB terminate macro names
  x86/sev: Save the negotiated GHCB version
  x86/sev: Add support for hypervisor feature VMGEXIT
  x86/mm: Add sev_feature_enabled() helper
  x86/sev: Define the Linux specific guest termination reasons
  x86/sev: check SEV-SNP features support
  x86/sev: Add a helper for the PVALIDATE instruction
  x86/sev: check the vmpl level
  x86/compressed: Add helper for validating pages in the decompression
    stage
  x86/compressed: Register GHCB memory when SEV-SNP is active
  x86/sev: Register GHCB memory when SEV-SNP is active
  x86/sev: Add helper for validating pages in early enc attribute
    changes
  x86/kernel: Make the bss.decrypted section shared in RMP table
  x86/kernel: Validate rom memory before accessing when SEV-SNP is
    active
  x86/mm: Add support to validate memory when changing C-bit
  KVM: SVM: define new SEV_FEATURES field in the VMCB Save State Area
  x86/boot: Add Confidential Computing type to setup_data
  x86/sev: Provide support for SNP guest request NAEs
  x86/sev: Add snp_msg_seqno() helper
  x86/sev: Register SNP guest request platform device
  virt: Add SEV-SNP guest driver
  virt: sevguest: Add support to derive key
  virt: sevguest: Add support to get extended report

Michael Roth (9):
  x86/head/64: set up a startup %gs for stack protector
  x86/sev: move MSR-based VMGEXITs for CPUID to helper
  KVM: x86: move lookup of indexed CPUID leafs to helper
  x86/compressed/acpi: move EFI config table access to common code
  x86/compressed/64: enable SEV-SNP-validated CPUID in #VC handler
  x86/boot: add a pointer to Confidential Computing blob in bootparams
  x86/compressed/64: store Confidential Computing blob address in
    bootparams
  x86/compressed/64: add identity mapping for Confidential Computing
    blob
  x86/sev: enable SEV-SNP-validated CPUID in #VC handlers

Tom Lendacky (4):
  KVM: SVM: Create a separate mapping for the SEV-ES save area
  KVM: SVM: Create a separate mapping for the GHCB save area
  KVM: SVM: Update the SEV-ES save area mapping
  x86/sev: Use SEV-SNP AP creation to start secondary CPUs

 Documentation/virt/coco/sevguest.rst        | 109 +++
 arch/x86/boot/compressed/Makefile           |   1 +
 arch/x86/boot/compressed/acpi.c             | 124 ++--
 arch/x86/boot/compressed/efi-config-table.c | 224 ++++++
 arch/x86/boot/compressed/head_64.S          |   1 +
 arch/x86/boot/compressed/ident_map_64.c     |  35 +-
 arch/x86/boot/compressed/idt_64.c           |   7 +-
 arch/x86/boot/compressed/misc.h             |  66 ++
 arch/x86/boot/compressed/sev.c              | 115 +++-
 arch/x86/include/asm/bootparam_utils.h      |   1 +
 arch/x86/include/asm/cpuid-indexed.h        |  26 +
 arch/x86/include/asm/mem_encrypt.h          |  10 +
 arch/x86/include/asm/msr-index.h            |   2 +
 arch/x86/include/asm/realmode.h             |   1 +
 arch/x86/include/asm/setup.h                |   5 +-
 arch/x86/include/asm/sev-common.h           |  80 ++-
 arch/x86/include/asm/sev.h                  |  79 ++-
 arch/x86/include/asm/svm.h                  | 176 ++++-
 arch/x86/include/uapi/asm/bootparam.h       |   4 +-
 arch/x86/include/uapi/asm/svm.h             |  13 +
 arch/x86/kernel/head64.c                    |  46 +-
 arch/x86/kernel/head_64.S                   |   6 +-
 arch/x86/kernel/probe_roms.c                |  13 +-
 arch/x86/kernel/setup.c                     |   3 +
 arch/x86/kernel/sev-internal.h              |  12 +
 arch/x86/kernel/sev-shared.c                | 572 +++++++++++++++-
 arch/x86/kernel/sev.c                       | 716 +++++++++++++++++++-
 arch/x86/kernel/smpboot.c                   |   5 +
 arch/x86/kvm/cpuid.c                        |  17 +-
 arch/x86/kvm/svm/sev.c                      |  24 +-
 arch/x86/kvm/svm/svm.c                      |   4 +-
 arch/x86/kvm/svm/svm.h                      |   2 +-
 arch/x86/mm/mem_encrypt.c                   |  65 +-
 arch/x86/mm/pat/set_memory.c                |  15 +
 drivers/virt/Kconfig                        |   3 +
 drivers/virt/Makefile                       |   1 +
 drivers/virt/coco/sevguest/Kconfig          |   9 +
 drivers/virt/coco/sevguest/Makefile         |   2 +
 drivers/virt/coco/sevguest/sevguest.c       | 623 +++++++++++++++++
 drivers/virt/coco/sevguest/sevguest.h       |  63 ++
 include/linux/efi.h                         |   1 +
 include/linux/sev-guest.h                   |  90 +++
 include/uapi/linux/sev-guest.h              |  81 +++
 43 files changed, 3253 insertions(+), 199 deletions(-)
 create mode 100644 Documentation/virt/coco/sevguest.rst
 create mode 100644 arch/x86/boot/compressed/efi-config-table.c
 create mode 100644 arch/x86/include/asm/cpuid-indexed.h
 create mode 100644 arch/x86/kernel/sev-internal.h
 create mode 100644 drivers/virt/coco/sevguest/Kconfig
 create mode 100644 drivers/virt/coco/sevguest/Makefile
 create mode 100644 drivers/virt/coco/sevguest/sevguest.c
 create mode 100644 drivers/virt/coco/sevguest/sevguest.h
 create mode 100644 include/linux/sev-guest.h
 create mode 100644 include/uapi/linux/sev-guest.h

Comments

Paolo Bonzini July 8, 2021, 8:53 a.m. UTC | #1
On 08/07/21 10:50, Dr. David Alan Gilbert wrote:
>> +enum sev_feature_type {
>> +	SEV,
>> +	SEV_ES,
>> +	SEV_SNP
>> +};
> Is this ....
> 
>> diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
>> index a7c413432b33..37589da0282e 100644
>> --- a/arch/x86/include/asm/msr-index.h
>> +++ b/arch/x86/include/asm/msr-index.h
>> @@ -481,8 +481,10 @@
>>   #define MSR_AMD64_SEV			0xc0010131
>>   #define MSR_AMD64_SEV_ENABLED_BIT	0
>>   #define MSR_AMD64_SEV_ES_ENABLED_BIT	1
>> +#define MSR_AMD64_SEV_SNP_ENABLED_BIT	2
> Just the same as this ?
> 

No, it's just a coincidence.

Paolo
Borislav Petkov Aug. 10, 2021, 11:22 a.m. UTC | #2
On Wed, Jul 07, 2021 at 01:14:33PM -0500, Brijesh Singh wrote:
> diff --git a/arch/x86/include/asm/sev-common.h b/arch/x86/include/asm/sev-common.h

> index 11b7d9cea775..23929a3010df 100644

> --- a/arch/x86/include/asm/sev-common.h

> +++ b/arch/x86/include/asm/sev-common.h

> @@ -45,6 +45,15 @@

>  		(((unsigned long)reg & GHCB_MSR_CPUID_REG_MASK) << GHCB_MSR_CPUID_REG_POS) | \

>  		(((unsigned long)fn) << GHCB_MSR_CPUID_FUNC_POS))

>  

> +/* GHCB Hypervisor Feature Request */

> +#define GHCB_MSR_HV_FT_REQ	0x080

> +#define GHCB_MSR_HV_FT_RESP	0x081

> +#define GHCB_MSR_HV_FT_POS	12

> +#define GHCB_MSR_HV_FT_MASK	GENMASK_ULL(51, 0)

> +

> +#define GHCB_MSR_HV_FT_RESP_VAL(v)	\

> +	(((unsigned long)((v) >> GHCB_MSR_HV_FT_POS) & GHCB_MSR_HV_FT_MASK))


As I suggested...

> @@ -215,6 +216,7 @@

>  	{ SVM_VMGEXIT_NMI_COMPLETE,	"vmgexit_nmi_complete" }, \

>  	{ SVM_VMGEXIT_AP_HLT_LOOP,	"vmgexit_ap_hlt_loop" }, \

>  	{ SVM_VMGEXIT_AP_JUMP_TABLE,	"vmgexit_ap_jump_table" }, \

> +	{ SVM_VMGEXIT_HYPERVISOR_FEATURES,	"vmgexit_hypervisor_feature" }, \


	SVM_VMGEXIT_HV_FEATURES

>  	{ SVM_EXIT_ERR,         "invalid_guest_state" }

>  

>  

> diff --git a/arch/x86/kernel/sev-shared.c b/arch/x86/kernel/sev-shared.c

> index 19c2306ac02d..34821da5f05e 100644

> --- a/arch/x86/kernel/sev-shared.c

> +++ b/arch/x86/kernel/sev-shared.c

> @@ -23,6 +23,9 @@

>   */

>  static u16 ghcb_version __section(".data..ro_after_init");

>  

> +/* Bitmap of SEV features supported by the hypervisor */

> +u64 sev_hv_features __section(".data..ro_after_init") = 0;


__ro_after_init

> diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c

> index 66b7f63ad041..540b81ac54c9 100644

> --- a/arch/x86/kernel/sev.c

> +++ b/arch/x86/kernel/sev.c

> @@ -96,6 +96,9 @@ struct ghcb_state {

>  static DEFINE_PER_CPU(struct sev_es_runtime_data*, runtime_data);

>  DEFINE_STATIC_KEY_FALSE(sev_es_enable_key);

>  

> +/* Bitmap of SEV features supported by the hypervisor */

> +EXPORT_SYMBOL(sev_hv_features);


Why is this exported and why not a _GPL export?

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette
Brijesh Singh Aug. 10, 2021, 1:39 p.m. UTC | #3
On 8/10/21 6:22 AM, Borislav Petkov wrote:
> 

> 	SVM_VMGEXIT_HV_FEATURES

> 


Noted.

>>   

>> +/* Bitmap of SEV features supported by the hypervisor */

>> +u64 sev_hv_features __section(".data..ro_after_init") = 0;

> 

> __ro_after_init


Noted.

> 

>> diff --git a/arch/x86/kernel/sev.c b/arch/x86/kernel/sev.c

>> index 66b7f63ad041..540b81ac54c9 100644

>> --- a/arch/x86/kernel/sev.c

>> +++ b/arch/x86/kernel/sev.c

>> @@ -96,6 +96,9 @@ struct ghcb_state {

>>   static DEFINE_PER_CPU(struct sev_es_runtime_data*, runtime_data);

>>   DEFINE_STATIC_KEY_FALSE(sev_es_enable_key);

>>   

>> +/* Bitmap of SEV features supported by the hypervisor */

>> +EXPORT_SYMBOL(sev_hv_features);

> 

> Why is this exported and why not a _GPL export?

> 


I was thinking that some driver may need it in future, but nothing in my 
series needs it yet. I will drop it and we can revisit it later.

-Brijesh
Borislav Petkov Aug. 10, 2021, 2:03 p.m. UTC | #4
On Tue, Aug 10, 2021 at 08:39:02AM -0500, Brijesh Singh wrote:
> I was thinking that some driver may need it in future, but nothing in my
> series needs it yet. I will drop it and we can revisit it later.

Yeah, please never do such exports in anticipation.

And if we *ever* need them, they should be _GPL ones - not
EXPORT_SYMBOL. And then the API needs to be discussed and potentially
proper accessors added instead of exporting naked variables...

Thx.
Borislav Petkov Aug. 13, 2021, 11:13 a.m. UTC | #5
On Wed, Jul 07, 2021 at 01:14:42PM -0500, Brijesh Singh wrote:
> +void __init early_snp_set_memory_private(unsigned long vaddr, unsigned long paddr,
> +					 unsigned int npages)
> +{
> +	if (!sev_feature_enabled(SEV_SNP))
> +		return;
> +
> +	 /* Ask hypervisor to add the memory pages in RMP table as a 'private'. */
Borislav Petkov Aug. 17, 2021, 5:54 p.m. UTC | #6
On Wed, Jul 07, 2021 at 01:14:46PM -0500, Brijesh Singh wrote:
> The hypervisor uses the SEV_FEATURES field (offset 3B0h) in the Save State

> Area to control the SEV-SNP guest features such as SNPActive, vTOM,

> ReflectVC etc. An SEV-SNP guest can read the SEV_FEATURES fields through

> the SEV_STATUS MSR.

> 

> While at it, update the dump_vmcb() to log the VMPL level.

> 

> See APM2 Table 15-34 and B-4 for more details.

> 

> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>

> ---

>  arch/x86/include/asm/svm.h | 15 +++++++++++++--

>  arch/x86/kvm/svm/svm.c     |  4 ++--

>  2 files changed, 15 insertions(+), 4 deletions(-)

> 

> diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h

> index 772e60efe243..ff614cdcf628 100644

> --- a/arch/x86/include/asm/svm.h

> +++ b/arch/x86/include/asm/svm.h

> @@ -212,6 +212,15 @@ struct __attribute__ ((__packed__)) vmcb_control_area {

>  #define SVM_NESTED_CTL_SEV_ENABLE	BIT(1)

>  #define SVM_NESTED_CTL_SEV_ES_ENABLE	BIT(2)

>  

> +#define SVM_SEV_FEATURES_SNP_ACTIVE		BIT(0)

> +#define SVM_SEV_FEATURES_VTOM			BIT(1)

> +#define SVM_SEV_FEATURES_REFLECT_VC		BIT(2)

> +#define SVM_SEV_FEATURES_RESTRICTED_INJECTION	BIT(3)

> +#define SVM_SEV_FEATURES_ALTERNATE_INJECTION	BIT(4)

> +#define SVM_SEV_FEATURES_DEBUG_SWAP		BIT(5)

> +#define SVM_SEV_FEATURES_PREVENT_HOST_IBS	BIT(6)

> +#define SVM_SEV_FEATURES_BTB_ISOLATION		BIT(7)


Only some of those get used and only later. Please introduce only those
with the patch that adds usage.

Also,

s/SVM_SEV_FEATURES_/SVM_SEV_FEAT_/g

at least.

And by the way, why is this patch and the next 3 part of the guest set?
They look like they belong into the hypervisor set.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette
Brijesh Singh Aug. 17, 2021, 6:11 p.m. UTC | #7
On 8/17/21 12:54 PM, Borislav Petkov wrote:
> On Wed, Jul 07, 2021 at 01:14:46PM -0500, Brijesh Singh wrote:
>> The hypervisor uses the SEV_FEATURES field (offset 3B0h) in the Save State
>> Area to control the SEV-SNP guest features such as SNPActive, vTOM,
>> ReflectVC etc. An SEV-SNP guest can read the SEV_FEATURES fields through
>> the SEV_STATUS MSR.
>>
>> While at it, update the dump_vmcb() to log the VMPL level.
>>
>> See APM2 Table 15-34 and B-4 for more details.
>>
>> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
>> ---
>>   arch/x86/include/asm/svm.h | 15 +++++++++++++--
>>   arch/x86/kvm/svm/svm.c     |  4 ++--
>>   2 files changed, 15 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/x86/include/asm/svm.h b/arch/x86/include/asm/svm.h
>> index 772e60efe243..ff614cdcf628 100644
>> --- a/arch/x86/include/asm/svm.h
>> +++ b/arch/x86/include/asm/svm.h
>> @@ -212,6 +212,15 @@ struct __attribute__ ((__packed__)) vmcb_control_area {
>>   #define SVM_NESTED_CTL_SEV_ENABLE	BIT(1)
>>   #define SVM_NESTED_CTL_SEV_ES_ENABLE	BIT(2)
>>   
>> +#define SVM_SEV_FEATURES_SNP_ACTIVE		BIT(0)
>> +#define SVM_SEV_FEATURES_VTOM			BIT(1)
>> +#define SVM_SEV_FEATURES_REFLECT_VC		BIT(2)
>> +#define SVM_SEV_FEATURES_RESTRICTED_INJECTION	BIT(3)
>> +#define SVM_SEV_FEATURES_ALTERNATE_INJECTION	BIT(4)
>> +#define SVM_SEV_FEATURES_DEBUG_SWAP		BIT(5)
>> +#define SVM_SEV_FEATURES_PREVENT_HOST_IBS	BIT(6)
>> +#define SVM_SEV_FEATURES_BTB_ISOLATION		BIT(7)
> 
> Only some of those get used and only later. Please introduce only those
> with the patch that adds usage.
> 

Okay.

> Also,
> 
> s/SVM_SEV_FEATURES_/SVM_SEV_FEAT_/g
> 

I can do that.

> at least.
> 
> And by the way, why is this patch and the next 3 part of the guest set?
> They look like they belong into the hypervisor set.
> 

This is needed by the AP creation, in SNP the AP creation need to 
populate the VMSA page and thus need to use some of macros and fields  etc.