Inside AppOS: Creating a Hardware Profile

Unlike other Linux based solutions, AppOS ships for specific hardware profiles rather than a generic hardware architecture. Keeping with the "only what is absolutely needed" approach of AppOS, each hardware profile supports a number of different "feature sets". How do you figure out what profile you need? If you hardware is not supported, we provide a kernel build kit, I will post more about that later in the week. Figuring out what profile you need, or creating your own profile is pretty easy.

AppOS can upgrade any Linux distribution by adding a kernel and entry to your boot loader (Grub, LILO etc). On an existing Linux system, finding out the hardware is pretty simple. We recommend the use of the open source project lshw.

[root@foo]# wget http://ezix.org/software/files/lshw-B.02.13.tar.gz

Always check ezix.org first, make sure that the release hasn't been upgraded, especially if wget can't get the file. Next simply untar it with tar zxvf lshw-B.02.13.tar.gz; cd lshw-B.02.13. If you don't already have gcc-c++ installed, on Fedora based systems you will need to run yum install gcc-c++.

Simply run make, then cd src. In there you will find a lshw executable (assuming your environment is ok). There are pre-built binaries on ezix.org if you need them. Using lshw to build a profile is pretty simple:

[root@foo]# lshw > profile.appos
[root@foo]# cat profile.appos | grep driver

This will produce a list of drivers that lshw found you had loaded, you can typically ignore the sound drivers, unless you have some sort of specific reason you need them active on your server. In our case, it found several, you don't need to worry if you see a driver listed more than once.

driver=agpgart-intel
driver=pcieport-driver
driver=ata_piix
driver=e100
driver=i801_smbus
driver=uhci_hcd

So after sanitizing the output from lshw, we have the valuable information we need. You can check the list of hardware profiles when downloading AppOS, typically you will find what you need. In the event you need to compile, we profile a downloadable kernel kit, where all you have to do is run make menuconfig ; make.

The above hardware is a typical Intel based system, PCIe and AGP are Intel, its got the PIIX ATA driver, Intel E100 network driver, the Intel i801 smbus and USB UCHI.

The only other piece of information you need to know is how many CPU cores you have, a quick command:

[root@foo]# cat /proc/cpuinfo | grep model | grep name

model name : Intel(R) Pentium(R) D CPU 2.80GHz
model name : Intel(R) Pentium(R) D CPU 2.80GHz

Here we can see its got multiple processors or multiple cores, either way we don't care, we just know it needs SMP support.

After building the new kernel, or selecting one for download. Its placed in /boot, /boot/grub/grub.conf is updated (or /etc/lilo.conf). For lilo you'll need to run lilo to install, otherwise, grub will pickup the changes. There is no need for an append line or an initrd line. The AppOS kernel build has a built-in compressed ramdisk image. You can use the append line to configure the system on first boot, more on that later.

Common Sense: Disabling Linux Kernel Modules

Linux kernel modules are great for development and workstation environments, but do they actually make sense for servers or appliances? The quick answer to that is not really. When you factor in that having loadable kernel module support provides a potential attack vector into the heart of your system, you quickly begin to realize that the risk far outweighs the benefits.

Aside from the development advantages of loadable kernel modules, the only other key advantage is possibly saving space. Kernel modules indeed save space when they are not loaded. However, I can't come up with a single module that I'd have on a server that I would have unloaded. You don't really need the development advantages on a production server.

The security risk though is considerably higher when you run with kernel module support enabled. If someone compromises your system, gains local root access, all they need to do is insmod something malicious into your kernel, and then you might not even know its been compromised.

Loadable kernel modules do provide a generic way for Linux distributions to ship a one-size fits most solution. Most competent admins will end up recompiling the stock kernel anyway. So why run something heavily loaded, when all you really need are a minimal set of features? The more features you add to a system, the great the number of possible attack vectors and vulnerable code there is.

Have some common sense, disable your loadable kernel module support, and optimize your Linux kernel!