[cap-talk] gauntlet - one way IPC considered useless,
Rob J Meijer
rmeijer at xs4all.nl
Sat Jan 21 02:31:59 EST 2006
> I wrote:
>> Suppose that a process A wants to tell processes B and C to perform some
>> actions P_B and P_C respectively, and be assured that all effects of P_B
>> before effects of P_C. B and C do not know anything about each other.
>> 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
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 of
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 this cost that makes the descission of either accepting
the risk or enforcing the proper pollicy something that falls outside of
basic system design and inside of the realm of itterative risk analysis.
I believe that designing with one-way channels is essential to fully
do POLP(/POLA) in any multi level data enviroment, in some places you will
end up with only one, thus if the outcome of a risk assesment requires it,
in some places you could introduce one-way fibre connections or in other
places you may need to have a respawning process in its own personal
An important point is that one way channels are a good design practice
but true one way channels are ecpensive to realize. There is thus no harm
in designing and building a prototype based on un-enforced one-way channels
that are there in the design and are abstracted truegh some basic API, in
that way you can after the first RA itteration upgrade the IPC channels
with two channels between processes and in some places with one.
More information about the cap-talk