linux-kernel - Re: [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: <601d5972-72b0-6556-0054-7275cb763816@amd.com>
Date:   Fri, 9 Jun 2017 16:20:35 -0500
From:   Tom Lendacky <thomas.lendacky@....com>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     linux-arch <linux-arch@...r.kernel.org>,
        "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
        kvm list <kvm@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        X86 ML <x86@...nel.org>, kexec@...ts.infradead.org,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        kasan-dev <kasan-dev@...glegroups.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        iommu@...ts.linux-foundation.org, Rik van Riel <riel@...hat.com>,
        Radim Krčmář <rkrcmar@...hat.com>,
        Toshimitsu Kani <toshi.kani@....com>,
        Arnd Bergmann <arnd@...db.de>,
        Jonathan Corbet <corbet@....net>,
        Matt Fleming <matt@...eblueprint.co.uk>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Joerg Roedel <joro@...tes.org>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Larry Woodman <lwoodman@...hat.com>,
        Brijesh Singh <brijesh.singh@....com>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        "H. Peter Anvin" <hpa@...or.com>,
        Andrey Ryabinin <aryabinin@...tuozzo.com>,
        Alexander Potapenko <glider@...gle.com>,
        Dave Young <dyoung@...hat.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Dmitry Vyukov <dvyukov@...gle.com>
Subject: Re: [PATCH v6 10/34] x86, x86/mm, x86/xen, olpc: Use __va() against
 just the physical address in cr3

On 6/9/2017 1:46 PM, Andy Lutomirski wrote:
> On Thu, Jun 8, 2017 at 3:38 PM, Tom Lendacky <thomas.lendacky@....com> wrote:
>> On 6/8/2017 1:05 AM, Andy Lutomirski wrote:
>>>
>>> On Wed, Jun 7, 2017 at 12:14 PM, Tom Lendacky <thomas.lendacky@....com>
>>> wrote:
>>>>
>>>> The cr3 register entry can contain the SME encryption bit that indicates
>>>> the PGD is encrypted.  The encryption bit should not be used when
>>>> creating
>>>> a virtual address for the PGD table.
>>>>
>>>> Create a new function, read_cr3_pa(), that will extract the physical
>>>> address from the cr3 register. This function is then used where a virtual
>>>> address of the PGD needs to be created/used from the cr3 register.
>>>
>>>
>>> This is going to conflict with:
>>>
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/pcid&id=555c81e5d01a62b629ec426a2f50d27e2127c1df
>>>
>>> We're both encountering the fact that CR3 munges the page table PA
>>> with some other stuff, and some readers want to see the actual CR3
>>> value and other readers just want the PA.  The thing I prefer about my
>>> patch is that I get rid of read_cr3() entirely, forcing the patch to
>>> update every single reader, making review and conflict resolution much
>>> safer.
>>>
>>> I'd be willing to send a patch tomorrow that just does the split into
>>> __read_cr3() and read_cr3_pa() (I like your name better) and then we
>>> can both base on top of it.  Would that make sense?
>>
>>
>> That makes sense to me.
> 
> Draft patch:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/commit/?h=x86/read_cr3&id=9adebbc1071f066421a27b4f6e040190f1049624

Looks good to me. I'll look at how to best mask off the encryption bit
in CR3_ADDR_MASK for SME support.  I should be able to just do an
__sme_clr() against it.

> 
>>
>>>
>>> Also:
>>>
>>>> +static inline unsigned long read_cr3_pa(void)
>>>> +{
>>>> +       return (read_cr3() & PHYSICAL_PAGE_MASK);
>>>> +}
>>>
>>>
>>> Is there any guarantee that the magic encryption bit is masked out in
>>> PHYSICAL_PAGE_MASK?  The docs make it sound like it could be any bit.
>>> (But if it's one of the low 12 bits, that would be quite confusing.)
>>
>>
>> Right now it's bit 47 and we're steering away from any of the currently
>> reserved bits so we should be safe.
> 
> Should the SME init code check that it's a usable bit (i.e. outside
> our physical address mask and not one of the bottom twelve bits)?  If
> some future CPU daftly picks, say, bit 12, we'll regret it if we
> enable SME.

I think I can safely say that it will never be any of the lower 12 bits,
but let me talk to some of the hardware folks and see about the other
end of the range.

Thanks,
Tom

> 
> --Andy
>