On Sat, 2007-01-06 at 19:20 +0100, Marcus Brinkmann wrote: > Hi, > > another approach would be to combine all the resources that a network > service needs into a single resource container, which is managed in a > way similar to space banks, but using a separate management service (a > "network bank"?) that can only be used by privileged system network > services responsible for implementing the scheduling policy (ie, it is > not general purpose).
This sounds like you intend to have all network buffers owned by the network subsystem. If so, you have re-invented denial of service. Could you clarify whether this is the case? Also, can you give a principled argument for how much resource (i.e. how much memory) the network resource container should hold? Finally, given that there is no statically correct answer to how much resource it should hold, can you justify why an unprincipled special purpose solution that implements the restrictions you object to in the space bank is in some way better than a principled, general-purpose solution? > There is some hazard attached to having two "classes" of memory, but > the system could provide a service to move resources from one type of > contingent to the other according to some policy. In a dynamically > configured system there need to be ways to rebalance contingents of > resources anyway, so that seems to be a small price to pay. It is exactly the case of a dynamic system that most concerns me. The rebalancing you speak of is an intrinsically bad thing. What makes it necessary is the partitioning of memory, which was not technically motivated. The problem with this class of policy is that there is no generally correct choice of policy, and you find later that the initial policy will be required to add another policy. In short: policy begets policy. I have yet to see any policy for constrained resource of this type that is not subject to denial of resource attacks. The best solution here is simply to have the clients supply the storage, which guarantees that all incentives align against the attacker and in favor of the well-intentioned user. > One advantage of binding resources to a certain specific use in this > way is that the resource can be delegated easily for a specific > purpose. Consider a web browser which I want to debug or monitor, for > example using intrusion detection techniques. If the malicious code > can hide in opaque memory, this fails. So I have to give only > transparent spacebanks to the web browser, but then it can't use the > network anymore. Yes. A hard requirement for transparency is a *fundamental* violation of encapsulation at an axiomatic level. There are a great many things you lose if you require this. If your goal is to be able to monitor processes. It is better to achieve the transparency you want at the constructor, not at the storage allocator. What you need is access to the address space. A variant constructor can provide this. > Of course some of this could be implemented in a user's shell based on > the EROS spacebank and factored network stack model. The interesting > question is if conflating resources into a bundle at the system level > allows for more optimisations or more efficient resource scheduling. > Any takers? A page is a page is a page. Relabeling pages into classes only ensures that their management is more complicated. -- Jonathan S. Shapiro, Ph.D. Managing Director The EROS Group, LLC +1 443 927 1719 x5100 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
