Debian Kernel Configs for x86-64 vs ARM Explained

Debian utilizes a sophisticated, layered configuration hierarchy within its kernel source package to deliver optimized default kernel images across diverse computer architectures. While x86-64 systems benefit from standardized platform specifications like ACPI and UEFI allowing for a single unified configuration, the ARM ecosystem—spanning modern 64-bit servers to diverse 32-bit embedded System-on-Chips (SoCs)—requires distinct configuration strategies regarding hardware discovery, bootloader handoff, and module modularity. This article explains how the Debian operating system structures, differentiates, and builds default kernel configurations for both x86-64 and ARM platforms.

The Debian Kernel Configuration Architecture

Debian manages Linux kernel source code through a centralized source package (typically named linux). Rather than maintaining entirely isolated configuration files (.config) for every supported architecture, Debian employs a modular, cascading configuration hierarchy:

  1. Common Base (config): Contains general distribution-wide settings applicable across all architectures, such as standard security features (AppArmor, SELinux support), networking protocols, filesystem drivers, and core namespace/container features.
  2. Architecture-Specific Base (<arch>/config): Overrides and appends settings specific to an architecture family (e.g., amd64/config, arm64/config, or armhf/config).
  3. Flavor-Specific Overrides (<arch>/config.<flavor>): Defines the final settings for specific target profiles, such as amd64/config.amd64, arm64/config.arm64, or 32-bit ARM multiplatform variants.

During the build process, these configuration snippets are concatenated and processed via kconfig tools to generate the final configuration used to compile each linux-image binary package.

Default Kernel Configuration for x86-64 (amd64)

The x86-64 ecosystem is characterized by hardware standardization rooted in the IBM PC legacy, modern UEFI, and Advanced Configuration and Power Interface (ACPI) standards. This uniformity allows Debian to ship a universally applicable default configuration.

  • Single Primary Flavor: Debian targets 64-bit x86 systems primarily with the amd64 kernel flavor (and the real-time rt-amd64 variant). A single kernel package can boot on practically any compliant desktop, laptop, server, or virtual machine.
  • ACPI and PCI Discovery: Debian builds core ACPI, PCI bus support, and basic video infrastructure directly into the kernel image (=y). Because ACPI allows the operating system to dynamically query system components, almost all peripheral device drivers are compiled as dynamically loadable modules (=m).
  • Minimal Built-ins: To reduce memory footprint and maintain flexibility, drivers for network interface cards, storage controllers, and peripherals are deferred to the initramfs, where udev loads them on demand.

Default Kernel Configuration for ARM (arm64, armhf)

Unlike x86-64, the ARM ecosystem historically lacked standardized hardware enumeration and unified firmware interfaces, resulting in different configuration methodologies across ARM generations.

64-Bit ARM (arm64)

Modern ARM64 configurations reflect efforts toward standardization led by Arm's Server Base System Architecture (SBSA) and Server Base Boot Requirements (SBBR).

  • Unified Target: Similar to amd64, Debian compiles a unified arm64 kernel image capable of booting on standard enterprise servers and consumer devices alike.
  • Dual Boot Path Support: The default arm64 configuration must enable both ACPI (CONFIG_ACPI=y) for enterprise server platforms and Open Firmware Flattened Device Tree (CONFIG_OF=y) for consumer SoCs and single-board computers.
  • Device Tree Blobs (DTBs): Because many ARM64 boards do not present ACPI tables, the kernel build generates hundreds of compiled Device Tree files (.dtb) bundled into the kernel package, allowing the kernel to discover board-specific memory layouts and peripherals.

32-Bit ARM (armhf and armel)

Older 32-bit ARM architectures lack standard firmware and feature distinct instruction sets and hardware variants.

  • Multi-Platform Kernels (armmp): For armhf, Debian introduced the Multi-Platform flavor (config.armmp), leveraging flattened device trees to boot a single kernel across different SoC families (e.g., Allwinner, Rockchip, Freescale/NXP).
  • Multiple Flavors: Where hardware differences cannot be reconciled in a single binary—such as differing virtual memory layouts or incompatible CPU instruction sets (ARMv4t, ARMv5te, ARMv7-A)—Debian maintains distinct flavors (e.g., armel/config.marvell or armhf/config.armmp-lpae for Large Physical Address Extension support).

Key Configuration Differences: x86-64 vs. ARM

Feature / Setting x86-64 (amd64) ARM 64-Bit (arm64) ARM 32-Bit (armhf)
Hardware Discovery ACPI and PCI enumeration ACPI and Device Tree (dual-support) Device Tree (CONFIG_OF)
Flavor Diversity Uniform (single standard flavor) Uniform (single standard flavor) Segmented (armmp, armmp-lpae)
Firmware Expectation UEFI or legacy BIOS UEFI/ACPI or U-Boot with DTB U-Boot or proprietary bootloaders
Bundled DTBs None Extensive set of .dtb files Extensive set of .dtb files
Driver Integration High reliance on modularization (=m) Core SoC interconnects built-in (=y), rest modular (=m) Specific SoC clock/power drivers built-in (=y)

Automated Auditing and Maintenance

Debian verifies and enforces consistency across architectures using automated maintenance scripts in the source tree:

  • Kernel Team Scripts: Scripts parse the generated configurations against the latest upstream Kconfig definitions to detect deprecated symbols, newly introduced features, and conflicting dependencies.
  • Security Baselines: Security-sensitive options (such as kernel self-protection features, BPF hardening, and page table isolation) are enforced globally in the base configuration and applied equally to both x86-64 and ARM, provided the underlying architecture provides the required CPU instructions.