[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Thomas Schwinge
Subject: Do we want a server on `/servers/machine' (or similar)?
Date: Wed, 9 May 2007 17:53:58 +0200
User-agent: Mutt/1.5.11


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
`io_perm_create' rpc on the server S that is residing on
`/servers/machine'.  S checks and sees that U provided some capability to
state that she's to be allowed such access.  As a proxy, S invokes
`i386_io_perm_create' on the device-master port and returns the resulting
`io_perm_t' capability P to U.  Then U can later directly invoke
`i386_io_perm_modify' on P.

What do you think?  Is this a feasible approach?


Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]