On 04.01.2018 22:07, Michael Butler wrote:
>
> 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
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
wrote:
> On 01/04/18 14:59, Klaus P. Ohrhallinger wrote:
>> On 04.01.2018 19:5
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 SharedArrayBuffe
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/Eri
On 04.01.2018 19:23, Klaus P. Ohrhallinger wrote:
> All PoC code I have seen today relies on those instructions.
> Is there any other way to measure the memory/cache access times ?
It is possible to emulate a high resolution counter with a thread that
continuously increments a variable [1]. This i
Hello,
I disabled the ldtsc and ldtscp instructions for usermode on one of my
production servers:
% ./spectre
Reading 40 bytes:
Bus error (core dumped)
All PoC code I have seen today relies on those instructions.
Is there any other way to measure the memory/cache access times ?
On 10.4-RELEASE
