According to Travis Hassloch:
>
>I remember reading something in the Intel uprocessor book about tasks
>having a "I/O map" that could allow access to certain areas of I/O space.
>I don't remember how fine a granularity this map had (per-word?) but it
>got me thinking.
>

The granuality of the I/O permission map is on a byte level.  Each bit
in the map allows/disallows access to that I/O byte - i.e. the first
byte of the map represents the permissions for i/o addresses 0x0 to
0x7.

The only problem with the permission map is that the offset to the
permission map in the TSS is only a 16 bit number so you cannot have
the map too far away from the TSS (the book I have says the offset
cannot be more than 0xdfff).  You don't need to populate the entire
permission map, if a permission request is made for an I/O location
off the end of the table you specified in the map length field of the
TSS then the access is allowed.

>How could one allow (in an aethetically pleasing way) the Unix kernel to
>start a particular process with (or allow it to get) a particular I/O
>privilege map or a fixed virtual-to-physical mapping (to grab memory-mapped
>I/O space)?  Would an a.out field and [e]uid-check be appropriate?
>

I think a system call would be the best way - not sure if you want to
make the caller specify the entire permission map they want or have a
call that asks for a range of addresses.  Either way the thing should
check the [e]uid for root otherwise normal users could do nasty low
level type things to disk controllers and the like.

BTW If intel did not have the strange restriction on the location of
the i/o map you could do interesting things like have the I/O map
inherited from the parent but perhaps that is not such a good idea
since it could be exploited in nasty ways...

-- 
Brett Lymn, Computer Systems Administrator, AWA Defence Industries
===============================================================================
  "Upgrading your memory gives you MORE RAM!" - ad in MacWAREHOUSE catalogue.