| Message ID | 20211210154332.11526-29-brijesh.singh@amd.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Add AMD Secure Nested Paging (SEV-SNP) Guest Support | expand |
On Fri, Dec 10, 2021 at 09:43:20AM -0600, Brijesh Singh wrote: > From: Michael Roth <michael.roth@amd.com> > > Update the documentation with SEV-SNP CPUID enforcement. > > Signed-off-by: Michael Roth <michael.roth@amd.com> > Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> > --- > .../virt/kvm/amd-memory-encryption.rst | 28 +++++++++++++++++++ > 1 file changed, 28 insertions(+) > > diff --git a/Documentation/virt/kvm/amd-memory-encryption.rst b/Documentation/virt/kvm/amd-memory-encryption.rst > index 5c081c8c7164..aa8292fa579a 100644 > --- a/Documentation/virt/kvm/amd-memory-encryption.rst > +++ b/Documentation/virt/kvm/amd-memory-encryption.rst > @@ -427,6 +427,34 @@ issued by the hypervisor to make the guest ready for execution. > > Returns: 0 on success, -negative on error > > +SEV-SNP CPUID Enforcement > +========================= > + > +SEV-SNP guests can access a special page that contains a table of CPUID values > +that have been validated by the PSP as part of SNP_LAUNCH_UPDATE firmware ^ the > +command. It provides the following assurances regarding the validity of CPUID > +values: > + > + - Its address is obtained via bootloader/firmware (via CC blob), whose > + binares will be measured as part of the SEV-SNP attestation report. Unknown word [binares] in Documentation. Suggestions: ['binaries', 'Linares', 'bi nares', 'bi-nares', 'bin ares', 'bin-ares', 'nares'] Also: s/whose binaries/and those binaries/ > + - Its initial state will be encrypted/pvalidated, so attempts to modify > + it during run-time will be result in garbage being written, or #VC s/be // > + exceptions being generated due to changes in validation state if the > + hypervisor tries to swap the backing page. > + - Attempts to bypass PSP checks by hypervisor by using a normal page, or a ^ the > + non-CPUID encrypted page will change the measurement provided by the > + SEV-SNP attestation report. > + - The CPUID page contents are *not* measured, but attempts to modify the > + expected contents of a CPUID page as part of guest initialization will be > + gated by the PSP CPUID enforcement policy checks performed on the page > + during SNP_LAUNCH_UPDATE, and noticeable later if the guest owner > + implements their own checks of the CPUID values. > + > +It is important to note that this last assurance is only useful if the kernel > +has taken care to make use of the SEV-SNP CPUID throughout all stages of boot. > +Otherwise guest owner attestation provides no assurance that the kernel wasn't ^ , > +fed incorrect values at some point during boot. > + > References > ========== > > -- > 2.25.1 >
diff --git a/Documentation/virt/kvm/amd-memory-encryption.rst b/Documentation/virt/kvm/amd-memory-encryption.rst index 5c081c8c7164..aa8292fa579a 100644 --- a/Documentation/virt/kvm/amd-memory-encryption.rst +++ b/Documentation/virt/kvm/amd-memory-encryption.rst @@ -427,6 +427,34 @@ issued by the hypervisor to make the guest ready for execution. Returns: 0 on success, -negative on error +SEV-SNP CPUID Enforcement +========================= + +SEV-SNP guests can access a special page that contains a table of CPUID values +that have been validated by the PSP as part of SNP_LAUNCH_UPDATE firmware +command. It provides the following assurances regarding the validity of CPUID +values: + + - Its address is obtained via bootloader/firmware (via CC blob), whose + binares will be measured as part of the SEV-SNP attestation report. + - Its initial state will be encrypted/pvalidated, so attempts to modify + it during run-time will be result in garbage being written, or #VC + exceptions being generated due to changes in validation state if the + hypervisor tries to swap the backing page. + - Attempts to bypass PSP checks by hypervisor by using a normal page, or a + non-CPUID encrypted page will change the measurement provided by the + SEV-SNP attestation report. + - The CPUID page contents are *not* measured, but attempts to modify the + expected contents of a CPUID page as part of guest initialization will be + gated by the PSP CPUID enforcement policy checks performed on the page + during SNP_LAUNCH_UPDATE, and noticeable later if the guest owner + implements their own checks of the CPUID values. + +It is important to note that this last assurance is only useful if the kernel +has taken care to make use of the SEV-SNP CPUID throughout all stages of boot. +Otherwise guest owner attestation provides no assurance that the kernel wasn't +fed incorrect values at some point during boot. + References ==========