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: <9725c503-2e33-2365-87f5-f017e1cbe9b6@amd.com>
Date:   Fri, 9 Jun 2017 13:36:35 -0500
From:   Tom Lendacky <thomas.lendacky@....com>
To:     Andrew Cooper <andrew.cooper3@...rix.com>,
        Boris Ostrovsky <boris.ostrovsky@...cle.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/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?

> 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
>