Re: Challenge: Find potential use cases for non-trivial confinement

[Michal Suchanek]

On 5/19/06, Bas Wijnen <address@hidden> wrote:
> On Fri, May 19, 2006 at 03:30:29PM +0200, Michal Suchanek wrote:
> > I guess this may apply to many other services.
> >
> > But you wanted a specific example, and I found that I cannot imagine
> > how ping can be easily implemented without (opaque) constructors.
>
> As a system service.  It runs in constant storage (it creates one packet at a
> time, it needs to wait for the network card anyway if there's another ping
> busy), so this is no problem.  If accounting is required, this uses constant
One packet at a time? How do you receive the pong then? And how do you
perform multiple pings? You may want to ping multiple locations or
send several pings before the pong arrives.
> storage per user as well (if done sensibly), so this can be system storage
> which is conceptually subtracted from the real quota the user should have (so
> the actual quota is slightly lower).  At session creation we are giving the
> user a quota anyway, so this can be paid from that, by not actually giving it
> out at all.
Are you proposing to put yet another service into the user shell? I do
not think that the need for every system service to have a plug in the
user session is a good design. At the very least it is not extensible.
And the shell will be a very large and complex then.

> > In the constructor scenario I can run a service (on user resources)
> > that does bandwidth accounting that ensures the administrator imposed
> > network bandwidth policy but uses user memory and CPU time to store
> > and update the accounting data.
> > Then ping is a simple program that asks this service (or does a call
> > and blocks until the service allows its packet). It then sends the
> > ping, and waits for pong. Any number of (opaque, again) ping instances
> > can be run at any time.
> > The privileged network service can then be reduced to some simple
> > interface like send_packet, receive_packet(_filtered?).
>
> This scheme is completely possible if the user donates CPU time to this
> service (the part which makes the send_packet call) to run (that is, it gives
> it a scheduling capability).

No. If the network bandwidth policy does not use constant space (ie it
wants to enforce something per remote address), and you cannot trust
the user to run it in his own space you get a problem.

Thanks

Michal