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

[Ludovic Courtès]

Hi,

Pierre THIERRY <address@hidden> writes:

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

FWIW, this design issue is somewhat addressed, in simple terms, in
Section 2.3 of Jonathan Rees' ``A Security Kernel Based on the Lambda
Calculus'':

  http://mumble.net/~jar/pubs/secureos/

For performance reasons (mostly), he argues for kernel support for
"seals".  As far as I understand, seals can be thought of as a mechanism
similar to "opaque storage", but they are more specific in that they
were designed solely to allow for the implementation of abstract data
types, as in the network packet example.

Thanks,
Ludovic.