bug-hurd
[Top][All Lists]
Advanced

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

Re: Gnumach and I/O


From: Roland McGrath
Subject: Re: Gnumach and I/O
Date: Fri, 10 Mar 2006 16:04:05 -0800 (PST)

> Then why splitting ioperm()'s work into two i386_io_perm_create()
> and i386_io_perm_modify() calls if people should use ioperm()
> rather than Mach calls? Couldn't gnumach just provide an
> i386_io_perm_modify(ipc_port_t master_port, io_port_t from,
> io_port_t to, boolean_t enable) call instead of the current two fancy
> calls? (I'm ready to write a patch for this)

My memory on this is as dim as usual, so I am mostly making up new
rationale on the spot.  For one thing, I suspect I wanted to have a
somewhat "Machish" interface rather than essentially an RPC veneer on an
ioperm system call, on principle.  More concretely, it separates the
general permission from the specific permission, making the latter a
transferrable capability, which is the Mach and Hurd style of doing things.
Similarly, we use privileged servers like storeio to do device_open, and
pass only the particular device ports to other servers in the system (at
least it's possible to do it this way, i.e. have only the
storeio-translated nodes be root, and have filesystems et al run without
special privilege other than being allowed by storeio to get that device
port).  I probably had in mind then, and certainly do now, the possibility
of using some privileged server to call i386_io_perm_create and pass out
the specific io port capabilities according to its own authorization
policies.  For the ioperm interface in libc, this has to be a single
central server, /dev/ioperm or suchlike.  Still, that translator could
implement a complicated ACL scheme for particular io ports, or at least
exclusive use protection, or whatever.  Native Hurdish things written to
want io port access (e.g. the display and keyboard stuff), might use a
different privileged translator in a more specific way.  The general point
being what I said above, getting the privilege to use particular io ports
is a capability that has to come from the ultimate source of privilege, and
applying that capability to mean something on the hardware is a separable act.


Thanks,
Roland




reply via email to

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