[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: video mem access with oskit-mach
From: |
Marcus Brinkmann |
Subject: |
Re: video mem access with oskit-mach |
Date: |
Sun, 7 Oct 2001 19:59:42 +0200 |
User-agent: |
Mutt/1.3.22i |
On Wed, Oct 03, 2001 at 04:53:51PM -0400, Roland McGrath wrote:
> First, as to the kernel implementation issue. Adding a new IKOT_* flavor
> is not really hard, and having extra flavors for machine-specific features
> is fine by me. But I was also thinking it might just be easiest to stick
> with device_t anyway, since it has the IPC setup all dealt with already
> (and the various new bits of IKOT_* and intran/outtran magic would just
> duplicate what's there for device_t).
This sounds reasonable. It would be a dummy device with only side effects.
However, if possible, I think it makes sense to give the RPC arguments a
name different from device_t, to avoid confusion.
> Your scheme #2 makes ioperm much easier. A root ioperm caller
> could just get a capability for all ports, and then make a call saying what
> change to make to the task.
Sounds good to me.
> I don't think extracting io port capability from the task is a good thing.
> If there are RPCs for subsetting (or unioning) that can be done, they
> should be sent to the io port capability port itself (like Hurd auth handles).
The reason I included that is to make it possible for a security concerned
task to drop the permission, even if it doesn't have the privilege to create
a new object representing it. I now see in Linux that they appear to allow
this (i386/kernel/ioport.c):
if (turn_on && !capable(CAP_SYS_RAWIO))
return -EPERM;
So if you just want to turn it off, you don't need permission. However,
this is certainly a rare case, and we might not want to bother about it at
all now.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org brinkmd@debian.org
Marcus Brinkmann GNU http://www.gnu.org marcus@gnu.org
Marcus.Brinkmann@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de
- video mem and keyboard access with oskit-mach, Marcus Brinkmann, 2001/10/01
- Re: video mem access with oskit-mach, Roland McGrath, 2001/10/01
- Re: video mem access with oskit-mach, Marcus Brinkmann, 2001/10/01
- Re: video mem access with oskit-mach, Roland McGrath, 2001/10/02
- Re: video mem access with oskit-mach, Thomas Bushnell, BSG, 2001/10/02
- Re: video mem access with oskit-mach, Marcus Brinkmann, 2001/10/02
- Re: video mem access with oskit-mach, Roland McGrath, 2001/10/02
- Re: video mem access with oskit-mach, Marcus Brinkmann, 2001/10/02
- Re: video mem access with oskit-mach, Marcus Brinkmann, 2001/10/03
- Re: video mem access with oskit-mach, Roland McGrath, 2001/10/03
- Re: video mem access with oskit-mach,
Marcus Brinkmann <=
- Re: video mem access with oskit-mach, Marcus Brinkmann, 2001/10/07
- Re: video mem access with oskit-mach, Marcus Brinkmann, 2001/10/02
- Re: video mem access with oskit-mach, Marcus Brinkmann, 2001/10/02
- Re: video mem access with oskit-mach, Marcus Brinkmann, 2001/10/03
- Re: video mem access with oskit-mach, Roland McGrath, 2001/10/03
- Re: video mem access with oskit-mach, Marcus Brinkmann, 2001/10/03
- Re: video mem access with oskit-mach, Roland McGrath, 2001/10/03
- Re: video mem access with oskit-mach, Marcus Brinkmann, 2001/10/03
- Re: video mem access with oskit-mach, Roland McGrath, 2001/10/03
- Re: video mem access with oskit-mach, Roland McGrath, 2001/10/03