I'm not sure I follow the part I boldfaced there. Not saying I don't believe you or think you're wrong. I just don't follow you there. How do you mean?
Apple has been updating iBridge (the firmware for the T2 chip) pretty much every single OS release (including the incremental ones). That’s a surprising number of updates. And the sort of raw NAND flash used for firmware doesn’t have anything like wear leveling, mostly because there’s not enough of it. In that sort of situation, an SSD could be a better choice for reliability.
That said, it’s still a fairly small number of writes (Apple’s not pushing out monthly updates, although it sometimes feels that way), so we are still talking fairly long lifespans. It makes me think there’s other reasons Apple could have moved this out of the UEFI space and into the recovery partitions.
It wouldn't be "secure boot". I think this is just how Apple Silicon devices have always been. This is the first time the Mac has adopted the same operational design that the iPad, iPhone, and iPod touch have all had since day one. Otherwise, I don't know what benefit there'd be. Unless the idea is that the internal drive has a much greater capacity to manage security settings across every bootable copy of macOS installed on the Apple Silicon Mac whereas a T2 Mac would be limited to what the UEFI firmware could govern (which is to say, all or nothing).
I’m thinking more in terms of the chain of trust involved with secure boot. Moving chunks of what used to be managed by UEFI out into the SSD, and using signing to ensure that it hasn’t been meddled with reduces vectors for attack on the SoC firmware itself and allows you to make ROM rather than NAND flash, like iOS devices. But this thing is still needed for boot, so it must be always accessible like firmware. It’s also important enough to protect, since taking over this pre-boot environment would be very similar to exploits like Thunderstrike.
The fact that what used to be Target Disk Mode prevents access to these extra partitions is interesting, and does have security implications. It essentially ensures that this pre-boot environment is up and running before an attacker can attempt to get at the SSD itself. They could de-solder the NAND, but the NAND being encrypted (and the keys being on the M1 itself) makes that sort of attack more difficult. By preventing an external device from providing a copy of this pre-boot environment, it further limits an attacker’s ability to inject custom pre-boot code.
It’s possible this is part of a defense in depth approach of limiting the attack surface as much as possible. It’s not perfect, since it would still be possible to modify this partition from Linux booted directly on the machine, and it’s possible there are holes in macOS’s read-only partition modes, but it still makes things harder for the attacker. I’d be surprised if Apple didn’t threat model this. They’ve put a surprising amount of work into their boot security on iOS, and Mac has been following suit with the T2.
That said, it’s possible the SoC firmware can only load the pre-boot environment from the SSD controller. USB/Thunderbolt mass storage drivers are more complex than an NVMe-over-MMIO driver would be. Hard to say.
