Re: Potential use case for opaque space bank: domain factored network stack

[Marcus Brinkmann]

At Sat, 6 Jan 2007 02:42:25 +0100,
Pierre THIERRY <address@hidden> wrote:
> 
> Scribit Marcus Brinkmann dies 06/01/2007 hora 02:07:
> > The core point here is that process A does not give any authority to
> > process B that it didn't already have or could have (in principle).
> 
> Only if you assume that the TCP stack is in the same domain that the NIC
> driver. This is already not the case anymore in the mentioned paper,
> IIUC.
>
> In the domain factored implementation, the only process that has
> potentially access to DMA is the "enet" process, which comprise the NIC
> driver and packet multiplexer. All layers above Ethernet are thus
> managed by totally unpriviledged processes WRT memory access.
>
> I'm pretty sure that if we follow a similar methodology to achieve
> isolation of critical components, we will indeed find some other
> scenarios. I'll try to do so, now that I see more clearly what it
> involves and what are the advantages.

Look, the issue at hand for me is not mechanisms, it is policy.  How
you achieve isolation and memory delegation doesn't really matter to
me in the quest for an answer.  The question that is important to me
is: Who are the actors, and what are their power relationships?

By actors I don't mean individual processes, which is what you are
focussing on right now.  To me, the network stack, the ethernet
driver, the kernel and the space bank represent essentially the same
actor, namely the machine owner.  The machine owner dominates, in my
view, the user totally ("trusted computing" and remote attestation
replaces the machine owner nominally with the issuers of the hardware
and the root key certificate).  Thus, it doesn't matter here to me
what the mechanism is by which this dominance is achieved, the end
result is the same.

You are pointing out, correctly, that the mechanism by which the
network stack gets its client memory in isolation is the same as the
one by which a different actor, say another user, could get the client
memory in isolation in a system like EROS.  To you, these two
scenarios appear identical, because the mechanisms are identical.  I
agree that the mechanisms are identical, but the critical difference
for me is who the actors are.  If the power relationship between the
two actors is rightfully total dominance, I have no principled
objection.  If the power relationship between the two actors is
rightfully a sibling relationship, I do.

If you think that this means I could accept the EROS space bank design
if it is only used in relationships where one actor totally dominates
another, then you are approximately correct, however, I would also
inspect other mechanisms as well that may achieve the same or
something similar.

But maybe the alternatives all suck.  In that case the next best thing
would be to write the user's default code in a way that denies to give
out resource pools from which opaque allocation is possible to any
processes other than those in the user's TCB.  Jonathan (IIRC) has at
one time proposed an extension to the space bank that would allow the
creator of a subspace bank allow to choose between transparent
spacebanks and opaque spacebanks, and which would allow the recipient
of a spacebank to check what type it is.  If that is used, my
suggestion would be to always create transparent space banks, except
in the few cases where you know you are talking to an actor who is
dominating you totally, in which case you can allocate an opaque space
bank safely.  That would, IMO, be a safe default (ensuring user
freedom).

Note that this completely leaves open if there are any other
reasonable policies except: reinforcement of total dominance is ok,
and strict separation of peers is ok.  There may be other
constellations that are ok, but I think that this is an extremely
delicate and non-trivial issue.

Thanks,
Marcus