[seL4] Re: Confidentiality and realtime requirements

On 8/13/23 12:18, Gernot Heiser wrote:

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

There is also the question of whether current hardware allows eliminating cache channels without an unacceptable performance cost. DRAM access is horribly expensive nowadays, so I am not sure if the overhead of cache partitioning and/or flushing is something that modern devices can afford. I’m also unsure if context switches that do not cross security boundaries are particularly common at all. Is the fast case (no flushing needed) actually that common, or will most context switches require flushing? If the latter, should synchronous IPC be discouraged, with asynchronous designs based on large ring buffers as the recommended alternative? -- Sincerely, Demi Marie Obenour (she/her/hers)