Date: Thu, 4 Jan 2018 20:59:56 +0100 From: "Klaus P. Ohrhallinger" <k@7he.at> To: freebsd-current@freebsd.org, jan.kokemueller@gmail.com Subject: Re: Intel CPU design flaw - FreeBSD affected? // disabling LDTSC Message-ID: <da881926-9ef0-6c69-a9fb-a7594613946a@7he.at> In-Reply-To: <c675036c-f300-839a-930c-cbe1b4d1c580@gmail.com> References: <9dda0496-be16-35c6-6c45-63d03b218ccb@protected-networks.net> <18376c97-3c0d-49c8-9483-96b95a84f3f1@7he.at> <c675036c-f300-839a-930c-cbe1b4d1c580@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 @ 2.50GHz (2500.14-MHz K8-class CPU) FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 2 package(s) x 4 core(s)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?da881926-9ef0-6c69-a9fb-a7594613946a>