linux-kernel - Re: [PATCH RFC v9 07/51] x86/sev: Add the host SEV-SNP initialization support

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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 21 Jun 2023 09:36:11 -0500
From:   Tom Lendacky <thomas.lendacky@....com>
To:     Borislav Petkov <bp@...en8.de>, Michael Roth <michael.roth@....com>
Cc:     kvm@...r.kernel.org, linux-coco@...ts.linux.dev,
        linux-mm@...ck.org, linux-crypto@...r.kernel.org, x86@...nel.org,
        linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com,
        jroedel@...e.de, hpa@...or.com, ardb@...nel.org,
        pbonzini@...hat.com, seanjc@...gle.com, vkuznets@...hat.com,
        jmattson@...gle.com, luto@...nel.org, dave.hansen@...ux.intel.com,
        slp@...hat.com, pgonda@...gle.com, peterz@...radead.org,
        srinivas.pandruvada@...ux.intel.com, rientjes@...gle.com,
        dovmurik@...ux.ibm.com, tobin@....com, vbabka@...e.cz,
        kirill@...temov.name, ak@...ux.intel.com, tony.luck@...el.com,
        marcorr@...gle.com, sathyanarayanan.kuppuswamy@...ux.intel.com,
        alpergun@...gle.com, dgilbert@...hat.com, jarkko@...nel.org,
        ashish.kalra@....com, nikunj.dadhania@....com,
        liam.merwick@...cle.com, zhi.a.wang@...el.com,
        Brijesh Singh <brijesh.singh@....com>
Subject: Re: [PATCH RFC v9 07/51] x86/sev: Add the host SEV-SNP initialization
 support

On 6/21/23 04:42, Borislav Petkov wrote:
> On Sun, Jun 11, 2023 at 11:25:15PM -0500, Michael Roth wrote:
>> From: Brijesh Singh <brijesh.singh@....com>
>>
>> The memory integrity guarantees of SEV-SNP are enforced through a new
>> structure called the Reverse Map Table (RMP). The RMP is a single data
>> structure shared across the system that contains one entry for every 4K
>> page of DRAM that may be used by SEV-SNP VMs. APM2 section 15.36 details
> 
> Rather say 'APM v2, section "Secure Nested Paging (SEV-SNP)"' because
> the numbering is more likely to change than the name in the future. With
> the name, people can find it faster.
> 
>> a number of steps needed to detect/enable SEV-SNP and RMP table support
>> on the host:
>>
>>   - Detect SEV-SNP support based on CPUID bit
>>   - Initialize the RMP table memory reported by the RMP base/end MSR
>>     registers and configure IOMMU to be compatible with RMP access
>>     restrictions
>>   - Set the MtrrFixDramModEn bit in SYSCFG MSR
>>   - Set the SecureNestedPagingEn and VMPLEn bits in the SYSCFG MSR
>>   - Configure IOMMU
>>
>> RMP table entry format is non-architectural and it can vary by
>> processor. It is defined by the PPR. Restrict SNP support to CPU
>> models/families which are compatible with the current RMP table entry
>> format to guard against any undefined behavior when running on other
>> system types. Future models/support will handle this through an
>> architectural mechanism to allow for broader compatibility.
> 
> I'm guessing this is all for live migration between SNP hosts. If so,
> then there will have to be a guest API to handle the differences.
> 
>> SNP host code depends on CONFIG_KVM_AMD_SEV config flag, which may be
>> enabled even when CONFIG_AMD_MEM_ENCRYPT isn't set, so update the
>> SNP-specific IOMMU helpers used here to rely on CONFIG_KVM_AMD_SEV
>> instead of CONFIG_AMD_MEM_ENCRYPT.
> 
> Does that mean that even on CONFIG_AMD_MEM_ENCRYPT=n kernels, host SNP
> can function?

Yes, because CONFIG_AMD_MEM_ENCRYPT is mainly for dealing with the 
encryption bit.

> 
> Do we even want that?

We support that today with SEV and SEV-ES guests. The host/hypervisor 
kernel does not need CONFIG_AMD_MEM_ENCRYPT=y in order to run SEV guests.

> 
> I'd expect that a host SNP kernel should have SME enabled too even
> though it is not absolutely necessary.

I recommend using TSME over SME.

Thanks,
Tom

> 
>> Co-developed-by: Ashish Kalra <ashish.kalra@....com>
>> Signed-off-by: Ashish Kalra <ashish.kalra@....com>
>> Co-developed-by: Tom Lendacky <thomas.lendacky@....com>
>> Signed-off-by: Tom Lendacky <thomas.lendacky@....com>
>> Signed-off-by: Brijesh Singh <brijesh.singh@....com>
>> [mdr: rework commit message to be clearer about what patch does, squash
>>        in early_rmptable_check() handling from Tom]
>> Signed-off-by: Michael Roth <michael.roth@....com>
>> ---
>>   arch/x86/coco/Makefile                   |   1 +
>>   arch/x86/coco/sev/Makefile               |   3 +
>>   arch/x86/coco/sev/host.c                 | 212 +++++++++++++++++++++++
>>   arch/x86/include/asm/disabled-features.h |   8 +-
>>   arch/x86/include/asm/msr-index.h         |  11 +-
>>   arch/x86/include/asm/sev.h               |   2 +
>>   arch/x86/kernel/cpu/amd.c                |  19 ++
>>   drivers/iommu/amd/init.c                 |   2 +-
>>   include/linux/amd-iommu.h                |   2 +-
>>   9 files changed, 256 insertions(+), 4 deletions(-)
>>   create mode 100644 arch/x86/coco/sev/Makefile
>>   create mode 100644 arch/x86/coco/sev/host.c
> 
> Ignored review comments here:
> 
> https://lore.kernel.org/r/Y9ubi0i4Z750gdMm@zn.tnic
> 
> Ignoring this one for now too.
>