Do we want a server on `/servers/machine' (or similar)?

Hello!

The Hurd console needs to access i/o ports and video memory.  Likewise
does X.org.  The pciutils need to access i/o ports.

For i/o ports we're fine, through the just-installed
`i386_io_perm_create' and `i386_io_perm_create' rpcs (or through glibc's
`ioperm', which in turn just uses those).

The Hurd console's video memory access is also fine: for OSKit-Mach a
`mmap' is done on `/dev/mem', for GNU Mach a `vm_map' is done after a
`device_map' on the `kb' device; see
`[Hurd]/console-client/vga-support.c'.  However, for X.org video memory
access is currently not possible, because I removed the `iopl' device
from GNU Mach, which it previously used akin to the Hurd console using
the `kb' device.

Now, how about the following: we have a server sitting on
`/servers/machine' (or somewhere else) that accepts rpcs like
`io_perm_create' or `memory_map_create' and ``forwards'' (it need not
really be forwarding) them to the kernel after having done some
permission checking.  That server would hold access to the device-master
port (and host-priv as well?), so it could also -- being a proxy -- allow
access to (e.g.) `i386_io_perm_create' to users that can't get such
access by themselves, but can prove that they should be allowed such
access.  Proving this might be something like: ``When you're a member of
the `console' group, you're allowed to get access to the i/o ports that
deal with video output and to the video memory.''

An example: in order to get access to video i/o ports, user U invokes a

Re: Do we want a server on `/servers/machine' (or similar)?

On Wed, 2007-05-09 at 17:53 +0200, Thomas Schwinge wrote:
> Now, how about the following: we have a server sitting on
> `/servers/machine' (or somewhere else) that accepts rpcs like
> `io_perm_create' or `memory_map_create' and ``forwards'' (it need not
> really be forwarding) them to the kernel after having done some
> permission checking.  That server would hold access to the device-master
> port (and host-priv as well?), so it could also -- being a proxy -- allow
> access to (e.g.) `i386_io_perm_create' to users that can't get such
> access by themselves, but can prove that they should be allowed such
> access.  Proving this might be something like: ``When you're a member of
> the `console' group, you're allowed to get access to the i/o ports that
> deal with video output and to the video memory.''

I think this is roughly the right structure, sounds good.

I don't much like the name /servers/machine; so let's figure out
something better.  Names like that persist forever, so it's actually
more important than it might seem to get them right from the get-go.

Thomas

_______________________________________________
Hurd-devel-readers mailing list
Hurd-devel-readers <at> gnu.org
http://lists.gnu.org/mailman/listinfo/hurd-devel-readers

Re: Do we want a server on `/servers/machine' (or similar)?

That is more or less what we always planned.  For the server that only
deals with io ports, call it /servers/ioperm.

Re: Do we want a server on `/servers/machine' (or similar)?

Hello!

On Wed, May 09, 2007 at 12:35:03PM -0700, Roland McGrath wrote:
> That is more or less what we always planned.

Good.  Have such things been written down somewhere?

> For the server that only
> deals with io ports, call it /servers/ioperm.

Fine, but are you in fact suggesting to have separate server for i/o
ports and memory access?  I would have stashed those two interfaces (as
well as any others?) into one single server.

On Wed, May 09, 2007 at 09:54:22AM -0700, Thomas Bushnell BSG wrote:
> I don't much like the name /servers/machine; so let's figure out
> something better.  Names like that persist forever, so it's actually
> more important than it might seem to get them right from the get-go.

I completely agree.  I didn't like that name myself, but couldn't easily
come up with a better one, so posted that one more or less as a
placeholder.

Now, if Roland suggests to separate the i/o port and memory access
interfaces then we could (for example) simply have the suggested
`/servers/ioperm' and a `/servers/mem' (or `/dev/mem'? -- but our thing
is more advances than the usual Unix system's `/dev/mem' is, so we'd
rather put it into `/servers/', I think).

Do we want separate servers?

Re: Do we want a server on `/servers/machine' (or similar)?

On Fri, 2007-05-11 at 00:06 +0200, Thomas Schwinge wrote:
> Now, if Roland suggests to separate the i/o port and memory access
> interfaces then we could (for example) simply have the suggested
> `/servers/ioperm' and a `/servers/mem' (or `/dev/mem'? -- but our thing
> is more advances than the usual Unix system's `/dev/mem' is, so we'd
> rather put it into `/servers/', I think).

/dev/mem is a specific thing; writes to /dev/mem are supposed to write
physical memory addresses directly.  Nothing prevents such an interface
being used for this purpose, but it doesn't seem to me that it would be
possible to have fine-grained control over /dev/mem and still maintain
that interface.

Thomas

_______________________________________________
Hurd-devel-readers mailing list
Hurd-devel-readers <at> gnu.org
http://lists.gnu.org/mailman/listinfo/hurd-devel-readers

Re: Do we want a server on `/servers/machine' (or similar)?

> Good.  Have such things been written down somewhere?

Probably not.

> Fine, but are you in fact suggesting to have separate server for i/o
> ports and memory access?  I would have stashed those two interfaces (as
> well as any others?) into one single server.

It doesn't matter deeply.  The io port allocation interfaces have to be
used on a well-known port location like /servers/ioperm because the name
goes into libc's implementation of the ioperm function.  It doesn't hurt
for that to be a symlink to some other /servers or /dev node if there is a
single server doing several things.  The important point is that what nodes
to use as the public interface for a system-wide facility is an interface
choice, and how many different servers actually control which interface
nodes is an implementation and policy choice.

There is no necessary intrinsic relationship between the io port and device
memory access facilities.  The traditional interface for applications on
other systems is the ioperm function and mmap on /dev/mem, which are not
tied together.

As long as the two facilities are actually doing independent things, there
is no special reason to do them in the same server.  For simple facilities
with canonical Unixoid access control, a simple ioperm delegation server on
/servers/ioperm and a simple memory mapping delegation server on /dev/mem
make sense to me.  (That is starting out mimicking the basic structure of
monolithic kernels' facilities for this.)  The latter might be implemented
as case of general libstore mapping to a microkernel device, adding an
access control by range feature if you want that.