[cap-talk] gauntlet - one way IPC considered useless,
Rob J Meijer
rmeijer at xs4all.nl
Sun Jan 22 15:22:54 EST 2006
> Rob J Meijer wrote:
>>>>Suppose that a process A wants to tell processes B and C to perform
>>>>actions P_B and P_C respectively, and be assured that all effects of
>>>>happen before effects of P_C. B and C do not know anything about each
>>>>There are only a few possible ways to implement this:
>> If you remember that:
>> a) Two way comunication channels can be composed of two one way
>> communication channels.
>> b) B could in time exist as different incarnations.
>> c) incarnations of B can have a one-way IPC channel to A for as long
>> as they don't read any secret.
>> d) Only on reading a secret would the B->A channel be revoked.
>> e) If a B incarnation chooses to it can have itself die and be respawned
>> with the B->A channel restored in the next incarnation but with non
>> its possible secret related state intact.
>> than you would see that the problem is actualy much smaller than you
>> think it is. Dropping state time and time again is expensive, but it is
>> a solution.
> It is a solution in some cases. What about all the cases in which it is
> not, because B needs to retain its state?
If B only needs to retain its state from before it read the secret, than
simple paterns suffice and multiple rather standard options are available.
If B needs to retain its state 'after' it has read the secret, than B
either needs to permanently drop its B->A channel, or B needs to be
promoted to a trusted
subsystem. Promoting subsystems to trusted subsystems is something that
is in general rather expensive as it involves extensive code audits,
dedicated resource pools and a lot of things you generaly learn you
want to avoid after having gone truegh the process ones or twice.
> I don't think I'm overestimating the problem of building an entire system
> using the techniques you're suggesting, at all. The costs, in terms of
> complexity, unreliability and inefficiency, are enormous, and the benefits
> too small.
The simple fact is that fully persistent two way communication is
incompatible with untrusted (that is un-audited, not unknown) handling any
secret. A second fact is that promoting code to a 'trusted' level is
exceptionaly expensive for anything but the most trivial re-usable
components. These two facts combined make that any practical system
that works with clasifications of data will need to use one-way
communication channels at some points in their design.
In my experience the added complexity with one-way channels is an
acceptable payment for avoiding or minimizing code audits, that I believe
are much more expensive given the complexity involved with proofing fully
connected and interconnected subsystems to enforce the required policies
the system design and the resulting code to a full scale certifying auditing
More information about the cap-talk