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. At least any part of the system where there will be access to hardware and some sort of packet multiplexing, the exact same layout can be used. This will be at least the case for IDE, SCSI, Firewire and USB devices. You could write a very minimalist bus driver with just a packet filter on top of it, both in the TCB (as one or two processes). Then you could add a SCSI or USB stack on top of it, as unpriviledged processes. Maybe some of these buses need a packet filtering a bit more complex than Ethernet, as I don't know how they work much, but I don't see why it couldn't be done. It would give us a very secure and yet incredibly flexible device framework... To rephrase, we want a client process C to be able to send, and possibly receive, data through an unpriviledged (apart from having a capability to T) server process S, without S to be vulnerable to DoS attacks, that has to do some mandatory checks or transformations to the data before passing it to a typically highly priviledged server T, like a server in the TCB accessing hardware. A solution is then for C to provide a space bank to S that it cannot write to anymore while S has the privilege to use it, but that it could reclaim at any time. Curiously, Pierre -- [EMAIL PROTECTED] OpenPGP 0xD9D50D8A
signature.asc
Description: Digital signature
_______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
