Re: [Xen-devel] Question about MDS mitigation

["wencongyang (A)" <wencongyang2@xxxxxxxxxx>]

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.

Thansk
Wen Congyang

> 
> However...
> 
> First of all, it depends on core scheduling as a prerequisite, and as
> you can see, that is still a work-in-progress for Xen.  There are many
> other good reasons for doing core scheduling, so we will be continuing
> with that work.
> 
> For partners who already had core scheduling and experimented with
> synchronised scheduling, no-one found a way of making it function with
> less overhead than disabling hyperthreading in the first place.  This
> was was a native OS case - the virtualised case gets a compound
> performance hit because every time the guest kernel tries to
> synchronise, it forces Xen to synchronise, because there is no
> virtualisation of IPIs available in affected hardware.
> 
> 
> Overall, it looks like the one mitigation option which would allow
> hyperthreading to remain active had a larger performance penalty than
> disabling hyperthreading (on native, and remember that it is compounded
> when virtualised), and is a very invasive change to the entry/exit code.
> 
> Unless someone finds a really clever alternative plan, there doesn't
> appear to be a viable alternative to turning off hyperthreading when
> cross-thread leakage is a concern.
> 
> ~Andrew
> 
> 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel