{
	"id": "b50afeab-7858-406c-a357-791538884bf1",
	"created_at": "2026-04-06T00:21:29.650954Z",
	"updated_at": "2026-04-10T03:20:34.588928Z",
	"deleted_at": null,
	"sha1_hash": "010c3d0c6eb407cf293f589c00912fcf0f504a9c",
	"title": "Modules vs Programs",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 65250,
	"plain_text": "Modules vs Programs\r\nArchived: 2026-04-05 13:09:54 UTC\r\n3.1.1. How modules begin and end\r\nA program usually begins with a main() function, executes a bunch of instructions and terminates upon\r\ncompletion of those instructions. Kernel modules work a bit differently. A module always begin with either the\r\ninit_module or the function you specify with module_init call. This is the entry function for modules; it tells\r\nthe kernel what functionality the module provides and sets up the kernel to run the module's functions when\r\nthey're needed. Once it does this, entry function returns and the module does nothing until the kernel wants to do\r\nsomething with the code that the module provides.\r\nAll modules end by calling either cleanup_module or the function you specify with the module_exit call. This is\r\nthe exit function for modules; it undoes whatever entry function did. It unregisters the functionality that the entry\r\nfunction registered.\r\nEvery module must have an entry function and an exit function. Since there's more than one way to specify entry\r\nand exit functions, I'll try my best to use the terms `entry function' and `exit function', but if I slip and simply refer\r\nto them as init_module and cleanup_module, I think you'll know what I mean.\r\n3.1.2. Functions available to modules\r\nProgrammers use functions they don't define all the time. A prime example of this is printf(). You use these\r\nlibrary functions which are provided by the standard C library, libc. The definitions for these functions don't\r\nactually enter your program until the linking stage, which insures that the code (for printf() for example) is\r\navailable, and fixes the call instruction to point to that code.\r\nKernel modules are different here, too. In the hello world example, you might have noticed that we used a\r\nfunction, printk() but didn't include a standard I/O library. That's because modules are object files whose\r\nsymbols get resolved upon insmod'ing. The definition for the symbols comes from the kernel itself; the only\r\nexternal functions you can use are the ones provided by the kernel. If you're curious about what symbols have\r\nbeen exported by your kernel, take a look at /proc/ksyms.\r\nOne point to keep in mind is the difference between library functions and system calls. Library functions are\r\nhigher level, run completely in user space and provide a more convenient interface for the programmer to the\r\nfunctions that do the real work---system calls. System calls run in kernel mode on the user's behalf and are\r\nprovided by the kernel itself. The library function printf() may look like a very general printing function, but all\r\nit really does is format the data into strings and write the string data using the low-level system call write(),\r\nwhich then sends the data to standard output.\r\nWould you like to see what system calls are made by printf()? It's easy! Compile the following program:\r\nhttps://tldp.org/LDP/lkmpg/2.4/html/x437.html\r\nPage 1 of 5\n\n#include \u003cstdio.h\u003e\r\n int main(void)\r\n { printf(\"hello\"); return 0; }\r\nwith gcc -Wall -o hello hello.c. Run the exectable with strace hello. Are you impressed? Every line you see\r\ncorresponds to a system call. strace[1] is a handy program that gives you details about what system calls a\r\nprogram is making, including which call is made, what its arguments are what it returns. It's an invaluable tool for\r\nfiguring out things like what files a program is trying to access. Towards the end, you'll see a line which looks like\r\nwrite(1, \"hello\", 5hello). There it is. The face behind the printf() mask. You may not be familiar with\r\nwrite, since most people use library functions for file I/O (like fopen, fputs, fclose). If that's the case, try looking at\r\nman 2 write. The 2nd man section is devoted to system calls (like kill() and read(). The 3rd man section is\r\ndevoted to library calls, which you would probably be more familiar with (like cosh() and random()).\r\nYou can even write modules to replace the kernel's system calls, which we'll do shortly. Crackers often make use\r\nof this sort of thing for backdoors or trojans, but you can write your own modules to do more benign things, like\r\nhave the kernel write Tee hee, that tickles! everytime someone tries to delete a file on your system.\r\n3.1.3. User Space vs Kernel Space\r\nA kernel is all about access to resources, whether the resource in question happens to be a video card, a hard drive\r\nor even memory. Programs often compete for the same resource. As I just saved this document, updatedb started\r\nupdating the locate database. My vim session and updatedb are both using the hard drive concurrently. The kernel\r\nneeds to keep things orderly, and not give users access to resources whenever they feel like it. To this end, a CPU\r\ncan run in different modes. Each mode gives a different level of freedom to do what you want on the system. The\r\nIntel 80386 architecture has 4 of these modes, which are called rings. Unix uses only two rings; the highest ring\r\n(ring 0, also known as `supervisor mode' where everything is allowed to happen) and the lowest ring, which is\r\ncalled `user mode'.\r\nRecall the discussion about library functions vs system calls. Typically, you use a library function in user mode.\r\nThe library function calls one or more system calls, and these system calls execute on the library function's behalf,\r\nbut do so in supervisor mode since they are part of the kernel itself. Once the system call completes its task, it\r\nreturns and execution gets transfered back to user mode.\r\n3.1.4. Name Space\r\nWhen you write a small C program, you use variables which are convenient and make sense to the reader. If, on\r\nthe other hand, you're writing routines which will be part of a bigger problem, any global variables you have are\r\npart of a community of other peoples' global variables; some of the variable names can clash. When a program has\r\nlots of global variables which aren't meaningful enough to be distinguished, you get namespace pollution. In large\r\nprojects, effort must be made to remember reserved names, and to find ways to develop a scheme for naming\r\nunique variable names and symbols.\r\nhttps://tldp.org/LDP/lkmpg/2.4/html/x437.html\r\nPage 2 of 5\n\nWhen writing kernel code, even the smallest module will be linked against the entire kernel, so this is definitely an\r\nissue. The best way to deal with this is to declare all your variables as static and to use a well-defined prefix for\r\nyour symbols. By convention, all kernel prefixes are lowercase. If you don't want to declare everything as static,\r\nanother option is to declare a symbol table and register it with a kernel. We'll get to this later.\r\nThe file /proc/ksyms holds all the symbols that the kernel knows about and which are therefore accessible to\r\nyour modules since they share the kernel's codespace.\r\n3.1.5. Code space\r\nMemory management is a very complicated subject---the majority of O'Reilly's `Understanding The Linux Kernel'\r\nis just on memory management! We're not setting out to be experts on memory managements, but we do need to\r\nknow a couple of facts to even begin worrying about writing real modules.\r\nIf you haven't thought about what a segfault really means, you may be surprised to hear that pointers don't actually\r\npoint to memory locations. Not real ones, anyway. When a process is created, the kernel sets aside a portion of\r\nreal physical memory and hands it to the process to use for its executing code, variables, stack, heap and other\r\nthings which a computer scientist would know about[2]. This memory begins with $0$ and extends up to whatever\r\nit needs to be. Since the memory space for any two processes don't overlap, every process that can access a\r\nmemory address, say 0xbffff978, would be accessing a different location in real physical memory! The processes\r\nwould be accessing an index named 0xbffff978 which points to some kind of offset into the region of memory\r\nset aside for that particular process. For the most part, a process like our Hello, World program can't access the\r\nspace of another process, although there are ways which we'll talk about later.\r\nThe kernel has its own space of memory as well. Since a module is code which can be dynamically inserted and\r\nremoved in the kernel (as opposed to a semi-autonomous object), it shares the kernel's codespace rather than\r\nhaving its own. Therefore, if your module segfaults, the kernel segfaults. And if you start writing over data\r\nbecause of an off-by-one error, then you're trampling on kernel code. This is even worse than it sounds, so try your\r\nbest to be careful.\r\nBy the way, I would like to point out that the above discussion is true for any operating system which uses a\r\nmonolithic kernel[3]. There are things called microkernels which have modules which get their own codespace.\r\nThe GNU Hurd and QNX Neutrino are two examples of a microkernel.\r\n3.1.6. Device Drivers\r\nOne class of module is the device driver, which provides functionality for hardware like a TV card or a serial port.\r\nOn unix, each piece of hardware is represented by a file located in /dev named a device file which provides the\r\nmeans to communicate with the hardware. The device driver provides the communication on behalf of a user\r\nprogram. So the es1370.o sound card device driver might connect the /dev/sound device file to the Ensoniq\r\nIS1370 sound card. A userspace program like mp3blaster can use /dev/sound without ever knowing what kind of\r\nsound card is installed.\r\n3.1.6.1. Major and Minor Numbers\r\nhttps://tldp.org/LDP/lkmpg/2.4/html/x437.html\r\nPage 3 of 5\n\nLet's look at some device files. Here are device files which represent the first three partitions on the primary\r\nmaster IDE hard drive:\r\n # ls -l /dev/hda[1-3]\r\n brw-rw---- 1 root disk 3, 1 Jul 5 2000 /dev/hda1\r\n brw-rw---- 1 root disk 3, 2 Jul 5 2000 /dev/hda2\r\n brw-rw---- 1 root disk 3, 3 Jul 5 2000 /dev/hda3\r\nNotice the column of numbers separated by a comma? The first number is called the device's major number. The\r\nsecond number is the minor number. The major number tells you which driver is used to access the hardware.\r\nEach driver is assigned a unique major number; all device files with the same major number are controlled by the\r\nsame driver. All the above major numbers are 3, because they're all controlled by the same driver.\r\nThe minor number is used by the driver to distinguish between the various hardware it controls. Returning to the\r\nexample above, although all three devices are handled by the same driver they have unique minor numbers\r\nbecause the driver sees them as being different pieces of hardware.\r\nDevices are divided into two types: character devices and block devices. The difference is that block devices have\r\na buffer for requests, so they can choose the best order in which to respond to the requests. This is important in the\r\ncase of storage devices, where it's faster to read or write sectors which are close to each other, rather than those\r\nwhich are further apart. Another difference is that block devices can only accept input and return output in blocks\r\n(whose size can vary according to the device), whereas character devices are allowed to use as many or as few\r\nbytes as they like. Most devices in the world are character, because they don't need this type of buffering, and they\r\ndon't operate with a fixed block size. You can tell whether a device file is for a block device or a character device\r\nby looking at the first character in the output of ls -l. If it's `b' then it's a block device, and if it's `c' then it's a\r\ncharacter device. The devices you see above are block devices. Here are some character devices (the serial ports):\r\n crw-rw---- 1 root dial 4, 64 Feb 18 23:34 /dev/ttyS0\r\n crw-r----- 1 root dial 4, 65 Nov 17 10:26 /dev/ttyS1\r\n crw-rw---- 1 root dial 4, 66 Jul 5 2000 /dev/ttyS2\r\n crw-rw---- 1 root dial 4, 67 Jul 5 2000 /dev/ttyS3\r\nIf you want to see which major numbers have been assigned, you can look at\r\n/usr/src/linux/Documentation/devices.txt.\r\nWhen the system was installed, all of those device files were created by the mknod command. To create a new\r\nchar device named `coffee' with major/minor number 12 and 2, simply do mknod /dev/coffee c 12 2. You don't\r\nhave to put your device files into /dev, but it's done by convention. Linus put his device files in /dev, and so\r\nshould you. However, when creating a device file for testing purposes, it's probably OK to place it in your\r\nworking directory where you compile the kernel module. Just be sure to put it in the right place when you're done\r\nwriting the device driver.\r\nhttps://tldp.org/LDP/lkmpg/2.4/html/x437.html\r\nPage 4 of 5\n\nI would like to make a few last points which are implicit from the above discussion, but I'd like to make them\r\nexplicit just in case. When a device file is accessed, the kernel uses the major number of the file to determine\r\nwhich driver should be used to handle the access. This means that the kernel doesn't really need to use or even\r\nknow about the minor number. The driver itself is the only thing that cares about the minor number. It uses the\r\nminor number to distinguish between different pieces of hardware.\r\nBy the way, when I say `hardware', I mean something a bit more abstract than a PCI card that you can hold in your\r\nhand. Look at these two device files:\r\n % ls -l /dev/fd0 /dev/fd0u1680\r\n brwxrwxrwx 1 root floppy 2, 0 Jul 5 2000 /dev/fd0\r\n brw-rw---- 1 root floppy 2, 44 Jul 5 2000 /dev/fd0u1680\r\nBy now you can look at these two device files and know instantly that they are block devices and are handled by\r\nsame driver (block major 2). You might even be aware that these both represent your floppy drive, even if you\r\nonly have one floppy drive. Why two files? One represents the floppy drive with 1.44 MB of storage. The other is\r\nthe same floppy drive with 1.68 MB of storage, and corresponds to what some people call a `superformatted' disk.\r\nOne that holds more data than a standard formatted floppy. So here's a case where two device files with different\r\nminor number actually represent the same piece of physical hardware. So just be aware that the word `hardware' in\r\nour discussion can mean something very abstract.\r\nSource: https://tldp.org/LDP/lkmpg/2.4/html/x437.html\r\nhttps://tldp.org/LDP/lkmpg/2.4/html/x437.html\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://tldp.org/LDP/lkmpg/2.4/html/x437.html"
	],
	"report_names": [
		"x437.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434889,
	"ts_updated_at": 1775791234,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/010c3d0c6eb407cf293f589c00912fcf0f504a9c.pdf",
		"text": "https://archive.orkl.eu/010c3d0c6eb407cf293f589c00912fcf0f504a9c.txt",
		"img": "https://archive.orkl.eu/010c3d0c6eb407cf293f589c00912fcf0f504a9c.jpg"
	}
}