Hi, Pierre THIERRY <[EMAIL PROTECTED]> 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. _______________________________________________ L4-hurd mailing list L4-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/l4-hurd
