6.2. Compiling the Linux Kernel
There is a specific order to getting your kernel compiled, and there is nothing preventing you from having multiple kernels and modules on the same system. This allows you to boot test kernels while keeping a known stable kernel in case you have trouble. Boot loaders like LILO will allow you to select a kernel at bootup.
The easiest place to pick up the latest kernels is http://www.kernel.org. This is the official site for Linux kernels. These kernels are almost always in tar-bzip2 format, instead of being in RPM or DEB formats. Check with your distribution provider for packaged formats of the kernel.
Unpack and untar the kernel. For packages compressed with bzip2, the process is:
# tar -jxvf linux-2.2.19.tar.bz2 |
This will create all the header files and source code for the kernel. There are three methods for configuring the kernel to compile, and each have some prerequisites. All methods will obviously require the C compiler.
6.2.1. Using make config
The siplest way (and the first) is to use make config from within /usr/src/linux. This is a very tedious way of compiling, since you must answer each question and the Linux kernel has a large number of questions now.
But an advantage to make config is that it does not require any other development tools to be installed in order to use it. On very lightweight systems, using this method will save drive space and memory, since we are not running very complicated or large programs.
SCREENSHOT OF make config HERE
6.2.2. Using make menuconfig
The next level of kernel configuration involves using a character based menuing system. For systems that have only a text console or ssh access, this makes an easier way to configure a kernel. It requires both ncurses and its development libraries to be installed in order for this to work. The program that runs in make menuconfig is part of the kernel source package and is compiled when needed.
With an on-screen menu, it is easier to organize and select the options you want to compile in. Help menus are available as well. This option is not good for those who want small systems, since it requires extra libraries.
INSERT SCREENSHOT OF make menuconfig
6.2.3. Using make xconfig
The most user friendly, but hardest to use, is the make xconfig option for configuring the kernel. This requires most of the X libraries to be installed, along with Tcl and Tk.
Since many server systems may not have X or its associated libraries, Tcl, or Tk installed, you may want to step back to one of the other methods of configuring the kernel. You would also need to make sure that you can export X to your desktop if you are configuring a remote system.
6.2.4. Options for configuring the kernel
Now that you have chosen a way to configure the kernel, how should you go about your configuration? What options should you pick for best performance, lowest memory consumption, and best security options?
Many of the answers to these questions depends on your particular situation. Selecting the right processor family for your CPI is one of the best things to do. Each processor family has its own way of alinging memory and some CPU-specific options and optimizations.
If your hardware setup is going to be stable, you can compile in drivers for various kinds of hardware for slightly better performance, and to prevent trojan modules from being loaded. See Section 6.2.4 for more on this.
Selecting DMA access for IDE devices under "Block devices" will automatically turn on DMA access, reducing CPU load. You can see Section 4.3.1.2 for more information.
If your box will be configured as a router without firewalling, you can enable "IP: optimize as router not host" under "Networking options". This reduces the latency of packets within the kernel by skipping a few unnecessary steps. But these steps are required if you will be doing firewalling or acting as a server.
Bonding device support under "Network device support" will enable bonding multiple network devices together to create one large pipe to other bonded Linux boxes or some Cisco routers.
If you plan on having a large number of users logging in and you would need a large number of pseudo terminals (PTYs), you can enter a number in "Maximum number of Unix98 PTYs in use (0-2048)" under "Character devices".
For systems that will not be onsite and require high availability, you can enable "watchdog timer support". Watchdogs can be implemented either in software or hardware. Software watchdogs open and close files to make sure that everything is working. If the driver cannot open the file, it tries to trigger a reboot of the system, since this indicates that there is some error with the system. Watchdog timers are usually implemented ISA cards, but some single board computers will have the necessary chips built in. Hardware watchdogs are a bit better as it can monitor extra features such as temperature and fan speed and can trigger reboots on those events as well. Hardware watchdogs are a bit more proactive as they continually talk to the kernel driver. If the kernel driver does not respond, the watchdog triggers a reset.
6.2.5. Kernel Modules and You
While this book is not specifically covering security, it is fair to bring it up every now and then. For those who want hard core, as-uncrackable-as-possible systems, you may want to consider removing module support from your system.
The reason for this is that if a cracker were to gain access to your system, one of the more advanced methods of covering their tracks is to insert a kernel module that hides much of their activity.
Another tactic is to replace an existing module with a trojan horse. Once the module is loaded, its payload deploys in kernel space instead of userspace, giving the rogue code more access to the system.
Another reason to remove modules from your system is to create a smaller size kernel. With modules compiled into the kernel, they get compressed along with the rest of the kernel using bzip2. Normally module files are uncompressed, but bzip2 can compress sizes by more than half. This can save crucial space if it is required.
For most users, however, you will want to use modules, as it gives a very versitile way of installing new drivers by just loading the module.
6.2.6. Building The Kernel
With a configured kernel, you can now go through the build process. This is documented in a number of places, but it is included here for completeness.
The first thing you should take a look at if you want to store the kernel configuration is to get /usr/src/linux/.config, as it has the ouput from the configuration options selected previously. You can move the .config file to a new system, then build the kernel and skip the configuration part.
The make dep command sets up the dependencies needed so the kernel can be built. This is a crucial step, as the kernel will not compile without it.
Most users will want to use bzip2 for building the kernel, as it makes a much smaller kernel than gzip or uncompressed. You can build a bzip2 kernel by using make bzImage. The compressed image is built and put into /usr/src/linux/arch/i386/. You may want to just use make bzlilo to put the kernel into / and run lilo to let you boot the new kernel. Some users may not want their kernel in /, since many distributions create a small /boot partition that contains the kernel and enough to boot the kernel. In this event, you will want to copy the kernel by and into /boot.
If you will be using modules, you will also need to run make modules and make modules_install. These two commands will build and install the modules for your kernel.