[jameshilliard]

Compare the RAM capacity in the running board revision with the factory revision in OTP row 32. Report possible RAM tampering or replacement and advise contacting the seller to arrange a return.

Install the standalone checker through CMake and document its usage, exit statuses, and limitations. Matching capacity cannot establish that the RAM is original.

Include the check in raspinfo on BCM2712 devices when the tool is installed. Capture warnings in the saved report and continue collecting diagnostics when RAM differs or the check is unavailable.

In a previous review I was told that this was out of scope for the rpi-eeprom repo, I figured it seems that this would potentially make sense to include in the utils repo here since that's where some similar diagnostic/debugging utils are located.

I would note that using an official Raspberry Pi reseller as suggested here is likely insufficient in practice to ensure that tampered hardware does not end up in a product, unless such an official reseller were to prohibit the resale of returned products entirely. From my understanding even official Raspberry Pi resellers(i.e. retailers like microcenter) are not prohibited from reselling a returned raspberry pi.

Supply chain tampering issues like this are tricky for companies to handle properly, often the best approach to combating it is simply to maximize visibility of the issue by providing users with tools for easily and reliably identifying tampering where possibility.

Some of the reviews I've seen to my rpi-eeprom submissions are extremely confusing to me as they seem to imply that raspberry pi isn't interested in providing users with good visibility into whether or not their ram is authentic or not. Is there some underlying issue I'm missing here? I would think most companies would want to give their customers ways of determining if their product has been tampered with by a 3rd party.

One of the big issues with having the ram tampering checks only in the eeprom binary itself is that any failure from an eeprom update presents an unusually confusing failure pattern to the user. In most reported cases of ram tampering related raspberry pi boot failures users typically report it takes them many hours to root cause that ram tampering was what triggered such a failure, and these reports are likely highly biased towards the more technically capable users already, less technical users are more likely to assume it's a pure hardware failure and not deliberate tampering by a 3rd party.

Having a way for users/customers to be informed of such an issue as early as possible in a clear way therefore should significantly reduce the amount of end user time wasted diagnosing/debugging ram tampering related raspberry pi update failures and also make it easier to eliminate such devices from supply chains overall.