IO(4)

💖 IO(4) — io, the I/O privilege file 💖

ok bestie so this is a page from the Kernel Interfaces Manual, section 4, and it's all about io, aka the I/O privilege file. buckle up 🎀

✨ NAME ✨

io — I/O privilege file 🫶

🌸 SYNOPSIS 🌸

device io

#include <sys/types.h>
#include <sys/ioctl.h>
#include <dev/io/iodev.h>
#include <machine/iodev.h>

struct iodev_pio_req {
        u_int access;
        u_int port;
        u_int width;
        u_int val;
};

🦋 DESCRIPTION 🦋

okay so the special file /dev/io is, and I quote, a controlled security hole 💀 — it lets a process gain I/O privileges, which are normally reserved for kernel-internal code only. and like, why would anyone want that? because it's genuinely useful for writing userland programs that handle some hardware directly. main character behaviour, honestly 👑

the usual operations on the device are: open it via the open(2) interface, then send I/O requests to the file descriptor using the ioctl(2) syscall. that's the whole vibe.

the ioctl(2) requests available for /dev/io are mostly platform dependent, but there are also some in common between all of them. IODEV_PIO is used by all the architectures in order to request that an I/O operation be performed. it takes a 'struct iodev_pio_req' argument that must be previously setup. no setup, no slay.

the access member specifies the type of operation requested. it may be:

• IODEV_PIO_READ — the operation is an "in" type. a value will be read from the specified port (retrieved from the port member) and the result will be stored in the val member. it's giving "bringing the data home" ✨
• IODEV_PIO_WRITE — the operation is a "out" type. the value will be fetched from the val member and will be written out to the specified port (defined as the port member). bye bestie, off it goes 💅

finally, the width member specifies the size of the operand to be read/written, expressed in bytes. measure twice, read once, iykyk 📏

ok so real talk: in addition to any file access permissions on /dev/io, the kernel enforces that only the super-user may open this device. so like, don't get cute unless you're root 🙈

🎀 LEGACY 🎀

not me bringing up the past but… the /dev/io interface used to be very i386 specific and worked differently. the initial implementation simply raised the IOPL of the current thread when open(2) was called on the device. this behaviour is retained in the current implementation as legacy support for both i386 and amd64 architectures. so it's like, old money but still on the guest list 🧚

⭐ SEE ALSO ⭐

• close(2)
• i386_get_ioperm(2)
• i386_set_ioperm(2)
• ioctl(2)
• open(2)
• mem(4)

🌈 HISTORY 🌈

the io file appeared in FreeBSD 1.0. an icon, a legend, the moment 🫶

and that's the whole page bestie, no notes 💜 this one came from Debian and it's dated June 1, 2010 — yeah she's got some years on her and she still ate 🔥

IO(4) out, mwah 💋