Save access to i/o ports (2024)

Hi,

FlashBurn wrote:I know how to protect the i/o ports, but I need a way of doing it fast and w/o much memory overhead.

"Fast" comes in 3 flavours - fast access to IO ports for device drivers, fast allocation/deallocation of IO ports and making the OS as a whole run fast by reducing overheads elsewhere. There's also differences in how much protection you want to provide. Using the methods listed by Gaf:

* IOPL-bit in the EFLAGS (hardware)

This method uses no CPU time and doesn't use any memory either. The compromise is that you have to give device drivers access to all IO ports, and either run drivers at CPL = 0 (IOPL = 0), use three different privelege levels (IOPL = 1 or 2) or just give all software access to all IO ports (IOPL = 3). The side effect here is that it also controls CLI and STI, which may or may not be desirable.

* I/O-Bitmap in the TSS (hardware)

This method doesn't use any CPU time when drivers access IO ports. If you're using software task switching then you need to adjust the TSS during each task switch, which adds a little overhead to every task switch. If you're using hardware task switching then IMHO you shouldn't be too concerned with speed anyway. With the IO permission bitmaps alone the kernel's code to allocate an IO port would need to scan the IO permission bitmap for every task to find out if an IO port is in use or not. This can be made faster by maintaining a global bitmap that determines if each IO port is allocated or free (it'd take an extra 8 Kb). Either way this method does provide per port protection.

* Software I - GPF emulation

This is the same as Software II (see the notes there) apart from using the general protection handler instead of system calls. The speed of the GPF handler is several cycles slower than a software interrupt (call gates, syscall, sysenter are usually even better). The part I like is that device drivers can use the IO instructions without caring if they are emulated or not, which also means that the kernel can disable all IO port protection by setting IOPL to 3 (for people who don't care and just want speed, or perhaps after everything has run without problems for several hours).

* Software II - System calls

This method (and Sofware I) uses the most CPU time when an IO port is accessed but offers the best IO port protection possible (if you want it) - per bit protection. One example would be the keyboard controller chip, where you want the keyboard driver to have access to everything except for the bits that control the A20 gate and system reset.

The easiest way to implement this is with a table, one entry for each IO port. The size of the entry depends on how many threads your OS supports (or processes depending on what owns the IO port), but for alignment purposes it'd be either 128 Kb or 256 Kb (for 16 bit or 32 bit entries). The memory actually used by this table will be more like 32 Kb or 64 Kb if unused pages aren't mapped.

FlashBurn wrote:@brendan
This would be also a good way, but then you have to scan through the table when a thread or task is killed. Also I think that a task-based i/o port protection is enough! I think that the task should also have to do some work for itsself

The OS can keep track of the number of IO ports each thread owns and expect the threads to free any IO ports itself before terminating so that the IO owner table doesn't normally need to be checked at all. If the driver is killed without notice (ie. crashed) the kernel needs to check through the IO owner table, but can stop looking once the right number of IO ports have been found (it wouldn't need to scan the entire table). Hopefully device drivers won't crash often

Cheers,

Brendan