Factory Pitfall

Norman Hardy norm@netcom.com
Sat, 26 Dec 1998 09:55:39 -0800


At 11:23 PM +0000 12/24/98, Ben Laurie wrote:
...
>It was precisely this kind of channel I was thinking of when I asked the
>question, though it seems to me that the solution is the same as the
>solution for storage - static allocation of CPU usage.
>
>However, surely the problem is that this means that I have to decide in
>advance that I will support at most n processes, and divide every
>resource into n chunks in advance, and _stick_ to that division. Which
>may give me security, but at hellish expense.

See US Patent at <http://patent.womplex.ibm.com/details?pn=US05574912__>
for a much more general and efficient solution to this problem. We had had
similar ideas but not well developed and not "disclosed". The solution
described in the patent limits itself to "one good guy" security while our
goals are support of mutually supicious programs.

>> 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.
>
>Doesn't that effectively mean we're talking about a purely theoretical
>system?
>
>Cheers,

It isn't as bad as all that.
Reproducible computing has been incorporated in certain Europen computing
systems but I don't have the reference here, (some Siemans system, I
recall). Other uses of reproducible computing help to recover from power
failures in transaction systems. Transactions can be relaibly replayed.

There are two main tricks to achieve this. Bill refers to schemes to insure
that interrupts occur at the same place. Another is to insure that
potential "receiving programs" run in compartments which do not have
multiple threads (processes). There is a partial design for this in Keykos.

I would classify all system as theoritical until they are built. We build. ;-)
Having a simple computing foundation, such as Keykos, makes some tricks
such as this many time easier. The world-state of Unix is not well defined.
Another such trick is check-point-restart. Yet another is "light-cone"
checkpoints where it need not be the whole world that is simultaneously
checkpointed. After too many such tricks, the foundation is no longer
simple, however. On the otherhand, some of the above tricks are synergistic.
...

Norman Hardy  <http://www.mediacity.com/~norm>