Re: Intel CPU design flaw - FreeBSD affected? // disabling LDTSC

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