You can also "fix" it by ignoring that memory area by adjusting kernel parameters. That's how I do it on one of my old laptops. I wonder if the kernel couldn't

You can also "fix" it by ignoring that memory area by adjusting kernel parameters. That's how I do it on one of my old laptops. I wonder if the kernel couldn't perform ECC itself at a small performance cost by storing CRC bits in padding bits (that would require cooperation from the compiler), or other memory areas, checking them on load, and recomputing them before store operations. It may be easier to achieve on RISC architectures where load and stores are explicit. I read a paper that seemed related to that some time ago, probably on an embedded microcontroller; the performance penalty was about 20% (you just need a few extra memory operations, performing ECC computation is pretty cheap, and is done 100% within the cache). Alternatively, the kernel could checksum memory areas, and warn/panic if they change without having written to them. As a bonus, it could help protect against rowhammer attacks. Performance cost might be less. Of course, ideally, ECC should be a standard feature, as it is on FLASH devices... CPUs should also support it even without explicit support from DRAM... Implementing the mechanisms I described above in hardware should be relatively easy.