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

On 8/14/23 11:59, Gernot Heiser wrote:

On 15 Aug 2023, at 00:34, Demi Marie Obenour wrote:

...

...

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.

I’d claim they don’t help at all. They might if “random” was truly random, which in hardware is rarely the case. “Random” cache replacement is more properly described as “unspecified”. In reality it’s usually using some existing state (eg some counter) and as such is actually fully deterministic, you only have to reverse-engineer the mechanism.

Besides that, fully-associative caches (unless very small) are inherently slow (long critical path) and energy-hungry many gates to traverse).

What about Chameleon Cache (https://arxiv.org/pdf/2209.14673.pdf)?

...

Speculative taint tracking helps close some of the remaining holes.

I’m highly sceptical too. Taint-tracking has to be highly pessimistic to be feasible, and adds a lot of complexity to the hardware (which gets back to my earlier argument: make it more complex and you’re making it more likely that something goes wrong).

You’re not wrong. I just don’t know if a better solution for fully dynamic workloads exists. -- Sincerely, Demi Marie Obenour (she/her/hers)