Linux Kernel Device Identifier and /dev File System
The Device Identifier in the Linux Kernel
The kernel uses a number to identify devices on the system. The major number identifies which driver is responsible, and the minor number allows a single driver to drive multiple devices.
/dev/pda references the master IDE disk on the primary controller, while /dev/hdb refers to the slave drive. The partitions on these drives are found by adding the partition number to the minor node for that device.
Major Number
The major number is the identifier that tells the kernel what driver to call for a character device special file (/dev). In DDI and pre-DDI 8 drivers, it also separates block from character devices. The major number is not passed to the open routine of the device driver, but it does identify the type of device and the driver associated with that device.
Traditionally, the major number has been used to identify the driver for a device. For example, the /dev/null and /dev/zero devices are managed by driver 1, while the virtual consoles and serial terminals are handled by driver 4. The kernel uses this information at open time to dispatch to the appropriate function for that device.
Since modern Linux kernels are organized on a one-major-one-driver principle, the major number is important. It’s usually best to pass a pointer to the global structure of the device driver to the register_chrdev() routine, not to one local to the module’s initialization function.
Minor Number
The minor number is used by a device driver to distinguish among devices it controls. It is important for programs to be able to tell which drivers manage specific devices (e.g. /dev/zero or /dev/null are both managed by driver 1, and virtual consoles are handled by driver 4).
The kernel uses the dev_t data type (defined in
Register_chrdev uses a pointer to this structure to store the major and minor numbers, which it passes to applications when they ask for a character device file. This is important because a program that invokes register_chrdev without knowing the device major and minor number will get a different file name when it tries to open the device.
/dev/random
The /dev/random device is used to supply truly random data. It does so by drawing from the kernel’s entropy pool. This means that if the pool is depleted, reading from it will block until more entropy is available. This prevents attackers from predicting the next output of the device.
The blocking read of /dev/random is a necessary security feature. If an attacker could determine that a certain amount of data was generated at a particular time, they would be able to guess the outcome of cryptographic operations such as key generation.
On modern Linux systems, the /dev/random device no longer blocks unless the system believes it has insufficient entropy to generate random numbers. This is a result of a new syscall, introduced by OpenBSD and known as getentropy(2). The syscall is designed to estimate how much entropy the kernel has, rather than wait for it to deplete. It has replaced the old /dev/random file on Linux systems.
/dev/urandom
The /dev/urandom device is used to collect entropy from sources that are registered with the kernel-level cryptographic framework, and implement random number generation routines. An administrator can use the cryptoadm(8) utility to configure which providers are used with /dev/random. The /dev/urandom device will block reads if the available entropy is too low.
When “true” random data enters the system, it is counted and a precise counter is updated. This entropy is then passed to an internal random number generator (RNG) and then merged with the existing pool. The /dev/random device reads from the /dev/urandom pool and blocks reads when the entropy counter falls too low.
If the entropy from the /dev/urandom output is not reseeded often enough, an attacker may be able to guess at the next output in a predictable manner. With current technology, however, this attack would require exhausting the entire entropy pool and is therefore astronomically improbably. To combat this issue, it is recommended that the OS save a copy of the /dev/urandom entropy pool at power off.
…