5 ms·

That's an interesting point. In an extreme case, an order or money transfer might be placed for an incorrect quantity, or to an incorrect recipient.

KingMachiavelli 6y ago
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.

KingMachiavelli 6y ago

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.