linux-kernel - Re: [PATCH v9 30/43] KVM: SEV: Add documentation for SEV-SNP CPUID Enforcement

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 7 Feb 2022 23:48:11 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Brijesh Singh <brijesh.singh@....com>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        linux-efi@...r.kernel.org, platform-driver-x86@...r.kernel.org,
        linux-coco@...ts.linux.dev, linux-mm@...ck.org,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Joerg Roedel <jroedel@...e.de>,
        Tom Lendacky <thomas.lendacky@....com>,
        "H. Peter Anvin" <hpa@...or.com>, Ard Biesheuvel <ardb@...nel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Jim Mattson <jmattson@...gle.com>,
        Andy Lutomirski <luto@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Sergio Lopez <slp@...hat.com>, Peter Gonda <pgonda@...gle.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        David Rientjes <rientjes@...gle.com>,
        Dov Murik <dovmurik@...ux.ibm.com>,
        Tobin Feldman-Fitzthum <tobin@....com>,
        Borislav Petkov <bp@...en8.de>,
        Michael Roth <michael.roth@....com>,
        Vlastimil Babka <vbabka@...e.cz>,
        "Kirill A . Shutemov" <kirill@...temov.name>,
        Andi Kleen <ak@...ux.intel.com>,
        "Dr . David Alan Gilbert" <dgilbert@...hat.com>,
        brijesh.ksingh@...il.com, tony.luck@...el.com, marcorr@...gle.com,
        sathyanarayanan.kuppuswamy@...ux.intel.com
Subject: Re: [PATCH v9 30/43] KVM: SEV: Add documentation for SEV-SNP CPUID
 Enforcement

On Fri, Jan 28, 2022, Brijesh Singh wrote:
> From: Michael Roth <michael.roth@....com>
> 
> Update the documentation with SEV-SNP CPUID enforcement.
> 
> Signed-off-by: Michael Roth <michael.roth@....com>
> Signed-off-by: Brijesh Singh <brijesh.singh@....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.