At 10:43 AM 12/24/98 +0000, Ben Laurie wrote:
>Hmmm ... do you think it is possible to avoid covert channels?
[#] Our (the KeyKOS group's) analysis indicated that it was possible to greatly limit the bandwidth of covert channels. Norm alluded to a covert channel where the sender and receiver share some limited resource (e.g. disk space). By statically allocating separate pools to the sender and the receiver, you eliminate that channel.
It turns out that timing channels are the hardest to eliminate. KeyKOS was originally written for the IBM S/370. That machine has a user-mode accessible clock which ticks at approximately the clock rate of the CPU. It makes a wonderful tool for performance tuning, and for using CPU usage as a covert channel. In general, you have to restrict access to the clock to eliminate this kind of covert channel. If you limit the precision of the clock, you limit the bandwidth of the channel but do not eliminate it.
Some of the work in "reproducible computing" applies to this problem. If you build a system where programs always run the same way, only dependent on their user specified inputs, then you eliminate them as receivers of covert channel information. This is much harder than it may at first seem. You must ensure that thread switches and interrupts occur at the same place in the instruction stream every execution. In general, it is necessary to eliminate interrupts and thread/process interactions to achieve this level of reproducibility.