1. Why Plain diff Fails on Kernel Config Files

When you configure the Linux kernel, the output is a file named .config at the root of your kernel source tree. On a modern kernel 6.x build, this file contains around 10,000 lines. If you changed a handful of settings and want to see exactly what you modified, your first instinct might be to run:

$ diff .config.old .config

The problem is that plain diff compares files line by line. A .config file contains comment lines starting with #, blank lines, and symbols in a certain order that may shift when the kernel version changes. The result is an overwhelming wall of text where your five actual changes are buried under hundreds of irrelevant lines.

2. The diffconfig Script — Built Into the Kernel

The Linux kernel ships its own solution inside the scripts/ folder: a small utility called diffconfig. It was written specifically for this problem. Instead of a raw file comparison, it parses both config files, extracts the symbol names and their values, and then compares only the values. The result is sorted, minimal, and immediately useful.

How to Use diffconfig

The workflow is always the same: save a backup of your current config before making changes, apply your changes, then compare the two files:

# Step 1 — back up before you change anything
$ cp .config .config.old

# Step 2 — make your changes
$ make menuconfig

# Step 3 — compare cleanly
$ scripts/diffconfig .config.old .config

Reading the diffconfig Output

The output is compact and follows a strict three-symbol format. Here is a realistic example of what you might see:

-AX25 n
-HAMRADIO y
 DEBUG_STACK_USAGE n -> y
 IKCONFIG m -> y
 IKCONFIG_PROC n -> y
 LOCALVERSION "" -> "-mykernel01"
+UIO_AEC n

3. Kernel Security — More Complex Than You Think

There is a widespread belief that Linux is secure by default. The reality is more nuanced. The kernel has hundreds of Kconfig options that directly affect how resistant it is to being exploited. Distributions like Ubuntu or Fedora make their own choices about these options, balancing compatibility, performance, and security — and security does not always win.

More importantly, most attention in the Linux security world has historically focused on userspace security — tools like SELinux, AppArmor, and seccomp that control what running processes are allowed to do. These technologies have matured over two decades. Kernel-space hardening — protecting the kernel itself from being exploited — is a younger field and still catching up.

4. The Kernel Self Protection Project — KSPP

The Kernel Self Protection Project (KSPP) is a community initiative by kernel security engineers whose goal is simple: get hardening features merged directly into the mainline Linux kernel. Rather than maintaining out-of-tree patches that distributions have to apply separately, KSPP pushes these improvements upstream where everyone benefits automatically.

Many KSPP improvements are now in mainline Linux and enabled by default in kernel 6.x. But a significant number of hardening options are still n by default because they carry a performance cost or compatibility trade-off. This is exactly where tools like kernel-hardening-checker help.

5. Auditing Your Config With kernel-hardening-checker

There are well over a hundred security-relevant Kconfig options. Checking each one by hand is not realistic. Security engineer Alexander Popov created a tool called kernel-hardening-checker (formerly known as kconfig-hardened-check) that automates this audit completely.

You give it your kernel’s .config file and it checks each security-relevant option against recommendations from four well-respected sources:

Installing and Running the Tool

# Install via pip (Python package)
$ pip install kernel-hardening-checker

# Check your currently running kernel's config
$ kernel-hardening-checker -c /boot/config-$(uname -r)

# Check a custom kernel config you are building
$ kernel-hardening-checker -c /path/to/kernel/source/.config

# Just print what the recommendations are for x86_64 (no config needed)
$ kernel-hardening-checker -p X86_64

Reading the Output Table

option name                      | desired | decision  | reason          | result
CONFIG_BUG                       |    y    | defconfig  | self_protection | OK
CONFIG_STRICT_KERNEL_RWX         |    y    | defconfig  | self_protection | OK
CONFIG_STACKPROTECTOR_STRONG     |    y    | defconfig  | self_protection | OK
CONFIG_DEBUG_LIST                |    y    | kspp       | self_protection | FAIL: "is not set"
CONFIG_INIT_ON_ALLOC_DEFAULT_ON  |    y    | kspp       | self_protection | OK

6. Modern Feature: Auto-Generating a Hardening Fragment

The original kconfig-hardened-check tool could only audit your existing config. The modern kernel-hardening-checker gained a powerful new feature: with the -g flag, it generates a Kconfig fragment you can feed directly into your build process.

# Generate a ready-to-use hardening fragment for x86_64
$ kernel-hardening-checker -g X86_64 > /tmp/hardening.fragment

# Merge it with your existing .config using the kernel's own merge script
$ cd /path/to/your/kernel/source
$ scripts/kconfig/merge_config.sh .config /tmp/hardening.fragment

This is very useful if you maintain custom kernel builds for embedded products or production systems. You can automate security hardening as part of your CI/CD pipeline instead of relying on someone manually checking options.

❓ Frequently Asked Questions

🎯 Interview Questions