ExtremeTech: CPU Manufacturers Are Pushing the Boundaries of CMOS and Starting to Pay For It
ExtremeTech: CPU Manufacturers Are Pushing the Boundaries of CMOS and Starting to Pay For It. https://www.extremetech.com/computing/323476-cpu-manufacturers-are-pushing-t...
Summary: Google is collecting evidence indicating that at least around 3% of modern cups are silently corrupting data in ways that users don't notice.
A pathological cpu core is described that performs AES in some way such that it can reliably decrypt its own encrypted documents, but no other discovered cores can do so. The failures are called "corrupt execution errors" and the invisibly failing cores "mercurial" . Blamed on problems of miniaturization. Chip manufacturers have not spoken yet. Google is finding more problems as they improve their software for detecting them. Google's paper linked from the article appears to be https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s01-hochschild.pd... . I have not visited the link myself.
When I worked for Intel in 1980, they were working on a CPU called the IAPX 432, which as I recall had the intended feature that they were installed in pairs, one called a "generator" and the other called a "checker". https://en.wikipedia.org/wiki/Intel_iAPX_432?wprov=sfla1 The latter verified that the "generator" had done its job correctly. On Mon, Jun 7, 2021 at 6:01 PM, Karl<gmkarl@gmail.com> wrote: Summary: Google is collecting evidence indicating that at least around 3% of modern cups are silently corrupting data in ways that users don't notice. A pathological cpu core is described that performs AES in some way such that it can reliably decrypt its own encrypted documents, but no other discovered cores can do so. The failures are called "corrupt execution errors" and the invisibly failing cores "mercurial" . Blamed on problems of miniaturization. Chip manufacturers have not spoken yet. Google is finding more problems as they improve their software for detecting them. Google's paper linked from the article appears to be https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s01-hochschild.pd... . I have not visited the link myself.
I skimmed through some parts of the paper. The rate is more like 0.1% than 3% and facebook has published a paper on it too. Google references a few techniques for working around the issue, and has made libraries for reliable cryptography, but does not link to them. On Linux thread affinity can be set to select cpu cores: https://man7.org/linux/man-pages/man3/pthread_setaffinity_np.3.html Google recommends triplicating on different cores crucial tasks. I suppose you would want to triplicate also the tallying of the results and the verification of being on separate cores. They link to well-studied techniques in the paper. The problem is supposed to only affect you if you run a datacenter with thousands of machines, so stop spilling coffee on your mobile phone while running it during an x-ray. (I recently replaced my copy of raspbian's latest openssl .deb with a handbuilt library because it kept giving me occasional valgrind failures and incorrect digests.) Obviously this is not a problem that ethereum would ever have.
https://sigops.org/s/conferences/hotos/2021/papers/hotos21-s01-hochschild.pd...
It only takes one lucky bug, or one intentionally inserted backdoor, a program hidden waiting among tens of billions of closed TOP SECRET HW gates that you have absolutely zero reason to trust, to flip your crypto from strong to weak. The deeper wider and longer that public cryptanalysis of whichever open crypto algos stand, the more you must then invest in destroying the remaining private facades in order to achieve bit-equivalent strengths across all elements touching your work... #OpenFabs , #OpenHW , #OpenAudit You have $2T in crypto cap, but still did not spend even under 0.5% of it on creating any seed investment in open design, production, etc capabilities to displace these legacy private generators and their exploit pox upon you. Shame.
participants (3)
-
grarpamp -
jim bell -
Karl