Reminds me of [Cores that don't count]https://research.google/pubs/pub50337/ https://research.google/pubs/pub50337/ >We are accustomed to thinking of computer

Reminds me of [Cores that don't count]https://research.google/pubs/pub50337/ https://research.google/pubs/pub50337/ >We are accustomed to thinking of computers as fail-stop, especially the cores that execute instructions, and most system software implicitly relies on that assumption. During most of the VLSI era, processors that passed manufacturing tests and were operated within specifications have insulated us from this fiction. As fabrication pushes towards smaller feature sizes and more elaborate computational structures, and as increasingly specialized instruction-silicon pairings are introduced to improve performance, we have observed ephemeral computational errors that were not detected during manufacturing tests. These defects cannot always be mitigated by techniques such as microcode updates, and may be correlated to specific components within the processor, allowing small code changes to effect large shifts in reliability. Worse, these failures are often "silent'': the only symptom is an erroneous computation. >We refer to a core that develops such behavior as "mercurial.'' Mercurial cores are extremely rare, but in a large fleet of servers we can observe the correlated disruption they cause, often enough to see them as a distinct problem -- one that will require collaboration between hardware designers, processor vendors, and systems software architects. >We have observed various kinds of symptoms caused by mercurial cores. > Violations of lock semantics leading to application data corruption and crashes. > Data corruptions exhibited by various load, store, vector, > and coherence operations. > A deterministic AES mis-computation, which was “self inverting”: encrypting and decrypting on the same core yielded the identity function, but decryption elsewhere yielded gibberish. > Corruption affecting garbage collection, in a storage system, causing live data to be lost. > Database index corruption leading to some queries, depending on which replica (core) serves them, being non deterministically corrupted. > Repeated bit-flips in strings, at a particular bit position (which stuck out as unlikely to be coding bugs). > Corruption of kernel state resulting in process and kernel crashes and application malfunctions ___________ >Not all mercurial-core screening can be done before CPUs are put into service – first, because some cores only become defective after considerable time has passed,