LLVM folks: so given this https://www.tomshardware.com/software/mozilla-firefox/after-a-year-firefox-finally-stops-crashing-on-intels-raptor-lake-cpus-mozilla-releases-new-version-patch-critical-flaw-on-intel-13th-gen-and-14th-gen-cpus and the patch https://phabricator.services.mozilla.com/D301917, how we feeling about maybe adding a codegen option for Raptor Lake mitigation that is just "don't emit mov \[...,\], [abcd]h"
Replies:
7
Boosts:
1
it's amazing that Intel is still selling these when we now have multiple projects independently working around certain byte stores in the 80386-era integer instruction subset failing, but here we are, I guess
@rygorous Wasn't the root cause too much voltage that degraded the CPU faster than expected or something like that?
Maybe with that fixed in firmware new/not previously used CPUs don't have the problem anymore
(still wouldn't buy one)
@Doomed_Daniel yes, but these are still (apparently) the first thing to fail (my guess being that this is probably one of the paths with the least timing slack at high clocks)
@rygorous @Doomed_Daniel oh wow that's crazy, just reading about this whole story now. could this be fixed, even for already-affected CPUs, with a microcode update?
@floe @Doomed_Daniel Not really how microcode works.
They've issued like 5 microcode fixes to try and make their voltage/frequency scaling logic less aggressive but apparently in newer uCode revisions this got worse again. (see comment 20 in https://bugzilla.mozilla.org/show_bug.cgi?id=1950764)
@floe @Doomed_Daniel Microcode is not "the CPU is actually running a SW interpreter of x86 code under the hood" or anything like that.
The vast majority of x86 instructions (basically anything that's actually used frequently) is completely hardwired, the things that are microcoded are things that are one or more of:
- very complex flows (e.g. things like protected mode FAR calls, the context switches for interrupts/exceptions, etc.)
- ~never used & not worth hard-wiring (e.g. some BCD stuff)
@floe @Doomed_Daniel
- already very slow (e.g. 128:64 int divides used to be microcoded for a long time, although these days they often aren't)
- good to be able to patch after the fact (e.g. CPUID, or supervisor-level insns where subtle bugs might be security issues)
but when there's an issue with the actual implementation of a hard-wired feature (which this is), there's simply no way for microcode to work around that directly.
