Hacker News Reader

Comment by hackpelican | Hacker News Reader

Does the OS that lies on top of this kernel need to be formally verified as well for the security guarantees to hold?

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.

Well, as long as the hardware underneath it also enables the construction of a secure system.

I don't think we have any such option right now.

An example of this is timing side channels.

Originating in an effort within seL4[0], there's ongoing work[1] in RISC-V to resolve this.

0. https://sel4.systems//Foundation/Summit/2022/slides/d1_11_fe...

1. https://lf-riscv.atlassian.net/browse/RVS-3569

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)

No.

But there are limitations. DMA off, only formally verified drivers

It's also important to note that se4L multicore kernel is not yet verified.

An IOMMU can help significantly with the driver problem, preventing a properly initialized driver from misbehaving and compromising the system.

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.

The primary roadblock is cost and complexity. The technology itself is sound and doesn't have major performance problems.

I want capability-based addressing like in the Plessy 250...

https://en.wikipedia.org/wiki/Plessey_System_250

In absolute terms, sure. At the practical level, you can find a partial answer in the section 7.2 of the paper.

Reply on news.ycombinator.com