cvs commit: src/sys/dev/io iodev.c

[Robert Watson]

On Sat, 9 Aug 2008, Peter Jeremy wrote:

> On 2008-Aug-09 12:08:42 +0100, Robert Watson <rwatson at freebsd.org> wrote:
>> While /dev/io appeals to the UNIX "everything is a file" sensibility, I 
>> think the system calls we have for this on i386 are more conceptually 
>> coherent.
>
> IMO, /dev/io is inherently a kludge - it's really more a MAC issue than 
> anything like a file.  Whilst you get a FD by opening /dev/io, you never use 
> that FD for anything other than passing to close(2). Instead, you are using 
> a magic side-effect that allows you to execute 'in' and 'out' instructions 
> whilst you hold that FD open.  AFAIK, the sole reason for having it appear 
> as a file is that (in the absence of a MAC framework), the filesystem 
> provides the only mechanism for access control.  IMHO, /dev/io should be 
> deprecated in favour of something like the MAC framework.  (Note that 
> i386_{g,s}et_ioperm(2) are nor suitable in their current form because there 
> is no mechanism for the system administrator to define access controls).

Well, the MAC Framework is basically an object/method control mechanism, and 
appropriate for use with different sorts of objects and methods (we have quite 
a few).  It doesn't specify how the service is delivered, though.  What I like 
about i386_{g,s}et_ioperm(2) is that they set qualities on a process (cleared 
on exeve(2), I hope), and if we have different priv(9) privileges for them, 
they can be separately controlled.

Robert N M Watson
Computer Laboratory
University of Cambridge