| Message ID | 20220128171804.569796-31-brijesh.singh@amd.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add AMD Secure Nested Paging (SEV-SNP) Guest Support | expand |
On Fri, Jan 28, 2022, 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 1c6847fff304..0c72f44cc11a 100644 > --- a/Documentation/virt/kvm/amd-memory-encryption.rst > +++ b/Documentation/virt/kvm/amd-memory-encryption.rst This doc is specifically for KVM's host-side implemenation, whereas the below is (a) mostly targeted at the guest and (b) has nothing to do with KVM. Documentation/x86/amd-memory-encryption.rst isn't a great fit either. Since TDX will need a fair bit of documentation, and SEV-ES could retroactively use docs as well, what about adding a sub-directory: Documentation/virt/confidential_compute to match the "cc_platform_has" stuffr, and then we can add sev.rst and tdx.rst there? Or sev-es.rst, sev-snp.rst, etc... if we want to split things up more. It might be worth extracting the SEV details from x86/amd-memory-encryption.rst into virt/ as well. A big chunk of that file appears to be SEV specific, and it appears to have gotten a little out-of-whack. E.g. this section no longer makes sense as the last paragraph below appears to be talking about SME (bit 23 in MSR 0xc0010010), but walking back "this bit" would reference SEV. I suspect a mostly-standalone sev.rst would be easier to follow than an intertwined SME+SEV. If support for SME is present, MSR 0xc00100010 (MSR_AMD64_SYSCFG) can be used to determine if SME is enabled and/or to enable memory encryption:: 0xc0010010: Bit[23] 0 = memory encryption features are disabled 1 = memory encryption features are enabled If SEV is supported, MSR 0xc0010131 (MSR_AMD64_SEV) can be used to determine if SEV is active:: 0xc0010131: Bit[0] 0 = memory encryption is not active 1 = memory encryption is active Linux relies on BIOS to set this bit if BIOS has determined that the reduction in the physical address space as a result of enabling memory encryption (see CPUID information above) will not conflict with the address space resource requirements for the system. If this bit is not set upon Linux startup then Linux itself will not set it and memory encryption will not be possible.
On Mon, Feb 07, 2022 at 11:48:11PM +0000, Sean Christopherson wrote: > On Fri, Jan 28, 2022, 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 1c6847fff304..0c72f44cc11a 100644 > > --- a/Documentation/virt/kvm/amd-memory-encryption.rst > > +++ b/Documentation/virt/kvm/amd-memory-encryption.rst > > This doc is specifically for KVM's host-side implemenation, whereas the below is > (a) mostly targeted at the guest and (b) has nothing to do with KVM. > > Documentation/x86/amd-memory-encryption.rst isn't a great fit either. > > Since TDX will need a fair bit of documentation, and SEV-ES could retroactively > use docs as well, what about adding a sub-directory: > > Documentation/virt/confidential_compute There's actually a Documentation/virt/coco/sevguest.rst that was added in this series as part of: "virt: Add SEV-SNP guest driver" Maybe that's good choice? I've been wondering about potentially adding the: "Guest/Hypervisor Implementation Notes for SEV-SNP CPUID Enforcement" document that was sent to SNP mailing list under Documentation/ somewhere. If we were to do that, it would be a good place to move the documentation from this patch into as well. Any thoughts on that? > > to match the "cc_platform_has" stuffr, and then we can add sev.rst and tdx.rst > there? Or sev-es.rst, sev-snp.rst, etc... if we want to split things up more. > > It might be worth extracting the SEV details from x86/amd-memory-encryption.rst > into virt/ as well. A big chunk of that file appears to be SEV specific, and it > appears to have gotten a little out-of-whack. E.g. this section no longer makes > sense as the last paragraph below appears to be talking about SME (bit 23 in MSR > 0xc0010010), but walking back "this bit" would reference SEV. I suspect a > mostly-standalone sev.rst would be easier to follow than an intertwined SME+SEV. > > If support for SME is present, MSR 0xc00100010 (MSR_AMD64_SYSCFG) can be used to > determine if SME is enabled and/or to enable memory encryption:: > > 0xc0010010: > Bit[23] 0 = memory encryption features are disabled > 1 = memory encryption features are enabled > > If SEV is supported, MSR 0xc0010131 (MSR_AMD64_SEV) can be used to determine if > SEV is active:: > > 0xc0010131: > Bit[0] 0 = memory encryption is not active > 1 = memory encryption is active > > Linux relies on BIOS to set this bit if BIOS has determined that the reduction > in the physical address space as a result of enabling memory encryption (see > CPUID information above) will not conflict with the address space resource > requirements for the system. If this bit is not set upon Linux startup then > Linux itself will not set it and memory encryption will not be possible. I'll check with Brijesh on these. Thanks! -Mike
On Mon, Feb 07, 2022 at 11:48:11PM +0000, Sean Christopherson wrote: > It might be worth extracting the SEV details from x86/amd-memory-encryption.rst > into virt/ as well. A big chunk of that file appears to be SEV specific, and it My personal preference would be to keep *all* SEV stuff in a single file for easier grepping and have everything together. But that's just me. Thx.
diff --git a/Documentation/virt/kvm/amd-memory-encryption.rst b/Documentation/virt/kvm/amd-memory-encryption.rst index 1c6847fff304..0c72f44cc11a 100644 --- a/Documentation/virt/kvm/amd-memory-encryption.rst +++ b/Documentation/virt/kvm/amd-memory-encryption.rst @@ -433,6 +433,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 the 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), and those + binaries 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 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 the 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 ==========