On-die ECC means that the DRAM array in the chip stores ECC and the chip itself handles that transparently. The interface does not use ECC in this case. One of the reasons this is done is higher cell densities (just like in storage) and allowing longer refresh intervals (refreshing requires power regardless of usage).

The inclusion of TPM is definitely the most interesting aspect of this to me. I was initially turned off by the idea because I tend to associate them with nasty enterprise-y DRM types of stuff.

But I wonder why it's included here. Maybe for secure storage of private keys? I'm guessing that's the desired purpose for TPM in a server setting.

Obviously I'm not super familiar with TPM. I wonder if it can be used for things like better random number generation or hardware-accelerated hashing. I'm guessing if it supported hashing from userspace, the cryptocurrency crowd would have been all over it already.

> I wonder if it can be used for things like better random number generation...

Too slow to be useful, and the BCM283x SoC already has an internal RNG:

https://github.com/torvalds/linux/blob/master/drivers/char/h...

> ... or hardware-accelerated hashing

The TPM is on a really slow bus (33 MHz, 4 bits, tons of wait states). Even without any hardware acceleration, hashing on the CPU is much faster.

You wouldn't hit a TPM every time you wanted a random number. Your OS would just use it when it wanted to seed its entropy pool.

This is particularly useful at boot when entropy is very low.

TPMs are just SPI connected devices. You can add them to any SBC.

Hardware accelerated hashing would be severely limited by the SPI bus speed.

I believe the 2.0 standard does support rng, but I;m not sure of the specifics. there might be some hashing functionality but the interface is going to be too slow for large data. I think it;s there to do integrity checks for bootloaders and such

Without bootloader integration, what's the difference between adding a TPM vs an HSM like [0]? Does TPM just have a more standardized interface?

[0] https://www.zymbit.com/2020/11/10/blog-security-module-raspb...

You can actually add both—there's a partial GPIO header for the Zymkey 4i on the board.

But yeah, I think the idea is TPM is a bit more standardized across hardware, so some software that uses it would not need any tweaks to run on the Pi with a TPM built-in.

>But yeah, I think the idea is TPM is a bit more standardized across hardware

But there are USB HSMs, along with smart cards (which are also HSMs). Aren't those pretty standard?

Sort of; the communication protocol is standard (CCID), but the actual HSM interface varies. Yubikeys implement the OpenPGP smartcard interface, for example, as well as PKCS #11.

The TPM specification has its own crypto interface that is standard across all hardware, so you can do things like generate a key and perform crypto operations without requiring the hardware implement a particular interface beyond whatever TPM version you require.

There are advantages and disadvantages to both approaches. On Linux, TPMs are implemented in the kernel, and CCID is handled by userspace drivers.

The Zymbit is trying to make up for the lack of secureboot/tpm integration on the Pi by securing the enclosure and monitoring that perimeter.