On 16/05/2019 12:48, wencongyang (A) wrote: > > On 2019/5/16 15:58, Andrew Cooper wrote: >> On 16/05/2019 08:56, wencongyang (A) wrote: >>> On 2019/5/16 15:38, Andrew Cooper wrote: >>>> On 16/05/2019 03:46, wencongyang (A) wrote: >>>>> Hi all >>>>> >>>>> Fill buffers, load ports are shared between threads on the same physical >>>>> core. >>>>> We need to run more than one vm on the same physical core. >>>>> Is there any complete mitigation for environments utilizing SMT? >>>> No - not really. >>>> >>>> An approach which was worked on was that of synchronised scheduling, >>>> whereby privilege transitions are syncrhonised to ensure that we're >>>> never running code from different privilege levels concurrently on >>>> adjacent threads. (This is the mitigation described as Group Scheduling >>>> in >>>> https://software.intel.com/security-software-guidance/insights/deep-dive-intel-analysis-microarchitectural-data-sampling >>>> ) >>> synchronised scheduling is not a complete mitigation. Guest A and Guest B >>> run on the same physical core, and the privilege level is the same. So >>> Guest A can infer data from Guest B. Guest A cannot infer data from >>> hypervisor >>> because they are in different privilege levels. >> This is (one of the reasons) why core scheduling is a prerequisite to >> synchronised scheduling. >> >> With core scheduling active, you will never have guest A and B >> concurrently running on adjacent threads of the same core. > Another question: > There are a CPUID bit(TSX_FORCE_ABORT) and MSR(MSR_TSX_FORCE_ABORT) in > xsa297/xsa297-4.7-1.patch. > But we do not find them in the patchs of kvm. > > IIUC, this MSR is not for MDS mitigation. Is this right?
Oops - I intended to make this a bit more clear in the advisory. Correct - this isn't to do with MDS, but the behavioural change was in the same piece of microcode as the MDS fixes, which is why it was included. See https://xenbits.xen.org/docs/unstable/misc/xen-command-line.html#vpmu-x86 and rtm-abort=<bool> for the details. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
