The theory is that the boot firmware is executed with the MMU off, and then jumps to your code and is done. Unless you specifically call into ROM, it just sits

The theory is that the boot firmware is executed with the MMU off, and then jumps to your code and is done. Unless you specifically call into ROM, it just sits there unused. Now it could be that there is some hardcoded exception handler in the memory controller that jumps to a specific area of ROM when a certain instruction is hit, and that causes exfiltration of data. But to do that would require a lot of separate components interacting, including ones that Freescale doesn't have access to (i.e. the A9 RTL, and possibly the PL-310 and the memory controller) and would require Freescale put the data exfiltration routine in ROM, or maybe there's an exfiltration routine hardcoded into the PL-310, in which case I wonder how they actually get data out of the machine. As you say, that firmware can't be changed. It can be read out and analyzed for possible security problems, and I hope someone does that. The code is mostly concerned with validating signed boot images for "secure boot" where manufacturers don't want third-party firmwares to be used. It checks the firmware signature / decrypts the firmware using a key burned into OTP fuse bits. Novena doesn't use fuse bits, and in fact doesn't even blow the "boot source" fuses, meaning you're free to change the boot source from internal SD to external SD to SSD to booting from USB. You can actually blow the fuses yourself and load a key known only to you, which means only you can sign firmware that it'll boot.