[emidln]

If you take a look at the binary that decides whether to boot the secure firmware or the tamper screen, it's probably trivial to patch to get the secure firmware running for more inspection. If the point of the linux system is networking and updates, that implies a method for updating the firmware of the secure portion which isn't ideal. If their check for whether it's tampered or not is in the linux userland, I'd be awfully suspect of their firmware update.

[stgl]

The binary that decides whether to boot or go into tamper mode is the "loadercode", which is integrity-protected (I think by a Boot ROM or similar).

The secure firmware can be updated, but it is signed as well.

[emidln]

If the integrity protection is like any of the TPM implementations I've seen, it often doesn't apply once the thing is already in memory, just that when it first loads that it (and everything before it) was attested. This matters a lot once you get into the userland, esp with an older system, since any random off the shelf exploit can be chained into modifying kernel memory with the intention of modifying the binfmt loader for loadercode (or anything else). Of course, if the loadercode is just a thin shim to prod the secure firmware and that's what has the tamper mode rather than being two separate firmwares for controlling the display, you probably can't progress very far.

I'm essentially skeptical that if you have the ability to control the linux root filesystem for a very old linux distro that any other security measures for the linux binaries themselves matter.

[stgl]

Linux does not handle any secure binaries. It only shares a filesystem where the signed and encrypted secure images are. The loadercode verification is not done in Linux, rather the insecure bootloader will read it from the filesystem load it to some memory address, that's it. From there, it is integrity-checked (?) and then executes on the second, secure core. This will then verify and chainload the secure image.