What is a Device Driver?

• device-specific portion of the OS
• ideally should be policy-free
  • support both synchronous & asynchronous operation
  • allow multiple (concurrent) opens
  • export the full capabilities of the hardware
  • no extra software layers to "simplify things"

How is the Kernel Organized?

What are Kernel Modules?

• allow code to be added to the kernel, dynamically
• only those modules that are needed are loaded
• reduces kernel size
• enables independent development of drivers for different devices
• insmod does insertion
• rmmod does removal
• lsmod tells what modules are currently loaded

How do insmod and rmmod work?

Classes of Devices and Modules

• char modules
• block modules
• network modules
• others

Char Devices

• abstraction: stream of bytes
• support: open, close, read, write
• archetypal examples: /dev/console, /dev/ttyS0
• oddball example: frame grabbers

Block Devices

• abstraction: array of storage blocks
• support similar API operations to char modules
• difference is internal to the kernel
• archetypal examples: /dev/hda, /dev/cdrom
• additional operation: mount
(hosting a filesystem)

Network Devices

• abstraction: data packets
• support API for sending and receiving packets
• support multiple protocols and streams on one device
• archetypal example: eth0.
• Note: Network devices usually have no corresponding file system representation in Linux. E.g. you won't find a /dev/eth0 entry in th efile system.

Other Classes of Devices

Examples that don't fit in any of the above categories:

• USB
• SCSI
• FireWire
• I2O

Filesystem Modules

• Are software drivers
• Are not device drivers
• Serve as a layer between user API and block devices
• Are intended to be device-independent

Security Issues

• security has two faces: deliberate vs. incidental damage
• kernel modules present possibilities for both of the above
• system only does some rudimentary checks at module load time
• relies mainly on limiting privilege to load modules
• and trusts the driver writer(s)
• writer of driver must be on guard for security problems

Security Issues for Driver Writers

• don't define policies
• provide mechanisms to enforce security policies
• look out for ways in which driver action may affect global resources or users besides the one requesting service
• beware of bugs (e.g., buffer overflow, unchecked parameters) in driver code
• treat input/parameters from user processes with "utmost suspicion"
• initialize (or zero) memory before exporting access to it
• implement protection for critical operations ( reloading firmware, formatting a disk, etc.)

Version Numbering

• kernel components have interdependences
• keeping track of what works with what is difficult, can easily become a nightmare, requires discipline
• seek to minimize interdependences in designing modules
• use version numbers as necessary to code for dependences
• Linux kernel version numbers: major.minor.release (e.g. 2.6.11)
• Ideal drivers should be backward compatible with all versions.
• Odd numbered minor versions are for developers only. Even numbers are supposed to be stable enough for general use.
• The text and this course is based on version 2.6.11+.

GPL

• Gnu General Public License
• basis for all of the Gnu development, includilng Linux
• allows users to modify software as they see the need
• requires source code be distributed with binaries
• "infects" transitively through modification and distribution by multiple parties
• device drivers need not be licensed under the GPL, but the mainstream ones are