[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.20.1801131342380.2371@nanos>
Date: Sat, 13 Jan 2018 13:50:55 +0100 (CET)
From: Thomas Gleixner <tglx@...utronix.de>
To: Peter Zijlstra <peterz@...radead.org>
cc: Andy Lutomirski <luto@...nel.org>, 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 Sat, 13 Jan 2018, Peter Zijlstra wrote:
> 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 :/
2:0 Ignored
3 PWT
4 PCD
11:5 Ignored
So yes, it's mostly ignored at least in theory... I'm sure I stared at that
code and the SDM more than once and convinced myself that it's not an issue
to set bit 11 unconditionally.
But I should have stared at the AMD manual which says:
Reserved Bits. Reserved fields should be cleared to 0 by software when writing CR3.
Thanks,
tglx
Powered by blists - more mailing lists