Messages in this thread | | | Subject | Re: [RFC PATCH] arch/x86: Optionally flush L1D on context switch | From | "Herrenschmidt, Benjamin" <> | Date | Sun, 22 Mar 2020 05:10:43 +0000 |
| |
On Sat, 2020-03-21 at 11:05 +0100, Thomas Gleixner wrote: > victim1 > store secrit > victim2 > attacker read secrit > > Now if L1D is flushed on CPU0 before attacker reaches user space, > i.e. reaches the attack code, then there is nothing to see. From the > link: > > Similar to the L1TF VMM mitigations, snoop-assisted L1D sampling can be > mitigated by flushing the L1D cache between when secrets are accessed > and when possibly malicious software runs on the same core. > > So the important point is to flush _before_ the attack code runs which > involves going back to user space or guest mode.
So you mean switching from victim to attacker in the kernel, and going back to victim before the attacker has a chance to actually execute any userspace code ?
I can see why this doesn't require a flush, but is it a case worth optimizing for either ?
IE. The flush in switch_mm is rather trivial, is lower overhead than adding code to the userspace return code, and avoids kernel threads likely, I prefer it for its simplicity TBH...
Cheers, Ben.
| |