This seems like a lot of code to be running in a security-critical relatively simple device. Does anyone else have the impression that I would rather this device be much, much simpler.
Of course that might raise development costs but that seems like a fair trade off in this case, especially if it causes some "features" not to be implemented because they would be too hard.
What "lot of code"? It's running L4, which is perhaps the simplest operating system that still deserves the name.
A lot of the complexity they're documenting is in hardware: the AES-XEX memory encryption scheme that protect's SEP's memory from the AP (or any other component of the system), the fuse array that controls its settings, the memory filter that restricts AP reads/writes to the mailbox range.
Still more of the complexity is in the AP and in the AP's interfaces and drivers. That's real complexity, but it's outside the SEP's TCB.
I guess I would have expected it to not have an operating system. I understand that and operating system can provide security through isolation but when you are running small amounts of highly security critical code it seems like the isolation benefit would be outweighed by the extra attack surface.
Can you be more specific about the extra attack surface to which you're referring? What vantage point does an attacker need to have to target that attack surface?
Well most data is going through more layers of code. And as a rough approximation the more code running the more vulnerabilities. I guess this "internal" code isn't as critical of a surface because you have to get through the applications but there is certainly still risk.
I'm still not sure I follow. Can you outline a hypothetical in which there is a practical risk, so I know what you're talking about? Obviously, neither of us have all the technical details, so just propose something.
I didn't have any attack in particular, but an example could be sending a long buffer to the kernel that causes an integer overflow and overwrites some important memory. Especially with the non-verified external RAM it seems like you could throw some weird stuff at the kernel.
Of course that might raise development costs but that seems like a fair trade off in this case, especially if it causes some "features" not to be implemented because they would be too hard.