Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 4 Jan 2018 13:43:35 -0800
From:      Conrad Meyer <cem@freebsd.org>
To:        Michael Butler <imb@protected-networks.net>
Cc:        "Klaus P. Ohrhallinger" <k@7he.at>, freebsd-current <freebsd-current@freebsd.org>, jan.kokemueller@gmail.com
Subject:   Re: Intel CPU design flaw - FreeBSD affected? // disabling LDTSC
Message-ID:  <CAG6CVpVN_wV42R6oswn8rCAMsdruqPrhZarxBcUSXDQyXXKNfQ@mail.gmail.com>
In-Reply-To: <02f1caac-b20d-d9bb-ceeb-fd1a2639e6f7@protected-networks.net>
References:  <9dda0496-be16-35c6-6c45-63d03b218ccb@protected-networks.net> <18376c97-3c0d-49c8-9483-96b95a84f3f1@7he.at> <c675036c-f300-839a-930c-cbe1b4d1c580@gmail.com> <da881926-9ef0-6c69-a9fb-a7594613946a@7he.at> <02f1caac-b20d-d9bb-ceeb-fd1a2639e6f7@protected-networks.net>

next in thread | previous in thread | raw e-mail | index | archive | help
Possibly because Xeon 5400 dates to 2007 =E2=80=94 it may have less advance=
d
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@protected-networks.net> wrote:
> On 01/04/18 14:59, Klaus P. Ohrhallinger wrote:
>> On 04.01.2018 19:51, Jan Kokem=C3=BCller 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/724d4a969fb2c6ae1bbd7b2a9e3d4bb=
6#gistcomment-2311156
>>> [2]: https://blog.mozilla.org/security/2018/01/03/mitigations-landing-n=
ew-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)
>
> 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=3DINTEL-SA-00088&=
languageid=3Den-fr
>
>         imb
>
> _______________________________________________
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org=
"



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAG6CVpVN_wV42R6oswn8rCAMsdruqPrhZarxBcUSXDQyXXKNfQ>