On 4/5/19 8:44 AM, Dave Hansen 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. That sounds like a good idea. This TLB flush only needs to be done at kernel entry when there is a pending flush posted for that cpu. What this does is move the cost of TLB flush from next context switch to kernel entry and does not add any more flushes than what we are doing with these xpfo patches. So the overall performance impact might not change much. It seems worth coding up. Thanks, Khalid
