On 9/10/19 7:27 AM, Julien Desfossez wrote: > On 29-Aug-2019 04:38:21 PM, Peter Zijlstra wrote: >> On Thu, Aug 29, 2019 at 10:30:51AM -0400, Phil Auld wrote: >>> I think, though, that you were basically agreeing with me that the current >>> core scheduler does not close the holes, or am I reading that wrong. >> >> Agreed; the missing bits for L1TF are ugly but doable (I've actually >> done them before, Tim has that _somewhere_), but I've not seen a >> 'workable' solution for MDS yet. >
The L1TF problem is a much bigger one for HT than MDS. It is relatively easy for a Rogue VM to sniff L1 cached memory locations. While for MDS, it is quite difficult for the attacker to associate data in the cpu buffers with specific memory to make the sniffed data useful. Even if we don't have a complete solution yet for MDS HT vulnerability, it is worthwhile to plug the L1TF hole for HT first with core scheduler, as L1TF is much more exploitable. Tim > Following the discussion we had yesterday at LPC, after we have agreed > on a solution for fixing the current fairness issue, we will post the > v4. We will then work on prototyping the other synchronisation points > (syscalls, interrupts and VMEXIT) to evaluate the overhead in various > use-cases. > > Depending on the use-case, we know the performance overhead maybe > heavier than just disabling SMT, but the benchmarks we have seen so far > indicate that there are valid cases for core scheduling. Core scheduling > will continue to be unused by default, but with it, we will have the > option to tune the system to be both secure and faster than disabling > SMT for those cases. > > Thanks, > > Julien > > P.S: I think the branch that contains the VMEXIT handling is here > https://github.com/pdxChen/gang/commits/sched_1.23-base >
