[CS-FSLUG] Have You Built a Custom Kernel and Why?

Tim Young Tim.Young at LightSys.org
Mon Jan 23 12:36:32 CST 2012

I have done a number of custom kernels.  I usually recommend against 
it for a number of reasons, unless you really find it will help...

The default kernel has lots of "modules", each module is the driver 
for certain sets of hardware.  A custom kernel allows you to have 
hardware that is not-by-default supported on your release.

There are a number of security patches that you can apply to a 
kernel, if you want to run a firewall or something.  Selinux now 
allows you to do many of those same security features, but in an 
"easier to manage" way than building a custom kernel.  But I do know 
of people who have custom build kernels so that they have a lot of 
much better security on their Linux box.

While the out-of-the-box kernels are generically optimized for your 
computer (i686, i386, etc), each CPU has different features.  
Compiling a kernel for a specific computer can get that computer to 
run faster.  For the most part, however, I find this is a silly 
argument.  Most Linux boxes hover around %2 CPU usage.  The 
improvement of a few clock-cycles is not going to make a huge 
difference.  When you are really using a computer heavily, the 
bottlenecks are rarely the kernel, but rather memory and HD access.  
So I do not think you get much of a performance gain by building a 
custom kernel.

The down-sides to a custom kernel, as I see them, are primarily due 
to the difficulty in keeping the computer updated.  I have seen 
people have a lot of fun rebuilding a kernel one time, but then they 
realize that, now, every time they want to update to a newer kernel, 
they need to rebuild it again.  Once is fun.  Once a month is a 
pain.  Usually, people who build custom kernels end up only updating 
the kernel every so often, which can result in various security 
patches not being applied regularly.  On most home computers which 
are behind firewalls, this is usually not a huge deal.  But for 
servers, especially web or email servers that have holes punched 
through firewalls so people can access the computer remotely, this is 
a big deal.  Most Linux hacking where the hacker gains root is 
because the hacker is able to connect to a server, gain "unprivileged 
access" (a non-root user), and then use that access to attack through 
"unpatched vulnerabilities."  One of the best things you can do for a 
system is keep it updated.  Building a custom kernel keeps many 
people from updating their system, therefore I think it is a bad 
idea.  ;)

By two cents,

     - Tim Young

On 1/23/2012 11:52 AM, Don Parris wrote:
> As I am gearing up for one of the Linux certs, I was reading a 
> chapter on building a custom kernel.  I did not follow the 
> exercise, as I honestly feel I need a pretty compelling reason to 
> build a custom kernel, other than "just because I can".  I did do 
> this years ago with the Mach kernel that ran under Red Hat 5, but 
> have never really seen the need to do so again.  I think simply 
> modifying the loading of modules (something else I have done at 
> least once or twice) is sufficient in most cases.  I am certain 
> there are really compelling reasons to build a custom kernel, though.
> I am curious to know if any of you have actually built a custom 
> kernel, and what advantages (if any) this gave you over (a) the 
> default kernel and (b) a comparable Windows system.  I ask about 
> Windows, because - as far as I know, no one can build a custom 
> kernel (since we cannot access the source code).  To build a custom 
> kernel "just because you can" - even though that, in and of itself 
> is a great thing - is not good enough for this question.  I want to 
> know if your custom kernel made Windows look even slower than 
> molasses or if you gained some special feature that is not normally 
> needed, or that does not exist in Windows.  Any compelling cases 
> out there for building a custom kernel?
> Blessings,
> Don
> -- 
> D.C. Parris, FMP, LEED AP O+M, ESL Certificate
> Minister, Security/FM Coordinator, Free Software Advocate
> https://www.xing.com/profile/Don_Parris  | 
> http://www.linkedin.com/in/dcparris
> GPG Key ID: F5E179BE
> _______________________________________________
> ChristianSource FSLUG mailing list
> Christiansource at ofb.biz
> http://cs.uninetsolutions.com

More information about the Christiansource mailing list