linux-kernel - Re: [PATCH] x86/mm: Create an SME workarea in the kernel for early encryption

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:   Thu, 13 Jun 2019 18:58:14 +0000
From:   "Lendacky, Thomas" <Thomas.Lendacky@....com>
To:     Dave Hansen <dave.hansen@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "x86@...nel.org" <x86@...nel.org>
CC:     Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Baoquan He <bhe@...hat.com>, Lianbo Jiang <lijiang@...hat.com>
Subject: Re: [PATCH] x86/mm: Create an SME workarea in the kernel for early
 encryption

On 6/13/19 1:06 PM, Dave Hansen wrote:
> On 6/13/19 10:59 AM, Lendacky, Thomas wrote:
>>> After I say all that...  Why can't you just stick your data in a normal,
>>> vanilla __init variable?  Wouldn't that be a lot less subtle?
>> The area needs to be outside of the kernel proper as the kernel is
>> encrypted "in place." So an __init variable won't work here.
> 
> Ahh, that makes sense.  Also sounds like good changelog fodder.
> 
> FWIW, you *could* use an __init area, but I think you'd have to work
> around it in sme_encrypt_kernel(), right?  Basically in the
> kernel_start/end logic you'd need to skip over it.  That's probably more
> fragile than what you have here, though.

Yes, I think having the workarea outside the kernel is best.

I'll send a V2 with the pre-patch and suggested changes.

Thanks,
Tom

>