linux-kernel - Re: [PATCH v2] KVM: SVM: Override default MMIO mask if memory encryption is enabled

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:   Tue, 7 Jan 2020 14:16:37 -0600
From:   Tom Lendacky <thomas.lendacky@....com>
To:     Sean Christopherson <sean.j.christopherson@...el.com>
Cc:     kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
        Paolo Bonzini <pbonzini@...hat.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>,
        Brijesh Singh <brijesh.singh@....com>
Subject: Re: [PATCH v2] KVM: SVM: Override default MMIO mask if memory
 encryption is enabled

On 1/6/20 5:38 PM, Sean Christopherson wrote:
> On Mon, Jan 06, 2020 at 05:14:04PM -0600, Tom Lendacky wrote:
>> On 1/6/20 4:49 PM, Sean Christopherson wrote:
>>> This doesn't handle the case where x86_phys_bits _isn't_ reduced by SME/SEV
>>> on a future processor, i.e. x86_phys_bits==52.
>>
>> Not sure I follow. If MSR_K8_SYSCFG_MEM_ENCRYPT is set then there will
>> always be a reduction in physical addressing (so I'm told).
> 
> Hmm, I'm going off APM Vol 2, which states, or at least strongly implies,
> that reducing the PA space is optional.  Section 7.10.2 is especially
> clear on this:
> 
>   In implementations where the physical address size of the processor is
>   reduced when memory encryption features are enabled, software must
>   ensure it is executing from addresses where these upper physical address
>   bits are 0 prior to setting SYSCFG[MemEncryptionModEn].

It's probably not likely, but given what is stated, I can modify my patch
to check for a x86_phys_bits == 52 and skip the call to set the mask, eg:

	if (msr & MSR_K8_SYSCFG_MEM_ENCRYPT &&
	    boot_cpu_data.x86_phys_bits < 52) {

> 
> But, hopefully the other approach I have in mind actually works, as it's
> significantly less special-case code and would naturally handle either
> case, i.e. make this a moot point.

I'll hold off on the above and wait for your patch.

Thanks,
Tom

> 
> 
> Entry on SYSCFG:
> 
>   3.2.1 System Configuration Register (SYSCFG)
> 
>   ...
> 
>   MemEncryptionMode. Bit 23.  Setting this bit to 1 enables the SME and
>   SEV memory encryption features.
> 
> The SME entry the above links to says:
> 
>   7.10.1 Determining Support for Secure Memory Encryption
> 
>   ...
> 
>   Additionally, in some implementations, the physical address size of the
>   processor may be reduced when memory encryption features are enabled, for
>   example from 48 to 43 bits. In this case the upper physical address bits are
>   treated as reserved when the feature is enabled except where otherwise
>   indicated. When memory encryption is supported in an implementation, CPUID
>   Fn8000_001F[EBX] reports any physical address size reduction present. Bits
>   reserved in this mode are treated the same as other page table reserved bits,
>   and will generate a page fault if found to be non-zero when used for address
>   translation.
> 
>   ...
> 
>   7.10.2 Enabling Memory Encryption Extensions
> 
>   Prior to using SME, memory encryption features must be enabled by setting
>   SYSCFG MSR bit 23 (MemEncryptionModEn) to 1. In implementations where the
>   physical address size of the processor is reduced when memory encryption
>   features are enabled, software must ensure it is executing from addresses where
>   these upper physical address bits are 0 prior to setting
>   SYSCFG[MemEncryptionModEn]. Memory encryption is then further controlled via
>   the page tables.
>