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

[Marcus Brinkmann]

Hi Pierre,

At Fri, 5 Jan 2007 21:59:51 +0100,
Pierre THIERRY <address@hidden> wrote:
> I just read the "Network Subsystems Reloaded" paper by Sinha, Sarat and
> Shapiro. Part of it discusses a network stack implemented for EROS with
> several isolated processes. As such layout typically lacks performance,
> they at least avoid copying accross protection boundaries with shared
> memory.
> 
> A client of the TCP stack would give it access to four memory regions:
> two for TCP headers and two for payloads, for transmission and
> reception. This avoids DOS attacks by clients because the stack doesn't
> use it's own limited memory to work on behalf of it's clients.
> 
> But to ensure correctness of network packets, header sections must not
> be writable by the client.
> 
> With the design of space banks as it was vigourously debated earlier,
> would that be even possible? IIRC, it was not considered desirable that
> a process A could give authority to some of it's resources (here,
> memory) to another process B while losing some of it's own authority to
> it (but having the ability to reclaim it back).

Right, thanks for bringing this up.  This has been discussed before,
please have a look at the following e-mails.  The example there was
the "ping" example (whatever that is, I can't find the original mail
where it came up), but I understand that it has essentially the same
properties as the TCP stack you describe above.

Bas' mail: http://lists.gnu.org/archive/html/l4-hurd/2006-05/msg00524.html
My response: http://lists.gnu.org/archive/html/l4-hurd/2006-05/msg00526.html

I will repeat my response in short here to be clear.  I admit that
this is a good and useful example for such an operation.  Another
example I consider to be similar is the L4.sec kernel memory managed
in user space.  Note that the network driver wants to do DMA
and thus needs to be able to lock down the memory anyway, at least for
a short period of time.  So, in a sense the TCP stack already
dominates the user, it is part of the TCB.  In this case, the
implementation details of how the memory allocation is organized is of
minor relevance to this question, IMO.

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).

Bas suggested that similar scenarios could pop up outside of the TCB.
This could happen when DMA transfers can be secure and a number of
other assumptions are made.  I am not really convinced at this point
that such scenarios as Bas' non-cooperatively shared USB high-speed
network adapter are all that practical, common or relevant.

Thanks,
Marcus