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

[Konrad Rzeszutek Wilk]

On Wed, Jan 10, 2018 at 08:28:26PM +0000, Woodhouse, David wrote:
> 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).

Are these cases documented somewhere along with what approaches are taken?

I do remember Thomas's email from Feb 4th titled:
Re: [RFC 09/10] x86/enter: Create macros to restrict/unrestrict Indirect Branch Speculation                                                          

which outlined a pretty nifty idea on this, but not sure where that has gone?