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 > > <torva...@linux-foundation.org> wrote: > > > > > > On Wed, Jan 10, 2018 at 11:28 AM, Willy Tarreau <w...@1wt.eu> 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?