On 8/13/23 18:25, Isaac Beckett wrote: > > >> Date: Sun, 13 Aug 2023 16:18:08 +0000 >> From: Gernot Heiser <ger...@unsw.edu.au> >> Subject: [seL4] Re: Confidentiality and realtime requirements >> To: devel <devel@sel4.systems> >> >>>>> On 12 Aug 2023, at 02:07, Demi Marie Obenour <demioben...@gmail.com> >>>>> 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) _______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems
