On 06/25/2017 14:53, A. Wilcox wrote:
On 25/06/17 12:56, Pete Wright wrote:
Came across this post today via HN regarding a issue with Hyperthreading
causing unpredictable behavior on these CPU's


I really wish there was more info on this in the email, for example
examples of programs being effected by this bug.  Anywho - was wondering
if any devs here had more info on this issue and could provide better



The linked OCaml issue goes quite in-depth with the mechanisms behind
this bug and the risks behind not patching the microcode:


Basically, if a HyperThreaded core is running a tight loop accessing
%rax and %ah (or %rbx and %bh, etc) in quick succession, on both threads
of the same physical core, it can corrupt/poison L1d cache.

AIUI, OCaml manages to generate this code by manipulating tagged memory
addresses and the corresponding tag (the address is in %rax, and the tag
is at %ah).

I'd really love to see if this affects write-through-no-allocate cache
or only write-behind, but I haven't seen any program besides OCaml
actually manage to get GCC to generate the insn pattern that is needed,
and I don't have a Skylake or Kaby Lake CPU to test with anyway.

Fun little hardware bug.

Hope this helps you,

Thanks this is really helpful! From the dire warning of the debian thread I was worried this was a very easy to run into runtime issue. Certainly sounds pretty darn serious, but having context at least gives me something to keep any eye out for as a syadmin - this def seems like a potentially interesting attack surface (as most CPU bugs tend to be) :)

i've got a couple effected CPUs that i use for dev purposes - might see if i can reproduce on my end just for shits and giggles.


Pete Wright

freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to