linux-kernel - Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against just the physical address in cr3

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: <33f20df0-bf71-bd9d-7a7e-4fb5e8793400@amd.com>
Date:   Fri, 9 Jun 2017 13:59:21 -0500
From:   Tom Lendacky <thomas.lendacky@....com>
To:     Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Andrew Cooper <andrew.cooper3@...rix.com>,
        linux-arch@...r.kernel.org, linux-efi@...r.kernel.org,
        kvm@...r.kernel.org, linux-doc@...r.kernel.org, x86@...nel.org,
        kexec@...ts.infradead.org, linux-kernel@...r.kernel.org,
        kasan-dev@...glegroups.com, linux-mm@...ck.org,
        iommu@...ts.linux-foundation.org
Cc:     Brijesh Singh <brijesh.singh@....com>,
        Toshimitsu Kani <toshi.kani@....com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Matt Fleming <matt@...eblueprint.co.uk>,
        Alexander Potapenko <glider@...gle.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Larry Woodman <lwoodman@...hat.com>,
        Jonathan Corbet <corbet@....net>,
        Joerg Roedel <joro@...tes.org>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Ingo Molnar <mingo@...hat.com>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Dave Young <dyoung@...hat.com>, Rik van Riel <riel@...hat.com>,
        Arnd Bergmann <arnd@...db.de>, Borislav Petkov <bp@...en8.de>,
        Andy Lutomirski <luto@...nel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Juergen Gross <jgross@...e.com>,
        xen-devel <xen-devel@...ts.xen.org>,
        Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [Xen-devel] [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use
 __va() against just the physical address in cr3

On 6/9/2017 1:43 PM, Boris Ostrovsky wrote:
> On 06/09/2017 02:36 PM, Tom Lendacky wrote:
>> On 6/8/2017 5:01 PM, Andrew Cooper wrote:
>>> On 08/06/2017 22:17, Boris Ostrovsky wrote:
>>>> On 06/08/2017 05:02 PM, Tom Lendacky wrote:
>>>>> On 6/8/2017 3:51 PM, Boris Ostrovsky wrote:
>>>>>>>> What may be needed is making sure X86_FEATURE_SME is not set for PV
>>>>>>>> guests.
>>>>>>> And that may be something that Xen will need to control through
>>>>>>> either
>>>>>>> CPUID or MSR support for the PV guests.
>>>>>>
>>>>>> Only on newer versions of Xen. On earlier versions (2-3 years old)
>>>>>> leaf
>>>>>> 0x80000007 is passed to the guest unchanged. And so is MSR_K8_SYSCFG.
>>>>> The SME feature is in leaf 0x8000001f, is that leaf passed to the
>>>>> guest
>>>>> unchanged?
>>>> Oh, I misread the patch where X86_FEATURE_SME is defined. Then all
>>>> versions, including the current one, pass it unchanged.
>>>>
>>>> All that's needed is setup_clear_cpu_cap(X86_FEATURE_SME) in
>>>> xen_init_capabilities().
>>>
>>> AMD processors still don't support CPUID Faulting (or at least, I
>>> couldn't find any reference to it in the latest docs), so we cannot
>>> actually hide SME from a guest which goes looking at native CPUID.
>>> Furthermore, I'm not aware of any CPUID masking support covering that
>>> leaf.
>>>
>>> However, if Linux is using the paravirtual cpuid hook, things are
>>> slightly better.
>>>
>>> On Xen 4.9 and later, no guests will see the feature.  On earlier
>>> versions of Xen (before I fixed the logic), plain domUs will not see the
>>> feature, while dom0 will.
>>>
>>> For safely, I'd recommend unilaterally clobbering the feature as Boris
>>> suggested.  There is no way SME will be supportable on a per-PV guest
>>
>> That may be too late. Early boot support in head_64.S will make calls to
>> check for the feature (through CPUID and MSR), set the sme_me_mask and
>> encrypt the kernel in place. Is there another way to approach this?
> 
> 
> PV guests don't go through Linux x86 early boot code. They start at
> xen_start_kernel() (well, xen-head.S:startup_xen(), really) and  merge
> with baremetal path at x86_64_start_reservations() (for 64-bit).
> 

Ok, I don't think anything needs to be done then. The sme_me_mask is set
in sme_enable() which is only called from head_64.S. If the sme_me_mask
isn't set then SME won't be active. The feature will just report the
capability of the processor, but that doesn't mean it is active. If you
still want the feature to be clobbered we can do that, though.

Thanks,
Tom

> 
> -boris
> 
>>
>>> basis, although (as far as I am aware) Xen as a whole would be able to
>>> encompass itself and all of its PV guests inside one single SME
>>> instance.
>>
>> Yes, that is correct.
>>
>> Thanks,
>> Tom
>>
>>>
>>> ~Andrew
>>>
>