linux-kernel - Re: Yet another KPTI regression with 4.14.x series in a VM

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: <20180113120847.GI3397@worktop>
Date:   Sat, 13 Jan 2018 13:08:47 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Borislav Petkov <bp@...en8.de>,
        Laura Abbott <labbott@...hat.com>, X86 ML <x86@...nel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        stable <stable@...r.kernel.org>
Subject: Re: Yet another KPTI regression with 4.14.x series in a VM

On Fri, Jan 12, 2018 at 10:08:20PM -0800, Andy Lutomirski wrote:
> Now this is quite a strange value to write to CR3.  The 0x800 part
> means that we're using the "user" variant of the address space that
> would have ASID=0 and the 0x1000 bit being set corresponds to the user
> pgdir, but this is nonsense, since the kernel never uses PCID 0 for
> user mode.  We always start at 1.  The only exception is if
> X86_FEATURE_PCID is off.  But, if X86_FEATURE_PCID is off, then we
> shouldn't be setting any PCID bits.

My bad, I was under the impression the lower 12 bits would be ignored
without PCID :/

> .Lwrcr3_\@:
>         /* Flip the PGD and ASID to the user version */
>         orq     $(PTI_SWITCH_MASK), \scratch_reg
>         mov     \scratch_reg, %cr3
> .Lend_\@:
> 
> That's bogus.  PTI_SWITCH_MASK is 0x1800, which has PCID = 0x800.

> This should probably use an alternative to select between 0x1000 and
> 0x800 depending on X86_FEATURE_PCID or just use an entirely different
> label for the !PCID case.

	ALTERNATIVE "orq $(PTI_SWITCH_PGTABLE_MASK), \scratch_reg",
	            "orq $(PTI_SWITCH_MASK), \scratch_reg", X86_FEATURE_PCID

Is not wanting to compile though; probably that whole alternative vs
macro thing again :/