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]

Message-ID: <20220208145439.ozw4cjhqfvozewl4@amd.com>
Date:   Tue, 8 Feb 2022 08:54:39 -0600
From:   Michael Roth <michael.roth@....com>
To:     Sean Christopherson <seanjc@...gle.com>
CC:     Brijesh Singh <brijesh.singh@....com>, <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>,
        "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 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@....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

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