> On Apr 5, 2019, at 9:56 AM, Tycho Andersen <ty...@tycho.ws> wrote: > >> 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? > >
But the injected ROP payload will be *below* RSP, so you’ll need a gadget that can decrement RSP. This makes the attack a good deal harder. Something like RAP on top, or CET, will make this even harder. > > Tycho _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu
