Hacker News Reader

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.

View on HN

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.

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.

Reply on news.ycombinator.com