Libsecded

I'm not sure how useful this is, because memory interacts with pretty much everything.

I mean, great: you've validated that the important financial data you were going to write to the DB is correct. But you didn't validate that the OS itself is in full working order. A bit goes out of place, the kernel writes something weird to disk, filesystem becomes corrupted and things explode in a dramatic fashion.

That's exactly why I try to get ECC everywhere these days. I had an old box serving firewall duty until one day it died because it got bumped, a memory module got loose somehow and the resulting disk corruption rendered it unbootable. Applications verifying that their data is correct wouldn't have changed anything.

Would you have a reference about ECC in LPDDR5, or Apple specific LPDDR5 features, protecting from internal errors? The sources I found said it only has link error correction, eg https://www.synopsys.com/designware-ip/technical-bulletin/ke...

Which kinds of ECC are mandatory and which kinds of ECC are optional can be found only in the JEDEC standards, which are expensive.

On the Synopsys site, both at the link provided by you and in other pages, for DDR5 is mentioned only on-die ECC, which protects only against bit flips during storage, while for LPDDR5 is mentioned only link ECC, which protects only against electrical noise on the PCB traces between the LPDDR5 soldered chips and the CPU soldered chip.

It is likely that on-die ECC is considered more important for DDR5, because the computers that use DDR5 modules are expected to have a larger amount of installed memory, which multiplies the frequency of bit errors during storage, while link ECC is considered more important for LPDDR5, because here the data transfer speed is higher, which multiplies the bit errors due to electrical noise on the PCB link.

On-die ECC can be implemented even if the memory controller of the CPU is not aware of it. Each memory manufacturer may choose to implement on-die ECC, or not, depending on the results of their in-house reliability tests for the storage of the bits in their DRAM chips. The memory manufacturers have no need to mention whether they use internally some form of ECC, because that is transparent for the users of the memories.

Link ECC must be supported by the memory controller and included in the standardized memory interface, so I assume that this is restricted to LPDDR5 memories.

Thanks for the link.

What if instead of passing tokens, checksums were passed and the function checked that its code matched the checksum. This would give some protection against both corruption of the code and instruction pointer errors.

Another element from the article was having copies of the function and comparing the return values, but I suspect this breaks down when the function deals with external state. Possibly it could be done by intercepting the state-related calls and making them atomic/combining them. I feel like there's something here reminding me of STM [0].

I suspect it will always be a better investment of time and result in scalable and simpler applications to go for the hardware required to get a full ECC-covered execution architecture.

[0] https://www.infoq.com/news/2010/05/STM-Dropped/