A Quick Look Around the Kernel

I'd like to introduce the kernel. If this is the first time you've met, say hello and treat it nicely. The kernel is the piece of software responsible for talking to the hardware and creating the background environment within which programs are run. You usually don't encounter the kernel until you have to load hardware or need to recompile it for additional features or security updates. Most Linux vendors now include modular kernels along with their regular updates, thus greatly reducing the number of people who compile their own kernel, or roll their own kernel as it is sometimes called.

What'd You Call That?

Before I go too far, I should get some terms out of the way in relation to the kernel. First is differentiation between the various kernels now available. Because Linux is open source and free (as in free speech), numerous forks and customizations have taken place on the kernel. Some of these are discussed a bit later, but for now take my word that multiple versions of the kernel exist. When you hear someone refer to a "stock" or "vanilla" kernel, they are (or should be) referring to the official kernel source code available from http://www.kernel.org/. These kernels are named as such because they come from the official Linus Torvaldsbased Linux kernel implementation.

Stock or vanilla kernels are in contrast to customized or distribution-specific kernels released by some Linux vendors. You'll hear the vendors refer to the kernels as "enhanced" or some other marketing-type term. These vendors usually add functionality to the kernel, thus making it custom to that distribution. One example of this is the Advanced Server released by Red Hat, which includes some Red Hatspecific additions to the kernel. Although these additions provide some functionality for specific needs, they also create a problem for those of us who want to add security or otherwise customize the kernel. Further, the updates to those distribution-specific kernels frequently lag behind the vanilla kernel, which leaves users of those distribution-specific kernels vulnerable to attack for longer than they should be.

What's Your Number?

Version numbering of kernels can be confusing to those new to the kernel. This fact is multiplied by the use of distribution-specific kernels and their own naming and numbering conventions. This section briefly examines the version numbering involved in Linux kernels.

Kernel numbering consists of three numbers separated by a dot, as in 2.6.4. In this numbering scheme the initial 2.6 indicates the major version number, and the final .4 indicates the minor version number. Major changes to the kernel are usually encompassed within the major version number, 2.0, 2.2, 2.4, 2.6, and so on. As you can see, the second digit within the kernel version number consists only of even-numbered integers. Kernel versions declared "stable" are given even-numbered second digits. For example, the development version of the kernel known as 2.3.N was eventually released as 2.4.0, and the development version known as 2.5.N was eventually released as 2.6.0. Work continues on the 2.7.N branch, which will eventually be released as 2.8.0. It's important to note that only the second number connotes the type of release, development (odd) or stable (even).

The final number is the minor release, beginning with 0 and continuing on as minor bug fixes and driver additions are released for the stock kernel. This last number can be either even or odd, and neither indicates any special type of kernel.

Kernels are also sometimes given an RC status to indicate that they are a Release Candidate. The number will resemble something like 2.6.5-rc2 or 2.6.8-rc3. As with the development releases of the kernel, these release candidates aren't meant for general use but rather are for testing purposes.

The Kernel: From 20,000 Feet

The kernel is really a bunch of source-code files written in C (mostly). You choose the stuff you want to include within the kernel, such as drivers and other functionality, and then you compile it. The kernel is modular, which means that pieces of its functionality can be loaded on demand. This is helpful for desktop-type systems in which you might need the USB driver only when a USB device is plugged in. A modular kernel is less useful (and can be harmful) from a security standpoint.

The act of compiling the kernel consists of a few steps, the first of which is obtaining the source code itself. Beyond that, you unarchive the source and run a command to help you select which drivers and functionality to include in the kernel. From there you build the kernel and then install it.

The de facto location for kernel source code is in /usr/src/linux. The kernel, as source code, includes a few main variations for selecting the options to include within the kernel. These options are all accessed with the make command; two of them are appropriate from the command line, whereas one is used for X Windows kernel compiles. For this discussion I'll be concentrating on the methods available from the command line. Don't worry about following along in this section; there will be plenty of time for that later. For now I'll give a high-level overview of the kernel.

The primary (and easiest) method for selecting kernel compile options from the command line is with this command:

 make menuconfig 

Running that command from the kernel source directory results in the kernel configuration interface running, as shown in Figure 13.1.

Figure 13.1. The kernel configuration interface is used to configure options to include with the kernel in Linux.

As you can see from Figure 13.1, there are quite a few options within the kernel. The configuration is such that the options are organized hierarchically, so there could be multiple levels within each of the options shown in Figure 13.1.

Probably the biggest hurdle when compiling a kernel for the first time on a new computer, whether you're experienced or not, is knowing exactly what to include within the compile. Much of the process involves finding the hardware that the computer uses and determining which driver to include for that hardware. At the end of the day, some of the process of compiling a kernel comes down to guesswork, some educated guesses, some not. Good troubleshooting techniques and trial and error both play a part in a kernel compile. These are fine when you're at the console but much less fun when you're 1,000 miles away from the computer.