> Date: Sun, 13 Aug 2023 16:18:08 +0000 > From: Gernot Heiser <[email protected]> > Subject: [seL4] Re: Confidentiality and realtime requirements > To: devel <[email protected]> > >>>> On 12 Aug 2023, at 02:07, Demi Marie Obenour <[email protected]> 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.). But I can’t say I know enough about computer science at this time to even tinker with the idea. And also, on the other hand maybe it doesn’t make sense to create hardware and accompanying software that are nearly impossible to non-destructively subvert, given the concerning trend of computer manufacturers and tech companies of restricting what code can run on their products. I don’t want to make something that could be set up to prevent an end user from modifying or running their own code. Isaac _______________________________________________ Devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
