On 25/10/2019 13:09, Jan Beulich wrote: > On 23.10.2019 15:58, Andrew Cooper wrote: >> l1tf-barrier is an inappropriate name, and came about because of restrictions >> on could be discussed publicly when the patches were proposed. >> >> In practice, it is for general Spectre v1 mitigations, and is necessary in >> all >> cases. An adversary which can control speculation in Xen can leak data in >> cross-core (BCBS, etc) or remote (NetSpectre) scenarios - the problem is not >> limited to just L1TF with HT active. >> >> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com> > Reviewed-by: Jan Beulich <jbeul...@suse.com> > >> In principle it should be tristate and being disabled by default on parts >> which don't speculate, but it is too late in 4.13 to organise this. > And the fundamental issue is correctly compiling the conditions under which > to default to true and false respectively?
Yes. > I ask because if it was not this > then I wouldn't see what hindering factor there is to make this tristate > right away. Linux's NO_SPECULATION list is a start (if there is actually an intersection with 64bit capable CPUs), but there are mitigating factors on some later CPUs as well. ~Andrew _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
