Re: Alternative network stack design (was: Re: Potential use case for opaque space bank: domain factored network stack

[Jonathan S. Shapiro]

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