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.
firstname.lastname@example.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"