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

[Alejandro Colomar <alx@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3119 bytes --]

Hi Ingo,

> Date: 2026-10-11 20:57:00+0200
> From: 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.

Thanks!

> 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.

Yes, it'd be good to get confirmation from them.

> 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.


Have a lovely night!
Alex

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

-- 
<https://www.alejandro-colomar.es>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]