linux-kernel - Re: [PATCH v7 34/36] x86/mm: Add support to encrypt the kernel in-place

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] [day] [month] [year] [list]

Date:   Mon, 26 Jun 2017 11:34:49 -0500
From:   Tom Lendacky <thomas.lendacky@....com>
To:     Borislav Petkov <bp@...en8.de>
Cc:     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, xen-devel@...ts.xen.org,
        linux-mm@...ck.org, iommu@...ts.linux-foundation.org,
        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>,
        Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
        Andy Lutomirski <luto@...nel.org>,
        Boris Ostrovsky <boris.ostrovsky@...cle.com>,
        Dmitry Vyukov <dvyukov@...gle.com>,
        Juergen Gross <jgross@...e.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Paolo Bonzini <pbonzini@...hat.com>
Subject: Re: [PATCH v7 34/36] x86/mm: Add support to encrypt the kernel
 in-place

On 6/26/2017 10:45 AM, Borislav Petkov wrote:
> On Fri, Jun 23, 2017 at 12:44:46PM -0500, Tom Lendacky wrote:
>> Normally the __p4d() macro would be used and that would be ok whether
>> CONFIG_X86_5LEVEL is defined or not. But since __p4d() is part of the
>> paravirt ops path I have to use native_make_p4d().
> 
> So __p4d is in !CONFIG_PARAVIRT path.
> 
> Regardless, we use the native_* variants in generic code to mean, not
> paravirt. Just define it in a separate patch like the rest of the p4*
> machinery and use it in your code. Sooner or later someone else will
> need it.

Ok, will do.

> 
>> True, 5-level will only be turned on for specific hardware which is why
>> I originally had this as only 4-level pagetables. But in a comment from
>> you back on the v5 version you said it needed to support 5-level. I
>> guess we should have discussed this more,
> 
> AFAIR, I said something along the lines of "what about 5-level page
> tables?" and whether we care.

My bad, I took the meaning of that question the wrong way then.

Thanks,
Tom

> 
>> but I also thought that should our hardware ever support 5-level
>> paging in the future then this would be good to go.
> 
> There it is :-)
> 
>> The macros work great if you are not running identity mapped. You could
>> use p*d_offset() to move easily through the tables, but those functions
>> use __va() to generate table virtual addresses. I've seen where
>> boot/compressed/pagetable.c #defines __va() to work with identity mapped
>> pages but that would only work if I create a separate file just for this
>> function.
>>
>> Given when this occurs it's very similar to what __startup_64() does in
>> regards to the IS_ENABLED(CONFIG_X86_5LEVEL) checks.
> 
> Ok.
>