[Top][All Lists]

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

Re: I/O permission control in OSKit-Mach

From: Thomas Schwinge
Subject: Re: I/O permission control in OSKit-Mach
Date: Mon, 2 Apr 2007 14:08:57 +0200
User-agent: Mutt/1.5.11


Since it's been six and a half years, let me first give some context

On Tue, Oct 16, 2001 at 04:16:42AM +0200, Marcus Brinkmann wrote:
> here is a patch to implement I/O permission control in OSKit-Mach.
> What do you get?
> ----------------
> Two new interfaces:
> /* Request a new port IO_PERM that represents the capability to access
>    the I/O ports [FROM; TO] directly.  MASTER_PORT is the master device port.
>    The function returns KERN_INVALID_ARGUMENT if TARGET_TASK is not a task,
>    or FROM is greater than TO.  */
> routine       i386_io_perm_create(
>               master_port     : mach_port_t;
>               from            : io_port_t;
>               to              : io_port_t;
>       out     io_perm         : io_perm_t);
> /* Modify the I/O permissions for TARGET_TASK.  If ENABLE is TRUE, the
>    permission to acces the I/O ports specified by IO_PERM is granted,
>    otherwise it is withdrawn.
>    The function returns KERN_INVALID_ARGUMENT if TARGET_TASK is not a valid
>    task or IO_PERM not a valid I/O permission port.  */
> routine i386_io_perm_modify(
>               target_task     : task_t;
>               io_perm         : io_perm_t;
>               enable          : boolean_t);
> The usage should be pretty obvious, an example follow below.  The
> capability port can be destroyed after the I/O permissions have been
> modified.
> What features are provided?
> ---------------------------
> I/O permissions are task based, rather than thread based.  All threads will
> get permission instantly.
> The io_perm_t ports represent the capability to control the permission to
> access I/O ports.  A server running as root could hand out permission to
> access linear port ranges for specific purposes to non-root users (like
> console users to program the console).
> Applications accessing I/O ports written for GNU/Linux will be able to compile
> on the Hurd without changes, as soon as glibc is extended to cover the new
> interfaces (see below).
> The task switching mechanism will only use one TSS for processors.  I/O
> permission bit maps are edited in place.

Finally, I'm now about to backport the above i/o permission interface to
the gnumach-1-branch.

> GNU Mach
> --------
> For GNU Mach, a kernel object would be necessary, so that a no senders
> notification can be sent and the capability be destroyed.  No magic, but
> annoying because it would be a bit different from the OSKit Mach
> implementation (nothing visible to the outside).  I don't plan to "backport"
> this change to GNU Mach currently, as it seems a usable OSKit Mach (with
> user space console) is coming along nicely.

The code in `[OSKit-Mach]/i386/i386/io_perm.c' makes use of the
OSKit-Mach specific ``struct device_ops'' (from
`[OSKit-Mach]/oskit/ds_oskit.h'), the ``COM object'' stuff in ``struct
device'' and so on.  What's the best way (or at least a feasible way) to
handle that in the gnumach-1-branch?


Attachment: signature.asc
Description: Digital signature

reply via email to

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