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

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

[Alejandro Colomar]

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

Hi Daniël,

> Date: 2026-08-11 14:41:07+0000
> From: Daniël Hörchner <dbjh@gmx.net>
>

The mailing list doesn't accept HTML mail.  Would you mind resending in
plain text?

Also, please CC the people who were involved in the current text, as
they might be interested in discussing the proposed improvements.

I've added them in CC in this mail.

	Cc: <victorm007@yahoo.com>
	Cc: Thomas Piekarski <t.piekarski@deloquencia.de>


Have a lovely day!
Alex

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

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

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

[Alejandro Colomar]

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

Hi Daniël,

I'm replying with the mailing list in CC.  This will transform the
message into plain text.


Have a lovely night!
Alex

> Date: 2026-08-11 17:19:31+0000
> From: Daniël Hörchner <dbjh@gmx.net>
>

> Hello,
> 
> 
> I have some feedback and suggestions to improve the man page of
> "iopl - change I/O privilege level".
>  
> The purpose of iopl() is not clearly explained. iopl() is a
> straightforward way to allow direct access to all I/O ports from
> user mode, when it is passed the argument 3. In practice, it is
> always passed the argument 3.
>  
> The description ends with the following paragraph:
> "This call is deprecated, is significantly slower than ioperm(2),
> and is only provided for older X servers which require access to
> all 65536 I/O ports.  It is mostly for the i386 architecture.  On
> many other architectures it does not exist or will always return
> an error."
>  
> The (dubious) claim that iopl() is slower than ioperm() is
> completeley irrelevant, as the most common use case involves
> calling iopl() or ioperm() once during program initialization.
>  
> Compared to iopl(), ioperm() is more restrictive. In the past
> NetBSD, FreeBSD, OpenBSD and DragonFly BSD provided analogous
> implementations in the form of i386_set_ioperm(). OpenBSD/x86_64
> provided amd64_set_ioperm(). They served the same purpose as
> ioperm() on Linux/x86{_64}, i.e. controlling access to specific
> I/O ports.
> However, as far as I can tell, all mentioned BSDs have dropped
> that functionality, but NetBSD and OpenBSD retained their version
> of iopl(): i386_iopl(), x86_64_iopl() (NetBSD/x86_64) and
> amd64_iopl() (OpenBSD/x86_64). FreeBSD and DragonFly BSD set the
> IOPL of the relevant process to 3 in the kernel, when the process
> successfully opens /dev/io.
> In other words, the BSD projects all preferred to drop their
> versions of ioperm() in favor of continuing to provide user
> programs a way to change the IOPL. It is interesting and perhaps
> noteworthy that the Linux project appears to head in the opposite
> direction.
>  
> As I stated above the purpose of iopl() goes beyond providing
> access only to older X servers. It is a mechanism to allow user
> programs to directly communicate with hardware through I/O ports.
> Whether this functionality is sufficient for modern hardware is
> outside the scope of describing iopl().
>  
> Kind regards,
> Daniël Hörchner

> Hi Alex,
> 
> Thank you for your quick reply. I am taken aback that HTML e-mail
> is still this insurmountable technological hurdle. I have not
> used local (non browser based) e-mail clients in 9 years. I
> cannot justify the time to set up a proper e-mail client right
> now, just to send a plain text e-mail. I am sorry and apologize
> if you are unable to read this message. I have attached a copy as
> text file (e-mail.txt). I have also attached the original e-mail
> as text file (iopl-manpage-feedback.txt).
> 
> Kind regards,
> Daniël Hörchner


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

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

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

[Alejandro Colomar]

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

[TO += Ingo and tlgx]

Hi Daniël, Thomas, Ingo,

> > Date: 2026-08-11 17:19:31+0000
> > From: Daniël Hörchner <dbjh@gmx.net>
> >
> 
> > Hello,
> > 
> > 
> > I have some feedback and suggestions to improve the man page of
> > "iopl - change I/O privilege level".
> >  
> > The purpose of iopl() is not clearly explained. iopl() is a
> > straightforward way to allow direct access to all I/O ports from
> > user mode, when it is passed the argument 3. In practice, it is
> > always passed the argument 3.
> >  
> > The description ends with the following paragraph:
> > "This call is deprecated, is significantly slower than ioperm(2),
> > and is only provided for older X servers which require access to
> > all 65536 I/O ports.  It is mostly for the i386 architecture.  On
> > many other architectures it does not exist or will always return
> > an error."
> >  
> > The (dubious) claim that iopl() is slower than ioperm() is
> > completeley irrelevant, as the most common use case involves
> > calling iopl() or ioperm() once during program initialization.
> >  
> > Compared to iopl(), ioperm() is more restrictive. In the past
> > NetBSD, FreeBSD, OpenBSD and DragonFly BSD provided analogous
> > implementations in the form of i386_set_ioperm(). OpenBSD/x86_64
> > provided amd64_set_ioperm(). They served the same purpose as
> > ioperm() on Linux/x86{_64}, i.e. controlling access to specific
> > I/O ports.
> > However, as far as I can tell, all mentioned BSDs have dropped
> > that functionality, but NetBSD and OpenBSD retained their version
> > of iopl(): i386_iopl(), x86_64_iopl() (NetBSD/x86_64) and
> > amd64_iopl() (OpenBSD/x86_64). FreeBSD and DragonFly BSD set the
> > IOPL of the relevant process to 3 in the kernel, when the process
> > successfully opens /dev/io.
> > In other words, the BSD projects all preferred to drop their
> > versions of ioperm() in favor of continuing to provide user
> > programs a way to change the IOPL. It is interesting and perhaps
> > noteworthy that the Linux project appears to head in the opposite
> > direction.

Ingo, Thomas, do you have any comments from the OpenBSD and Linux sides?

> > As I stated above the purpose of iopl() goes beyond providing
> > access only to older X servers. It is a mechanism to allow user
> > programs to directly communicate with hardware through I/O ports.
> > Whether this functionality is sufficient for modern hardware is
> > outside the scope of describing iopl().

Thanks for the report.  Do you have any specific wording you'd like to
change?

> > Kind regards,
> > Daniël Hörchner


Have a lovely night!
Alex

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

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

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

[Ingo Schwarze]

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>

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

[Alejandro Colomar]

[-- 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 --]