Re: [RFC PATCH v3 6/8] x86/pti: don't mark the user PGD with _PAGE_NX.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, 2018-01-10 at 11:59 -0800, Andy Lutomirski wrote:
> On Wed, Jan 10, 2018 at 11:54 AM, Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> > 
> > On Wed, Jan 10, 2018 at 11:28 AM, Willy Tarreau <w@xxxxxx> wrote:
> > > 
> > > Since we're going to keep running on the same PGD when returning to
> > > userspace for certain performance-critical tasks, we'll need the user
> > > pages to be executable. So this code disables the extra protection
> > > that was added consisting in marking user pages _PAGE_NX so that this
> > > pgd remains usable for userspace.
> > Yeah, no. This is wrong.
> > 
> > Sure, SMEP gives the same thing in most cases, but not for older CPU's.
> > 
> > So NX is a really nice way to make sure that PTI really does protect
> > against user-space gadgets.
> > 
> > We don't break that, and we definitely don't break that just because
> > of some broken notion of "let's make page table isolation per-thread".
> > 
> If we're going to have a thread without PTI off, that thread needs to
> run with the same page tables for kernel and user, so it needs NX off
> on the user part.  I don't see any way around it.
> 
> We could nix the entire concept of fine-grained PTI control, or we
> could make it require SMEP, I suppose.

We've been bashing out the precise requirements for RSB clearing (for
pre-SKL to avoid bogus entries) or stuffing (for SKL+ to avoid
underflow causing the BTB to be used).

It looks like we can avoid the RSB clearing on kernel entry if we have
SMEP. And PTI setting NX on userspace pages is equivalent to SMEP for
this purpose — so the RSB clearing basically ended up being AMD-only
(!SMEP && !PTI).

We also need to clear the RSB on vmexit, as documented. And if we
really want 100% support for retpoline on SKL+ instead of saying "use
IBRS if you're paranoid", then there are a few more cases where we need
to stuff it to avoid underflow (which is the same operation, but Arjan
insists we should differentiate the two, which is reasonable enough).

So... we'd really like to *not* lose the property that KPTI implies
SMEP-like NX of user space for the kernel.

Attachment: smime.p7s
Description: S/MIME cryptographic signature


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux