blog.6admin.io
guest@6admin.io:~$
debian, foreman, hardening, kernel, linux

Recompiling your kernel: bespoke kernels for your own infra

Hardening the OS is mostly subtraction, removing what listens and cutting the kernel surfaces you do not need, which I detailed in hardening the OS and the Linux kernel . There is one step that article did not climb and it is my favorite: not disabling a kernel feature at runtime, but never compiling it at all. Recompiling your own kernel is subtraction taken to its logical conclusion.

Why recompile, exactly

A distribution’s default is a kernel for everyone, so a kernel that ships just about everything: hundreds of drivers, exotic filesystems, whole networking subsystems, debug options, because it has to boot a student’s laptop as well as a storage array. On an infra, the hardware is known and stable and all that baggage becomes free attack surface. A subsystem that is not compiled has no CVE for you, no module to load, no bug to exploit; it simply does not exist in the binary. Compiling the kernel for your fleet is therefore three wins at once: a surface reduced to what you actually use, a smaller and often faster kernel because it carries less and a control that changes everything the day you have to react.

That last point is the least intuitive and the most valuable. When you own the chain that produces your kernel, you do not wait for a vendor’s timeframe to fix a flaw, you backport the upstream patch and ship, the same day if you must. We will come back to it below, because a French company illustrated it spectacularly.

The Debian way: a package, a repo, a pin

The kernel builds cleanly into a Debian package, with no hand-fiddling in /boot. You start from the distribution’s config, trim it with make menuconfig and produce a versioned .deb:

# from the source tree, base config taken from the distro
make olddefconfig
make menuconfig                  # strip what you do not use
make -j"$(nproc)" bindeb-pkg     # produces linux-image-*.deb, headers included

bindeb-pkg emits only the binary packages, the ones you deploy; deb-pkg would also build the source packages, useless here. The .deb does not go to the machines by hand, it enters your own apt repo, kept with reprepro or aptly, signed with your own key. The servers point at that repo and an apt pin explicitly says to prefer this kernel over the distribution’s:

# /etc/apt/preferences.d/kernel-inhouse
Package: linux-image-* linux-headers-*
Pin: origin repo.internal.example
Pin-Priority: 1001

A priority above 1000 even allows a downgrade if you must roll back, which is exactly the property you want on a kernel. At this point a homemade kernel deploys like any package, apt upgrade and reboots on a schedule like the rest.

At scale: Katello and content that gets promoted

A flat repo is enough for a handful of machines, not for a fleet with environments. This is where the Foreman ecosystem comes in, with Katello, which leans on Pulp to host and version the repos and on Candlepin for subscriptions. The homemade kernel becomes content like any other, pushed into a content view, frozen into versions and promoted along lifecycle environments, Library then Dev then Test then Prod. Promotion is the act of trust: a kernel reaches Prod only because its content view version has crossed Test and you can pin a whole environment to a precise version while another takes the hits. It is the industrial version of pinning, the same principle, with traceability and rollback on top.

The price, because it is real

It has to be said plainly: this thrill has a cost and not everyone can afford it. An in-house kernel in production demands a build pipeline and above all a test one on real hardware, because a kernel that boots in a VM can perfectly well hang on the exact network card of one server model. It demands canaries, a handful of machines that take the new kernel before the fleet and a rollback path rehearsed for real, not assumed. A bad kernel does not make a service unavailable, it bricks the machine until someone intervenes and multiplied by a fleet that is a very bad night. If you do not have the means for that pipeline, the right answer is not to recompile anyway, it is to stay on the distribution kernels and patch fast and often, which the hardening article already argues for. Recompiling is a win when you have the discipline that goes with it, a debt when you improvise it.

Yes, I recompile, so what?

  • The ultimate subtraction is not disabling a kernel feature, it is never compiling it: what is not in the binary has no CVE, no module and no bug for you.
  • A kernel cut for a known fleet is smaller, often faster and rid of whole surfaces a distribution ships to please everyone.
  • The Debian way is clean: bindeb-pkg, your own apt repo, a pin and the kernel deploys like a package and downgrades if needed.
  • At scale, Katello promotes the kernel as versioned content along environments, pinning with traceability and rollback.
  • The price is a test pipeline on real hardware and canaries; without it, stay on the distro and patch fast, no shame.

[edit: 2026] The full-scale illustration came in July 2026 with CVE-2026-53359, nicknamed “Januscape”, a use-after-free in the shadow paging of KVM x86 that hit every Linux x86 kernel, OVHcloud included. Contrary to what I thought I remembered, they did not escape it, their fleet was exposed like everyone else’s. What their in-house Debian kernel pipeline gave them was reaction speed: their Kernel and Virtualisation teams backported the upstream patch onto their production kernels and shipped a fixed kernel the very evening of the alert, instead of depending on a third party’s timeframe across tens of thousands of hypervisors and about a million VMs. They explicitly ruled out waiting for an official kernel and live patching, because the latter requires enabling a kernel option that reduces hardening. Owning your kernel is not immunity, it is the freedom to react at your own pace. The story is on the OVHcloud blog .