4 ms·

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

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.

mark-r 6y ago
That's the principle behind Gray Code counting: https://en.wikipedia.org/wiki/Gray_code https://en.wikipedia.org/wiki/Gray_code
- Dylan16807 6y ago
  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.
knorker 6y ago
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)
- MaxBarraclough 6y ago
  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.
  - knorker 6y ago
    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.