[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 |
Hello!
Since it's been six and a half years, let me first give some context
here...
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?
Regards,
Thomas
signature.asc
Description: Digital signature
- Re: I/O permission control in OSKit-Mach,
Thomas Schwinge <=
- Re: I/O permission control in OSKit-Mach, Roland McGrath, 2007/04/02
- Re: I/O permission control in OSKit-Mach, Thomas Schwinge, 2007/04/08
- Re: I/O permission control in OSKit-Mach, Thomas Schwinge, 2007/04/11
- Re: I/O permission control in OSKit-Mach, Thomas Schwinge, 2007/04/24
- Re: I/O permission control in OSKit-Mach, Richard Braun, 2007/04/24
- Re: I/O permission control in OSKit-Mach, Thomas Schwinge, 2007/04/25
- Patch for i/o permission control in GNU Mach (was: I/O permission control in OSKit-Mach), Thomas Schwinge, 2007/04/25