This is purely an artifact of poor system design. x86 platforms are notoriously bad at this.
I'm reverse engineering the Apple M1 and haven't found any trustability issues yet (besides the proprietary early stage bootloaders, but everything has that). There are some 12 or so coprocessors running proprietary firmware, but all of them are safely behind OS-controlled IOMMUs and not privileged to take over the system. There is no ME, no SMM, no TrustZone, nothing running with higher privilege than the OS. Most of the coprocessors have at least inspectable firmware (except the Secure Enclave, but you can just turn it off). The ARM architecture design makes it near impossible for an early boot backdoor to, say, run your OS in an undetectable VM too. No updatable microcode.
On x86 you have the ME running secret code with higher privilege than the main CPU, as well as SMM running secret code on the main CPU at a higher privilege than the OS and stealing cycles from it, as well as a rather poor track record of proper IOMMU sandboxing (especially for anything that isn't a PCI device), and secret, encrypted microcode updates.
> I'm reverse engineering the Apple M1 and haven't found any trustability issues yet
... except for assuming "EL3 seems to be missing" means "EL3 doesn't exist" instead of "the bootrom dropped to EL2 before we got control".
Not saying I have any evidence to the contrary, nor is this in any way a criticism of your awesome work. Just saying that this will unfortunately remain forever unknowable unless Apple decides to volunteer information.
Personally, if I were Apple, instead of removing EL3 I would've left it in but unused, accessible only to code signed by Apple with the public key burned into silicon. As a way to mitigate currently-undiscovered silicon bugs.
Your argument is equivalent to "Apple might have backdoored the CPU". Well, yes. So might have every other CPU vendor.
If EL3 were to exist, for starters, it would have no way to receive interrupts, as Apple uses both IRQ and FIQ for the OS (normally FIQ is used for EL3 on platforms with a secure monitor).
These bits amount to Apple saying "there is no EL3" and constitute one of the few pieces of official documentation attributable to Apple.
PS, if you're maintaining any kind of list of "why the M1 is more trustworthy than chip XYZ", the fact that there is a MSR-like bit declaring that the feature doesn't exist should definitely go on that list. Just to make it clear that EL3 not existing was something declared by the chip rather than assumed by the reverse engineers.
Including EL3 is not free, it requires silicon validation effort. Apple has no use for EL3, so it is gone. They have other ways to patch things anyways, though there are limitations. (FWIW, we also know there isn't an EL3 because we have the code the processor runs as it comes out of reset.)
The M1 does not support nested virtualization, so if you put a VM hypervisor under an OS, the OS knows it's running in guest mode. Making it transparent would imply implementing nested virtualization in software in an undetectable way, which is nigh impossible given the way the architecture is designed. Undefined/illegal/HV-privileged instructions don't trap to the hypervisor, nor does the "am I a guest?" instruction. You have to get into full guest code analysis and patching territory. It's a giant mess, and cannot be done without massive performance overhead.
I'm reverse engineering the Apple M1 and haven't found any trustability issues yet (besides the proprietary early stage bootloaders, but everything has that). There are some 12 or so coprocessors running proprietary firmware, but all of them are safely behind OS-controlled IOMMUs and not privileged to take over the system. There is no ME, no SMM, no TrustZone, nothing running with higher privilege than the OS. Most of the coprocessors have at least inspectable firmware (except the Secure Enclave, but you can just turn it off). The ARM architecture design makes it near impossible for an early boot backdoor to, say, run your OS in an undetectable VM too. No updatable microcode.
On x86 you have the ME running secret code with higher privilege than the main CPU, as well as SMM running secret code on the main CPU at a higher privilege than the OS and stealing cycles from it, as well as a rather poor track record of proper IOMMU sandboxing (especially for anything that isn't a PCI device), and secret, encrypted microcode updates.