[tptacek]

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.

[kevincox]

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.

Everything is a trade off I guess...

[tptacek]

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?

[kevincox]

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.

[tptacek]

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.

[kevincox]

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.

[95014_refugee]

You cannot "send a long buffer to the (l4) kernel".

You would know this if you had read the available documentation. 8)