[seL4] Re: Confidentiality and realtime requirements

On 12 Aug 2023, at 02:10, Demi Marie Obenour wrote:

On 8/11/23 07:46, Gernot Heiser wrote:

...

On 11 Aug 2023, at 21:33, Hugo V.C. wrote:

...

That's it. And here is were I think we all in the security industry are failing. I don't think we can solve that nowadays with the current hardware/CPUs and "mix" things, moreover, even if someone dares to do it, I guess it will be extremely complex to make guarantees. Instead of "relaxing" the security policy, I bet to solve that by, literally, make hardware partitioning, with different OSs, the general purpose one and the one with guarantees and then transfer sensible workloads to the hardware partition with the OS that gives you guarantees. I'm aware that here interaction between those two systems introduces new challenges, but IMHO it simplifies a lot the design.

I’m not convinced that there’s a case for more HW support than the simple mechanisms we propose in the TP paper, and which Nils instantiated in fence.t. Unless you go for something that is *very* complex, and will just create more opportunities for loopholes.

"Simple is better” applies in the security context even more than in other contexts. Pick the simplest mechanism that does the job, and then use it judiciously.

I agree, but in this case, I don’t know if a simple solution exists. The workloads people want to run aren’t simple, and the security policies they want to enforce aren’t simple either.

I’m yet to see a system that cannot be built on top of simple mechanisms. Policy-mechanism separation is one of the most powerful concepts in system design. Unfortunately, most people just try to solve problems by adding features (and thus complexity) instead of stepping back and try to understand the root causes of a problem and how it can be solved at the root. Featuritis would have never produced something of the power of seL4, but instead has produced all the security debacles we see day after day. Gernot