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

Reply via email to