Re: Suggestions for an improvement to the man page "iopl - change I/O privilege level".

[Ingo Schwarze <schwarze@usta.de>]

Hello,

i'm answering here because Alejandro is asking me directly.
However, please take my comments with a grain of salt because
this whole topic is far out of my comfort zone, and i have
never worked on low-level hardware support.

My naive impression is that all the mentioned functions are entirely
anachronistic.  If Daniel is correct that these functions are
intended to provide mechanisms "to allow user programs to directly
communicate with hardware through I/O ports" then i suspect that
goal as a whole is completely misguided and opposed to what the
point of having any operating system at all is in the first place:
controlling hardware access and making sure that userland *cannot*
directly manipulate hardware.

I searched the entire source code of the OpenBSD operating system,
both kernel and userland, and failed to find anything that uses
these functions.  In the Xenocara tree, which contains the X11
implementation used by OpenBSD, there is one reference in a highly
obscure driver, vmmouse(4) = VMware Mouse input driver, but
looking at /usr/X11R6/lib/modules/input/vmmouse_drv.so, i do not
see it actually used, so i suspect it is disabled by the configure
script.  There is another reference in xfree86/os-support/bsd/i386_video.c,
but it's only conditionally compiled, so it seems likely that is also
disabled.  Admittedly, searching very large codebases like this
is not trivial, so i might have overlooked something.

To summarize, i cannot say why OpenBSD retained i386_iopl(2)
and amd64_iopl(2).  It seems possible to me it was an accident,
and deleting it was merely forgotten.  Looking through the
entire commit history of these functions, my impression is
that since these functions were first provided in OpenBSD
almost exactly 31 years ago, exactly one persion ever changed
anything substantial with respect to them, and that single
change happened in 1998.  Such a low level of activity often
occurs when the functionality in question is obsolete and unused.

If you think that would be helpful, i could ask around inside the
OpenBSD developer community whether i386_iopl(2) and amd64_iopl(2)
should be deleted, or whether they still serve any purpose, and if
so, which purpose, and report back to you.

One thing is abundantly clear: in normal multi-user operation,
amd64_iopl(2) cannot be used on OpenBSD because OpenBSD runs
with securelevel(7) = 1 by default and because OpenBSD runs
with sysctl(8) machdep.allowaperture=0 by default, and i don't
recall ever needing allowaperture for anything for more than
a decade now.

Yours,
  Ingo

-- 
Ingo Schwarze             <schwarze@usta.de>
http://www.openbsd.org/   <schwarze@openbsd.org>
http://mandoc.bsd.lv/     <schwarze@mandoc.bsd.lv>