"A web browser is a good example of this. The number of security domains is at least the number of origins in use, which can be extremely large. Furthermore, some origins might be CPU-intensive."
Yes. That's the challenge when you try to use a solution aimed to static systems for dynamic systems... Not sure how other will solve this, we will just try to make some sacrifice, in example, by assuming a total fixed memory and CPU available for a domain and how will you offer that to the end user. What is not compatible is the old fashioned way of happily and chaotically assigning resources (expressions like "must be able to compete with each other" I don't think are too much compatible with a predictable behavior...). What is not "normal" to me is how browsers behave and how much we allow to them (that is a party for attackers) in example, with crazy stuff like javascript, etc. So, at some point, the solution designer must decide what to offer to end user. In example, you can set up fixed resources per domain and fixed number of domains. Yes, it is a waste of resources. But it is secure. So you offer this to the customers and explain how it works: no more free browser resources party, no more browsers taking 100% cpu and lots of GB of RAM (with 20 tabs...). Are we crazy? Instead, you can just make a reservation of resources for the secure static system and put your secure stuff there. And forget of those resources, they are not free to be used by other programs, nor by the OS,... Just partition the full system, have a static partition for serious stuff and and dynamic partition for toys. Just a silly example. El jue, 18 abr 2024 a las 5:43, Demi Marie Obenour (<demioben...@gmail.com>) escribió: > On 4/17/24 23:20, Gernot Heiser via Devel wrote: > > On 18 Apr 2024, at 13:13, Demi Marie Obenour <demioben...@gmail.com> > wrote: > > > > properly implements mitigations. Time protection is a principled > solution > > to side-channel attacks, but it requires that the time consumed by > operations > > on sensitive data is not observable. > > > > This is actually not a correct summary of time protection (TP). In > contrast, TP *ensures* that kernel operations are constant time, and that > userspace operations do not produce observable timing variations across > security domains. > > > > Having said that, TP isn’t in the mainline kernel and is still > experimental. We’re planning to restart that project mid-year. > > > > Gernot > > How does time protection handle these two cases? > > 1. Untrusted code can request a service from trusted code that involves > processing sensitive data, and this request may take an unbounded > amount of time. In this case, it is not possible to pad the time > actually consumed to the maximum possible value, because the maximum > possible value does not exist. > > Cryptographic operations involving rejection sampling may be an example > here. It is possible to pad the time to a very large value, since the > probability that N operations will be needed decreases exponentially > with N, but this may be prohibitive performance-wise. > > 2. Operations on sensitive data must be able to consume all available > CPU resources. The main example I can think of is human-interactive > systems. These may be so heavily oversubscribed that it is simply > not possible to statically allocate resources to different security > domains. Instead, even security domains involving sensitive data > must be able to compete with each other. > > A web browser is a good example of this. The number of security > domains is at least the number of origins in use, which can be > extremely large. Furthermore, some origins might be CPU-intensive. > Therefore, the overall system load is an unavoidable side-channel, > at least if one wants fair scheduling. > -- > Sincerely, > Demi Marie Obenour (she/her/hers) > > _______________________________________________ > Devel mailing list -- devel@sel4.systems > To unsubscribe send an email to devel-leave@sel4.systems > _______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems
