Re: Part 2: System Structure

[Michal Suchanek]

On 5/24/06, Marcus Brinkmann <address@hidden> wrote:
> At Wed, 24 May 2006 15:54:34 +0200,
> "Michal Suchanek" <address@hidden> wrote:
> > OK, I as an administrator would trust the system that I can set up a
> > program that users can execute but not modify its execution.
>
> I think that description is incomplete, but it is clear to me what you
> mean, if I consider the background of the discussion.
>
> > The security I gain by this is that the shared services that have to
> > run on system resources can be greatly simplifed or removed
> > completely.
>
> I don't think this is true automatically, or even in general.  User

yes, it allows some quick and simple hacks like the ping example. For
a more general solution a global sheduler that can see the whole state
would be probably needed.

> resources are not durable, so they are not suited for example for
> accounting information.
If the accounting can be transformed so that it stores what the user
can still use rather what he has already used up the user resources
are very suitable.

> > The specific example that is probably of relevance to the
> > Hurd is networking. If you can run part of the bandwidth accounting on
> > user resources the shared scheduler can be simplfied.
>
> Let's assume you are right, and there is a good motivation to allow
> the user to lend opaque storage to the system services.  One good
> example for this is actually the L4 user space kernel memory
> management model proposed for L4.sec by B. Kauler in Dresden.  Then I
> may even agree with you and allow such a mechanism as an exception.  I
> can do this without compromising my overall position, because the
> resources that the user has come from the system in the first place.
> So, one can at least semantically envision a different implementation
> where the system would simply take the required resources from the
> user's resource pool without the user providing it.  Any other

This would need some accounting of the storage given to the sytem.
Otherwise the user may lose the storage that he gave to services that
were killed or crashed.

> mechanism would merely be an implementation or management convenience
> or optimization.  One reason this works is that the user does not get
> any confinement guarantees for system services.
> This perspective reveals that the discussion of system services
> completely misses the point.  In the case of system services, there
> already is a uni-directional dependency between the two involved
> parties, even if not explicit in the process hierarchy, that can be
> exploited to admit an exception.
>
> I meant to say the above some time ago, but somehow managed to miss
> several opportunities to do so.

This leaves only the competition/exam cases. It looks these are mostly
minor or work around some problems that originate outside of the OS.

Your arrangment creates a new class of programs.
As I understnad it, there are two types of programs in EROS/Coyotos.
Persistent, and nonpersistent. The distinction between user and system
program is only in naming. They are in fact equal.
But in your system you get nonpersistent programs, persistent system
services (that run outside of user sesssions and have the right to
chop storage that was sent to them from the sessions), and persistent
user programs running inside user sessions.

You also introduce a new type of possible failure: a user session
running out of storage by talking to system services.

> > > that I have seen where on the fence.  For example, the ping example
> > > was a case where I think that we could very well agree on alternative
> > > mechanisms that achieve some of the goals you want without going all
> > > the way.  Note that one goal of the Hurd is to _reduce_ system code
> > > and to maximize flexibility.
> >
> > I want to hear the middle solution for the above problem either
> > abstract or specifically for ping so that I can abstract myself and
> > see if it is able to solve the problem for other services.That is why
> > I ask.
>
> I think the main motivation of your ping example was to provide
> quality of service guarantees by controlling the load a user can put
> on the network.  The accounting information needed for that have a
> fixed size, that is limited by the number of users and the total
> bandwidth of the network (and other factors).  This is sufficient to
> implement a robust and scalable network system service.  There is no
> need to run anything on non-durable user-provided resources.

yes, something like a round-robin scheme should be good enough for
most cases  and it is not very dynamic. Perhaps the user could get a
capability to a packet queue, and there would be a list of queues from
which the scheduler reads a packet at a time (if available). Higher
priority queues could be listed more than once. To make configuration
easy the queues could be even listed in some directory if that does
not get too slow.

Multiple priority categories (like realtime, interactive, bulk) could
be handled by creating several queues. And new categories will
probably not just appear dynamically.

I do not see much use for per ip accounting (although it might be
mildly interesting for the icmp echo packets). But there are very
dynamic things like giving more priority to users (queues) that have
been idle lately.

> Here is a better example that may be more fruitful: It may be slightly
> different for the acutal I/O buffers that are exchanged between the
> user and the driver.  Because they may be formatted, and a layer
> between the user and driver may need to verify and enforce the
> validity of the format, we may need to make the user-provided buffer
> opaque for a transitional period (during DMA, for example).  In
> principle, I can think of more than one way to do this, either by
> resource exchange, or by actually making the user buffer temporarily
> opaque.  However, I can justify such an exception as described above.

I was somewhat concerned by the driver case. But if the dma buffers
aren't too large they can be paid by the driver, and it would just map
the user data in the buffer and return an empty page.
This has an interesting feature: when the transmission fails the data
is likely lost. The same would likely happen if the data was
substracted from the user quota and the quota increased when the
transmission ends. But constructors do not help with this problem,
they do not solve memory pinning.

> > I did not beleive so but it really looks like you sidestep some
> > questions.
>
> I did sidestep the ping question previously, because I was not sure
> what you wanted to achieve, and because that particular part of the
> system is underspecified at this point (ie, we are leaving out a lot
> of relevant details), and any exceptions that may be needed for system
> services can easily be justified on other grounds.
Yes, there are several interesting problems in networking.
It looks like it is impossible to create a send capability that
delivers to multiple receivers which is exactly how networking works.
This requires a system service that receives all packtets and forwards
them to a client based on port number or similar. It would be needed
for inbound bandwidth accounting anyway.
I wonder if one can trust users to do TCP on top of IP themselves -
outside of system space. It requires some buffering so it would be
good thing to move TCP out of the system. Here a constructor would be
nice.


Thanks

Michal