Hi Thomas,

> Date: 2026-10-15 18:54:21+0200
> From: 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.

Thanks!  I'll keep the manual pages unchanged.


Have a lovely day!
Alex

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

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