Re: "Yes, it is a waste of resources. But it is secure. " I agree.
I have been thinking of this tradeoff for another security scenario and my current thinking is: - It's just necessary - It's not really a waste. It is a price paid for security and the security is worth the price. - What a caller sees need not be time spinning in the callee but rather deliberate delays offset by servicing other requests. - We are at the level of paranoid security and we need to be. Anything at all that leaks information is a security issue and as we are increasingly seeing adversaries will use the smallest silver of an opening to attack. On Thu, Apr 18, 2024 at 5:20 AM Hugo V.C. <skydive...@gmail.com> wrote: > "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 > -- Bob Trower --- From Gmail webmail account. --- _______________________________________________ Devel mailing list -- devel@sel4.systems To unsubscribe send an email to devel-leave@sel4.systems
