On Fri, Apr 05, 2019 at 09:24:50AM -0600, Andy Lutomirski wrote: > > > > On Apr 5, 2019, at 8:44 AM, Dave Hansen <dave.han...@intel.com> wrote: > > > > On 4/5/19 12:17 AM, Thomas Gleixner wrote: > >>> process. Is that an acceptable trade-off? > >> You are not seriously asking whether creating a user controllable ret2dir > >> attack window is a acceptable trade-off? April 1st was a few days ago. > > > > Well, let's not forget that this set at least takes us from "always > > vulnerable to ret2dir" to a choice between: > > > > 1. fast-ish and "vulnerable to ret2dir for a user-controllable window" > > 2. slow and "mitigated against ret2dir" > > > > Sounds like we need a mechanism that will do the deferred XPFO TLB > > flushes whenever the kernel is entered, and not _just_ at context switch > > time. This permits an app to run in userspace with stale kernel TLB > > entries as long as it wants... that's harmless. > > I don’t think this is good enough. The bad guys can enter the kernel and > arrange for the kernel to wait, *in kernel*, for long enough to set up the > attack. userfaultfd is the most obvious way, but there are plenty. I suppose > we could do the flush at context switch *and* entry. I bet that performance > still utterly sucks, though — on many workloads, this turns every entry into > a full flush, and we already know exactly how much that sucks — it’s > identical to KPTI without PCID. (And yes, if we go this route, we need to > merge this logic together — we shouldn’t write CR3 twice on entry). > > I feel like this whole approach is misguided. ret2dir is not such a game > changer that fixing it is worth huge slowdowns. I think all this effort > should be spent on some kind of sensible CFI. For example, we should be able > to mostly squash ret2anything by inserting a check that the high bits of RSP > match the value on the top of the stack before any code that pops RSP. On an > FPO build, there aren’t all that many hot POP RSP instructions, I think. > > (Actually, checking the bits is suboptimal. Do: > > unsigned long offset = *rsp - rsp; > offset >>= THREAD_SHIFT; > if (unlikely(offset)) > BUG(); > POP RSP;
This is a neat trick, and definitely prevents going random places in the heap. But, > This means that it’s also impossible to trick a function to return into a > buffer that is on that function’s stack.) Why is this true? All you're checking is that you can't shift the "location" of the stack. If you can inject stuff into a stack buffer, can't you just inject the right frame to return to your code as well, so you don't have to shift locations? Thanks! Tycho _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
