No matches found

[ltning]

I've ran your tool on three different Intel systems (10.4 and 11.1), and on neither have I been able to get the mdcheck tool to return anything but '2'. Running mdattack with no options returns no data on most runs on Intel machines, but seemingly random data on an agin AMD Opteron system we have.

I can provide unprivileged accounts on several of these systems, if you wish.

[jdwx]

The same seems true in our environment. We tested on several systems including a Xeon E5530 running unpatched FreeBSD 11.1 with no mitigation steps taken, and we consistently get 2 from mdcheck.

The same result, FWIW, is obtained from a virtual machine running Ed Maste's 11.1 candidate patch in a VM under a patched Linux/KVM host on a Xeon E5-2630 v3. (As well as several other systems, but those should represent the two vulnerability extremes.)

[dag-erling]

I'm sorry, I never received a notification from Github for this issue or for Kostik's pull request, so I didn't see either until he contacted me out of band.

The issue is almost certainly the addq in spec_read(). It's a dummy instruction which is simply meant to delay the ALU so the speculative prefetcher has time to run. On some machines, just one is enough, but on others you need a longer delay, which is most easily achieved using the .rept assembler macro:

.rept 100
        addq            $0x5754, %rdx
.endr

The delay required for the attack to work may vary from one CPU to another. I can't remember off the top of my head if it needs to be just right or if it just needs to be long enough. I would suggest starting with 100 and then doubling until it works or you give up.