linux-kernel - Re: [PATCH] x86/mm: Unbreak modules that rely on external PAGE

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: <20171108214522.n5ewoijugodmmiec@pd.tnic>
Date:   Wed, 8 Nov 2017 22:45:22 +0100
From:   Borislav Petkov <bp@...e.de>
To:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Tom Lendacky <thomas.lendacky@....com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Jiri Kosina <jikos@...nel.org>, Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        LKML <linux-kernel@...r.kernel.org>,
        linux-mm <linux-mm@...ck.org>,
        the arch/x86 maintainers <x86@...nel.org>,
        Greg KH <greg@...ah.com>
Subject: Re: [PATCH] x86/mm: Unbreak modules that rely on external
 PAGE_KERNEL availability

On Wed, Nov 08, 2017 at 01:23:37PM -0800, Linus Torvalds wrote:
> I was thinking that maybe we could have a fixed "encrypt" bit in our
> PTE, and then replace that "software bit" with whatever the real
> hardware mask is (if any).

Right, I don't think that should be hard, unless I'm missing anything.
We read that bit from CPUID and that's bit 47 of the physical address
right now.

Do you think we could reuse one of those _PAGE_BIT_SOFTW*?

Right, and then set the proper *hardware* bit everytime we set a
pteval_t.

> Because it's nasty to have these constants that _used_ to be
> constants, and still _look_ like constants, suddely do stupid memory
> reads from random kernel data.
> 
> So _this_ is the underflying problem:
> 
>   #define _PAGE_ENC  (_AT(pteval_t, sme_me_mask))
> 
> because that is simply not how the _PAGE_xyz macros should work!

Yeah, I still have a funny feeling when looking at that but modulo
better solutions... :-\

> So it should have been a fixed bit to begin with, and the dynamic part
> should have been elsewhere.

Right, Tom, whaddya think? Do you see any issues with doing a software,
"mirror" bit of sorts and then converting to the C-bit when needed?

> The whole EXPORT_SYMBOL() thing is just a symptom of that fundamental
> error. Modules - GPL or not - should _never_ have to know or care
> about this _PAGE_ENC bit madness, simply because it shouldn't have
> been there.

Right, so every user of the PAGE_* macros needs to set the C-bit when
SME is enabled and everytime it creates a PTE so that the memory
controller knows how to do the access. I certainly like your idea but
we'd have to audit all the places where we need to convert to the C-bit
from the software encryption bit and how ugly that would get.

Btw, this is the other reason why the _PAGE_ENC bit is in the PAGE_*
macros: for full encryption, everything that deals with PTEs needs to
set the C-bit.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
--