[seL4] Re: Conclusions regarding speculation

"However, ensuring that the CPU time used by one domain is not observable by another domain is not possible, and I do not believe this will ever change." I usually see infosec people talking about CPU time and cache to cover "modern" hardware based attacks, which is a good starting point, but just a starting point. Share a beer with anyone with know-how on physics and will give you half dozen ways to attack a workload from another workload in a system that is sharing resources. And I'm not talking about covert channels, which are the last unicorns to protect, I talk about direct info leaks based on several measurable environmental variables of the medium were those workload are being executed. Even with air gaped systems... so sharing hardware you can figure it out... I guess I should release some paper about Marvel CPUs (ARM) and how to play with those naive hardware partitioning concepts we all are blindly trusting. One thing I absolutely agree with Gernot s to simplyfy hardware as much as possible and let the (formally verified) software do it's job when it comes to Time Protection. Even if far from perfect, this is an affordable and realistic approach. For any other hardware-based solution where the words "share/sharing" are wrote down somewhere, I would not even read the specs. El vie, 10 nov 2023 a las 22:02, Demi Marie Obenour () escribió:

On 11/9/23 17:47, Gernot Heiser via Devel wrote:

...

On 10 Nov 2023, at 06:03, Demi Marie Obenour wrote:

- Speculative taint tracking provides complete protection against speculative attacks. This is sufficient to prevent leakage of cryptographic key material, even in fully dynamic systems. Furthermore, it is compatible with fast context switches between protection domains.

It’s also a point solution, that provides zero guarantees against unforeseen attacks.

Unless I am severely mistaken, it provides complete protection for code that has secret-independent timing, such as cryptographic software. It is also cheaper than some of the workarounds existing systems must use.

...

- Full time partitioning eliminates all timing channels, but it is possible only in fully static systems, which severely limits its applicability.

I’m sorry, but this is simply false.

What you need for time protection (I assume this is what you mean with “full time partitioning”) are fixed time slices – ”fixed” in that their length cannot depend on any events in the system that can be controlled by an untrusted domain. It doesn’t mean they cannot be changed as domains come and go.

Based on what information should I set these time slices?

The system I work with has no idea what workload it is running. It can’t require the workload to provide it with hints because existing workloads don’t do that. It can’t ask the user because the user will have no idea either. The most it can do is adapt based on what the workload is doing at runtime.

In Qubes OS, it is completely normal for one VM (effectively a protection domain) to start using almost the entire system’s CPU resources without any warning at all. This could happen because the user just started compiling a big project. The user might then start another CPU-intensive task (such as a video call) in another VM, and that might _also_ try to use 100% of the system CPU resources. And users will expect that the CPU usage of the first workload will decrease when this happens, as some (but not all!) of the CPU time is allotted to the second workload instead.

Given this constraint, I see no way to implement time protection. It _is_ possible to quantize the amount of CPU time allotted to a given vCPU, and to have a process that uses small, random amounts of CPU to generate noise. However, ensuring that the CPU time used by one domain is not observable by another domain is not possible, and I do not believe this will ever change.

...

- Time protection without time partitioning does _not_ fully prevent Spectre v1 attacks, and still imposes a large penalty on protection domain switches.

Time protection does *not* impose a large penalty. Its context-switching cost is completely hidden by the cost of an L1 D-cache flush – as has been demonstrated by published work. And if you don’t flush the L1 cache, you’ll have massive leakage, taint-tracking or not.

Where time protection, *without further hardware support*, does have a cost is for partitioning the lower-level caches. This cost is two-fold:

1) Average cache utilisation is reduced due to the static partitioning (in contrast to the dynamic partitioning that happens as a side effect of the hardware’s cache replacement policy). This cost is generally in the single-digit percentage range (as per published work), but can also be negative – there’s plenty of work that uses static cache partitioning for performance *isolation/improvement*.

Static partitioning based on _what_? On a desktop system, the dynamic behavior of a workload is generally the _only_ information known about that workload, so any partitioning _must_ be dynamic.

...

2) Memory utilisation is reduced, as colouring implicitly partitions memory. This is the most significant cost, and unavoidable without more hardware support. Intel CAT is one variant of such support (partitions the cache by ways rather than set, which has not effect on memory utilisation, but only works on the LLC, and has itself a performance cost due to reduced cache associativity).

Static memory partitioning is completely nonviable for desktop workloads. A VM might go from needing 1/16 of system RAM to requesting over half of it without any warning, and the expected behavior is that unless some other part of the system is using that RAM, the VM will get it. And yes, that does mean that two VMs can communicate by competing for system RAM, just like they can communicate by competing for CPU resources. Covert channels (ones that require cooperation from both ends) are out of scope for Qubes OS and for every other desktop system I am aware of, precisely because the cost of eliminating them is so high.

...

And, of course, without partitioning the lower-level caches you have leakage again, and taint tracking isn’t going to help there either.

If people want to improve the hardware, focussing on generic mechanisms such as support for partitioning L2-LL caches would be far more beneficial than point-solutions that will be defeated by the next class of attacks.

I would much rather have a theoretically sound solution than an unsound one. However, it is even more important that my desktop actually be able to do the tasks I expect of it. To the best of my knowledge, time protection and a usable desktop are incompatible with each other. I do hope you can prove me wrong here. -- Sincerely, Demi Marie Obenour (she/her/hers)

_______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems