[coyotos-dev] sleep capability

[Jonathan S. Shapiro]

On Sun, 2007-01-21 at 18:55 +0100, Pierre THIERRY wrote:
> While reading the various kernel capabilities specifications, I was
> worried by the fact that the sleep capability would also enable a
> process to detect reboots. I suppose it would only be possible if the
> process has also authority to get the current time, so I'm wondering how
> would access to the clock be regulated. Is a ioperm capability needed to
> access the hardware clock?

This is a more subtle question than it appears to be.

First, concerning reboots: reboots are rare and user-controlled. There
is no real security risk in observing them.

The issue that deserves greater concern is the hardware clock -- or more
precisely, in precise information about system load. The hardware clock
is primarily a means to calibrate other mechanisms of covert
communication.

There are two sources of clock exposure in Coyotos: the hardware time
stamp counter and the run-in specification. The combination is
especially bad, since the run-in notification can be used in combination
with RDTSC to get very precise scheduling information.

We could easily change this part of the specification so that run-in
notice was delivered only to real-time processes, but here are some
issues:

1. Real-time processes are now ubiquitous, and probably untrusted, so
this limit really would not help.

2. Running a second thread on a concurrent CPU is good enough to get a
very high accuracy clock. With most modern CPUs being multithread or
multicore, this means that disabling RDTSC will not help. Further, a
shared page is sufficient to provide highly accurate run-in information
under these conditions.

Given (2), the only real solution is a deterministic scheduler. The
problem with this is that real users will not accept a 90%+ reduction in
effective computer speed.

Norm Hardy and I have gone back and forth on this with no happy
conclusion.
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100