On the last conference held by the Chaos Computer Club in Germany, there was a talk about a covert side channel[0] using - if I understood and remembered that correctly - cache timings.
The researchers that gave the talk claimed that they could establish a very slow but practically undetectable communication channel between two VMs running on the same host.[1]
Since the introduction to Muen explicitly mentions defense against covert channels, could somebody explain to me if this system would be able to prevent such communication? And if so, is it possible to explain the mechanism to somebody like me who knows basically nothing about these things?
[1] Again, if I understood that talk more or less correctly (probably less), undetectable refers both to the OS running in the VM and to the hypervisor.
I can't speak for Muen but I can a bit for this problem area. This attack has been known for a long time. It's why physical separation and CPU's with separate caches were used in high-assurance security. Anything shared is a potential, covert channel. Timing channels are the hardest to mitigate so share nothing if you're worried about that, right? Well, some sharing is needed so what to do.
1. Since security kernels of the old days, any shared stuff is supposed to be cleared before the next thing uses it. That principle here would be register overwriting and a cache flush when a separation kernel switches between partitions. It's called "periods processing" in the literature.
2. If no shared cache, then we can keep Security Domain A running on Core A, Security Domain B on Core B, etc. There can be multiple, concurrent VM's on each core so long as they are in same security classification (trust each other). Take the penalty of separation when it matters.
3. Partitioning and/or real-time caches. In real-time caches, you lock the cache for determinism. That determinism might be used to aid covert, channel mitigation. The other mechanism is stronger whereby you design the cache itself to know mutually-distrusting processes are using it. A combo of the CPU, cache, and/or separation kernel might wall off parts of it, erase parts of it, replace parts of it, and so on. There's quite a few prototypes in CompSci of this. Maybe some commercial implementations but my brain is too tired to remember.
4. Asynchronous, randomized execution to throw off timing. I came up with this one independently studying the problem probably with inspiration from others randomizing timing in asynchronous way. More importantly, another person did the same concept implemented on a prototype CPU.
5. Run with no cache. Very painful. Barely a solution. It's been done, though.
I'm sure more of this can be combined in interesting ways with randomized storage in caches w/ randomized timing and/or that controlled by separation kernels. It's mostly a hardware problem, though, like software safety against code injection. Most in high-assurance have moved on from separation kernels to other tech, esp modified CPU's, to solve the problem bottom-up like Burroughs B5000 did for some things. Last efforts I looked into were Cambridge CHERI processor w/ CheriBSD, SAFE processor at crash-safe.org, and Watchdog[Lite]. Gotta add cache protections, IO/MMU, RAM cryptosystem, TRNG, and so on.
Wrt "run with no cache": is a shared DRAM that much better than a shared cache? The DRAM state is affected by what previously accessed it, in fact DRAM effectively has an SRAM on-chip "cache" keeping the current active row per bank. ("Cache" in quotes because it's a bit crummy if you think of it as a cache - there's just one way, #lines is 4-8 and their size is measured in kilobytes - but technically it's a cache.)
Far as DRAM state, the separation kernel keeps the state of one process separate from another. Harder to do with a cache without defeating the performance-enhancing purpose of a cache.
"in fact DRAM effectively has an SRAM on-chip "cache" keeping the current active row per bank."
Had no idea. That could be a problem. See why we systems people defaulted on physical separation during most of the Moore's Law advances? Never know what hardware issue will pop up.
The researchers that gave the talk claimed that they could establish a very slow but practically undetectable communication channel between two VMs running on the same host.[1]
Since the introduction to Muen explicitly mentions defense against covert channels, could somebody explain to me if this system would be able to prevent such communication? And if so, is it possible to explain the mechanism to somebody like me who knows basically nothing about these things?
[0] https://media.ccc.de/v/33c3-8044-what_could_possibly_go_wron...
[1] Again, if I understood that talk more or less correctly (probably less), undetectable refers both to the OS running in the VM and to the hypervisor.