Re:ECC matters
by KingMachiavelli on Sunday January 03, 2021 @12:39PM
(#25623307)
Well maybe. Rather than having to trust memory completely, it would just be better to use a binary format where each bit is verifiable so then at least a single bit flip would be immediately obvious. For example, a bit flip in a TLS session causes the whole session to fail rather than a random page element to change.
[ Parent
| on HN ]
That doesn't help if the memory is corrupted before the verification code is applied. (the code will simply put a signature on incorrect data)
Or after it's been checked. (time-of-check vs time-of-use)
Re:ECC matters
by MaxBarraclough on Sunday January 03, 2021 @01:47PM
(#25623960)
Right, exactly. TCP protects us from data-corruption in network streams, and ECC protects us from data-corruption in RAM. I doubt any sort of software solution could practically compete against hardware ECC, even if it could be done it would presumably be disastrous for performance.
The best integrity checking is "end to end". The problem with non-ECC is that there are no "ends" that are trustworthy.
I guess in theory some software could produce signed data in CPU cache, and "commit" it to RAM as a verified block.
But the overhead would be enormous. Would you slow down your CPU by half in order to not pay 12.5% more for RAM?
Hmm, I wonder what SGX and similar do about this.
That's the principle behind Gray Code counting: https://en.wikipedia.org/wiki/Gray_code
Re:ECC matters
by Dylan16807 on Monday January 04, 2021 @11:09PM
(#25641984)
Not really. Gray codes are designed so that if you're counting correctly, only one bit flips at a time. But if you flip the wrong bit by accident, you'll end up with a completely different number, no way to tell a problem happened.
If you want to detect a bit flip, use parity.