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. But, if it enters the kernel, we could process the deferred flush there. The concern would be catching all the kernel entry paths (PTI does this today obviously, but I don't think we want to muck with the PTI code for this). The other concern would be that the code between kernel entry and the flush would be vulnerable. But, that seems like a reasonable trade-off to me.
