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

[Thomas Gleixner <tglx@kernel.org>]

On Sun, Oct 11 2026 at 19:26, Alejandro Colomar wrote:
>> > 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?

The 'iopl() is slower' comment is just voodoo as it really does not
matter whether a syscall at setup time takes a bit longer or not. But
30+ years ago syscall performance bragging was part of the game :)

Though the difference between iopl() and ioperm() is not only that
ioperm() provides a more granular control than iopl() over the I/O ports
which can be accessed.

Up to Linux 5.4 iopl() was implemented using the IOPL bits in
EFLAGS. Setting them to '3' allows user space to access not only all I/O
ports via IN/INS/OUT/OUTS, but also allows user space to use CLI/STI.

ioperm() was there first (as of Linux 0.96). It allows not only to have
more granular control over the accessible IO ports but also avoids the
CLI/STI enablement.

iopl() followed in 0.97 and was deprecated after we changed the iopl()
implementation in 5.5 to utilize the IOPERM bitmap, which effectively
prevents the usage of CLI/STI in user space. Ancient X-Servers used to
utilize CLI/STI in user space for serialization, but that code has long
reached the ugly code museum.

Aside of the syscalls the permission bitmap can also be changed via
X86 specific VT IOCTLs.

In all cases the caller must have RAWIO capabilities. The syscalls and
the IOCTLs can be disabled at compile time and the security framework
can lock them down, i.e. disable them.

So in pratice these syscalls and IOCTLs are ancient ballast and any
modern distro should not need them anymore.

Though at least in the enterprise world there have been binary only
vendor "value add" programs which depended on them. At least that was the
case seven years ago.

But as kernels might have the syscalls disabled or security measures
make them unacessible at runtime, these syscalls and IOCTLs might be
indeed just nostalgia.

My personal preference would be to just delete them, but if there is a
legitimate use case then I prefer to have ioperm() as that allows at
least fine granular permission checks via the syscall security controls
instead of having the binary all or nothing iopl() mechanism.

Thanks,

        tglx