Re: Part 2: System Structure

[Marcus Brinkmann]

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
resources are not durable, so they are not suited for example for
accounting information.

> 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
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.

> > 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.

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 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.

> Or what part is so unspecific that you think it is a
> management buzzword question rather than a technical one? What do you
> want me to explain in more detail?
> How does your solution reduce code and maximize flexibility (is that
> more than buzzwords)? As I understand the constructors they do exactly
> that.

By focussing on the mechanisms and issues that really matter to the
system.  The system doesn't care about how many ping programs you are
running, or how you organize them.  The system may care about the load
you put on the network, and if filtering network traffic is necessary,
it may also care about the content of the individual packets (although
I am not sure that is really a valid concern).  So, we have to look
for the minimal mechanisms that achieve that.

Thanks,
Marcus