[seL4] Re: CPU design, Re: Confidentiality and realtime requirements

On 8/13/23 18:25, Isaac Beckett wrote:

...

Date: Sun, 13 Aug 2023 16:18:08 +0000 From: Gernot Heiser Subject: [seL4] Re: Confidentiality and realtime requirements To: devel

...

...

...

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

If you want to relax this, you’ll need a very careful analysis of your security requirements, and deploy TP where needed and omit where it’s not needed. But you can't prevent µarch timing channels without TP. Everybody knows about D-cache channels these days and how easy they are to exploit, and similar with LLC channels. And if you want to prevent at least those, then full TP has no extra cost.

Does time protection require temporal isolation?

Nope. Time protection is the mechanism that allows providing temporal isolation.

...

...

Developing such a framework is on my agenda (it’s a core part of what I said I’m waiting for a good PhD student to work on). Basically I want to be able to make certain security guarantees where components have overt communication channels. An example is tab isolation in a browser: We want to have a fully functional web browser that allows processing of sensitive information in one tab, but guarantee that it cannot be leaked to a different tab.

Another good example is different apps on a mobile device. Android allows any two applications on the same profile to communicate with mutual consent, and yet also allows one application to keep information secret from another.

Yes. The smartphone space is really interesting. While built on top of the classical Unix security model (but implementable on a much simpler model) it demonstrates that stricter security policies (compared to desktops) can be made acceptable to users.

...

One critical requirement is that such a framework must allow an efficient implementation, both in terms of performance and power consumption. If it isn’t efficient enough to be deployed, then it won’t do people any good.

Energy is (to first order) proportional to computation, so just looking at “performance” is good enough.

And performance has always been our driver – see “security is no excuse for bad performance!” ;-)

As I argued earlier, the performance cost of time protection is not higher than what you need to eliminate just the most easily exploitable cache channels.

Gernot

This makes me wonder if it’d make sense to design a new CPU and/or instruction set with the goal of eliminating timing and other side channels. Like, we had the Lisp machines with hardware support for Lisp, and now most CPUs are optimized for C and similar languages, and in turn those languages are optimized for those CPUs (x86, Arm, etc.).

Fully-associative caches with random eviction help a lot. Speculative taint tracking helps close some of the remaining holes. It’s not perfect, but it is the best one can do without cache partitioning or heavyweight flushing, and I suspect both of those are often impractical from a performance perspective. There are designs for fully-associative caches that are practical, at least for levels other than L1. -- Sincerely, Demi Marie Obenour (she/her/hers)