The guarantees offered by the kernel cannot be subverted by unprivileged processes running on it.
Of course, the kernel is not very useful on its own, thus the design of drivers, filesystem servers and other services running on top of the kernel is still relevant.
Note that, unlike most other systems (including Linux) which are flawed at a fundamental level, seL4 actually enables the construction of a secure and reliable system.
No, that's the advantage is that the kernel/processes don't need to be trusted since your kernel guarantees the isolation.
So you can have a Linux kernel running next to some high security process with the guarantee that they will be isolated (with the exception of allowed IPC)
I want the magical IOMMUs that are maturely secure like MMUs are now. For now, I think various efforts in verifying/restricting/generating drivers are far better, although they fall particularly flat for proprietary drivers.
>I want the magical IOMMUs that are maturely secure like MMUs are now.
There's nothing magical about IOMMUs. They weren't invented last week either.
Driver and hardware talk to each other using virtual memory instead of physical memory, preventing the scenario where a bug causes DMA to shit all over somebody else's memory.
What holds is that systems that run drivers in supervisor mode have not been able to leverage an iommu to its full extent.
My (admittedly limited) understanding is that IOMMUs still have practical roadblocks to being a solidly established part of the security of the computer. Of course they aren't bad in principle. Perhaps it's just that we aren't willing to eat the performance cost of making them more robust, but then performance is a tortured debate.
