Date: Sun, 25 Jun 2017 18:22:04 -0700 From: Pete Wright <pete@nomadlogic.org> To: freebsd-current@freebsd.org Subject: Re: Skylake/Kabylake Intel Bug? Message-ID: <06aeb24f-c725-52c8-5746-fca40c588a20@nomadlogic.org> In-Reply-To: <595030E7.1030400@Wilcox-Tech.com> References: <a5e8f4c4-9cbb-d229-12a7-ce9c21bfe832@nomadlogic.org> <595030E7.1030400@Wilcox-Tech.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 >> >> https://lists.debian.org/debian-devel/2017/06/msg00308.html >> >> 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 >> context? >> >> Cheers, >> >> -pete >> > The linked OCaml issue goes quite in-depth with the mechanisms behind > this bug and the risks behind not patching the microcode: > > https://caml.inria.fr/mantis/view.php?id=7452 > > > 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, > --arw 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. -p -- Pete Wright pete@nomadlogic.org @nomadlogicLA
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?06aeb24f-c725-52c8-5746-fca40c588a20>