Possibly because Xeon 5400 dates to 2007 — it may have less advanced speculative / out-of-order execution and may not have the same branch prediction algorithm as Haswell. On Thu, Jan 4, 2018 at 1:07 PM, Michael Butler <imb_at_protected-networks.net> wrote: > On 01/04/18 14:59, Klaus P. Ohrhallinger wrote: >> On 04.01.2018 19:51, Jan Kokemüller wrote: >> >>> It is possible to emulate a high resolution counter with a thread that >>> continuously increments a variable [1]. This is the reason why browser >>> vendors are currently disabling the SharedArrayBuffer feature [2]. >>> >>> [1]: https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6#gistcomment-2311156 >>> [2]: https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/ >> >> I tried the phtread example from [1] but even with some tweaking is does >> not work at all. >> >> This is a multiprocessor system, with moderate load. >> >> As far as I understand the matter, it can only work if both threads >> share the same cpu cache, otherwise the counter variable is either never >> up-to-date, or has to be fetched and stored from/to memory, which is way >> too slow for this purpose. >> >> Any suggestions ? >> >> --- >> >> CPU: Intel(R) Xeon(R) CPU E5420 _at_ 2.50GHz (2500.14-MHz >> K8-class CPU) >> FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs >> FreeBSD/SMP: 2 package(s) x 4 core(s) > > Interestingly, the Xeon 5400 series is not listed as vulnerable in the > Intel documentation where the 5500 and 5600s are; I checked as I have a > bunch of E5440s in service. > > https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00088&languageid=en-fr > > imb > > _______________________________________________ > freebsd-current_at_freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"Received on Thu Jan 04 2018 - 20:43:43 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:14 UTC