Earlier quoted context omitted.
I am used to ‘bit rot’ refer to code becoming obsolete due to lack of maintenance. Can’t we use another term for actual hardware errors?
I’ve always understood “bit rot” meaning data getting silently corrupted on o storage device like a hard drive or SSD.
Single random bit flip causes error in certificate transparency log
61–70 of 258 posts
Re: Single random bit flip causes error in certificate transparency log
#62Earlier quoted context omitted.
Is this bit rot happening on a server w/ ECC RAM just curious?
It was a MacStadium ( https://www.macstadium.com ) build server, so most likely non-ECC.
Re: Single random bit flip causes error in certificate transparency log
#63Do nuclear missiles have this anywhere? bool launch = false; if(launch) ...
Generally critical systems can't be armed without physical interaction from humans. It's not just computer logic, but powering up the system that can do the launch. It does not matter what the logic does as long as ignition system is not powered up using physical switch.
Re: Single random bit flip causes error in certificate transparency log
#64Earlier quoted context omitted.
Yes. Via git diff --no-index and xxd.
I have no words. Stories like this trigger PTSD for me. I wasn't trying to be flip. That must have been a bitch to figure out.
As Arthur Conan Doyle put it: "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth." ¯\_(ツ)_/¯
Re: Single random bit flip causes error in certificate transparency log
#65Re: Single random bit flip causes error in certificate transparency log
#66Earlier quoted context omitted.
These things exist, using trade names like chipkill or lockstep memory. Though they don't need to sacrifice half of the memory chips to get good error recovery properties. Note that this is still not end-to-end protection of data integrity. Bit flips happen in networking, storage, buses between everything, caches, CPUs, etc. See eg [1] [1] https://arxiv.org/abs/2102.11245 Silent Data Corruptions at Scale (based on em…
According to the Intel developer's manual L1 has parity and all caches up from that have ECC. This would seem to imply that the ring / mesh also has at least parity (to retry on error). Parity instead of ECC on L1(D) makes sense since the L1(D) has to handle small writes well, while the other caches deal in lines.
Re: Single random bit flip causes error in certificate transparency log
#67Example: bitsquatting on domains [2].
[1]: https://arstechnica.com/gadgets/2021/01/linus-torvalds-blame...
[2]: https://nakedsecurity.sophos.com/2011/08/10/bh-2011-bit-squa...
Re: Single random bit flip causes error in certificate transparency log
#68Isn't ECC memory supposed to mitigate these kind of bit-flips, specifically it should correct all single bit flips? As this is a single bit-flip, why wasn't it corrected? Did ECC memory fail? Or was this bit-flip induced in the CPU pipeline, registers, or cache? Do we need "RAID for ECC memory", where we halve user-accessible RAM and store each memory segment twice and check for parity?
These are all very fair statements but there’s no guarantee that ECC memory was even used. Computers typically fail open when ECC is potentially present but not available. People also cite early stage google and intentionally do not buy ECC components, running more consumer hardware for production workloads. Even if google later recanted that theology.
Re: Single random bit flip causes error in certificate transparency log
#69Re: Single random bit flip causes error in certificate transparency log
#70Do nuclear missiles have this anywhere? bool launch = false; if(launch) ...