Modinfo: Inspecting Kernel Module Metadata, Auditing Cryptographic Signatures, and Validating Driver Parameters in Production

In the midst of an infrastructure crisis, the instinct to guess is dangerous. High-performance servers do not fail randomly; their physical components are commanded by low-level device drivers that live inside the Linux kernel—the foundational layer of software that bridges physical silicon with application code. When a network card drops packets or a storage array freezes, the underlying cause is rarely mysterious hardware decay. More often, it is a mismatch in driver configuration, an incompatible kernel version, or a missing piece of hardware microcode.

To solve the puzzle without destabilising the machine further, systems engineers do not guess or randomly reboot servers. Instead, they turn to modinfo—a precision diagnostic tool that inspects the blueprints, configuration dials, and security certificates of any Linux kernel module before it is ever loaded into active memory.

The quickest way to inspect any device driver on a Linux system is to run modinfo followed by the module name. For example, querying the standard Intel network driver takes a single command:

modinfo e1000e

Within milliseconds, modinfo reads the driver binary directly from the disk and outputs a complete manifest of its identity:

filename:       /lib/modules/6.8.0-40-generic/kernel/drivers/net/ethernet/intel/e1000e/e1000e.ko.zst
version:        3.2.6-k
license:        GPL v2
description:    Intel(R) PRO/1000 Network Driver
author:         Intel Corporation, <linux.nics@intel.com>
srcversion:     2D0E6C52B5CA6F869A68364
alias:          pci:v00008086d0000105Esv*sd*bc*sc*i*
alias:          pci:v00008086d000010D3sv*sd*bc*sc*i*
depends:        ptp
retpoline:      Y
intree:         Y
name:           e1000e
vermagic:       6.8.0-40-generic SMP preempt modversions 
sig_id:         PKCS#7
signer:         Build time autogenerated kernel key
sig_key:        51:A4:9C:12:F4:7E:28:44:CD:19:62:3B:5A:F1:60:88:C1:23:45:67
sig_hashalgo:   sha512
signature:      30:82:02:B0:06:09:2A:86:48:86:F7:0D:01:07:02:A0:82:02:A1:30:82...
parm:           InterruptThrottleRate:Interrupt Throttling Rate (array of int)
parm:           IntMode:Interrupt Mode (uint)
parm:           SmartPowerDownEnable:Enable USB power down (uint)
parm:           KumeranLockLoss:Enable Kumeran lock loss workaround (uint)

In one readable snapshot, you can verify who wrote the code, which software licence governs it, which precise hardware models it supports, what security signature guarantees its authenticity, and what performance tuning knobs are available to adjust its behaviour.

What Modinfo Does in Plain English

Think of a Linux kernel module as a specialised plug-in for your operating system. When your server detects a new network card or storage controller, it loads a .ko (Kernel Object) file to teach the operating system how to talk to that specific hardware. Because these modules run with total administrative control over the machine, loading a corrupted, outdated, or malicious driver can instantly crash the operating system or compromise its security.

The modinfo command, part of the standard kmod utilities suite, serves as an identity inspection scanner for these modules. It reads the compiled binary files sitting in your system's /lib/modules/ directory and extracts their embedded metadata without requiring them to run. This gives engineers a completely safe, non-intrusive way to audit driver settings, verify software supply chains, and troubleshoot hardware issues before code is executed at the most privileged level of the computer.

Anatomy of a Kernel Module and Core Flags

Under the bonnet, Linux kernel modules are structured as Executable and Linkable Format (ELF) object files. When modinfo opens a .ko file, it navigates a series of specialised data compartments:

1. The .modinfo Section: A dedicated list of text strings containing key-value pairs that describe the author, licence, hardware aliases, firmware requirements, and configuration parameters (parm).
2. The .note.gnu.build-id Section: A unique fingerprint stamped by the compiler to trace the compiled binary back to its exact source code commit.
3. Appended Cryptographic Signatures: When modern systems use UEFI Secure Boot, an X.509 digital signature is appended directly to the end of the module file, marked by the magic trailer string ~Module signature appended~.
4. Transparent On-Disk Decompression: In modern Linux distributions, modules are compressed using Zstandard (.ko.zst) or XZ (.ko.xz) to save disk space. The modinfo utility decompresses and analyses these files in memory on the fly without writing temporary files to disk.

Essential Command Flags

Five Real-World Production Use Cases

1. Auditing Cryptographic Module Signatures in Secure Boot Environments

The Scenario

An enterprise security policy requires all bare-metal compute nodes to enforce UEFI Secure Boot alongside Linux Kernel Lockdown. Following a maintenance update, a server refuses to load an essential network filtering probe, throwing a cryptic kernel error: EKEYREJECTED (Key was rejected by service). The site reliability engineer must determine whether the driver binary on disk was signed by an approved enterprise authority or an untrusted local key.

The Command

modinfo -F sig_id -F signer -F sig_key -F sig_hashalgo -F signature /opt/security/drivers/netfilter_sensor.ko

Terminal Telemetry

sig_id:         PKCS#7
signer:         Enterprise Infrastructure Root CA - G4 Subkey
sig_key:        7E:3B:11:09:44:A2:8F:CC:01:5D:88:99:E4:31:00:1A:BC:DE:F0:12
sig_hashalgo:   sha256
signature:      4A:1F:90:BC:88:12:AA:77:09:DE:33:55:C1:80:FF:99:31:4A:E6:0B
                11:22:33:44:55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44
                55:66:77:88:99:AA:BB:CC:DD:EE:FF:00:11:22:33:44:55:66:77:88

Line-by-Line Explanation

• sig_id: PKCS#7: Confirms the signature uses standard RFC 2315 cryptographic packaging.
• signer: Enterprise Infrastructure Root CA...: Identifies the Common Name of the certificate authority that authorised the driver.
• sig_key: 7E:3B:11:09...: The public key identifier. The kernel compares this against its internal trust store and the UEFI Machine Owner Key (MOK) database.
• sig_hashalgo: sha256: The cryptographic hashing algorithm used to guarantee the binary has not been tampered with.
• signature: 4A:1F:90...: The raw digital signature verifying origin and integrity.

What the Admin Does Next

The telemetry proves the module is authentic and signed by the enterprise root authority. The reason the kernel rejected it is that the target server is missing the corresponding public certificate in its local UEFI MOK keyring. The engineer imports the public key and registers it:

mokutil --import /etc/pki/enterprise_kmod_signing_ca.der
# Enter a one-time enrollment password, then reboot the server to approve enrollment in UEFI.

2. Tuning Network Driver Parameters to Eliminate Microsecond Latencies

The Scenario

A high-frequency financial platform begins experiencing erratic latency spikes during peak market hours. Network diagnostics reveal that packets are queuing up because the Intel 10-Gigabit Ethernet driver (ixgbe) is throttling hardware interrupts to conserve CPU cycles. The systems engineer needs to discover which configuration knobs the driver supports so they can disable interrupt moderation.

The Command

modinfo -p ixgbe

Terminal Telemetry

max_vfs:Number of Virtual Functions: 0 = disable (default), 1-63 = enable this many VFs (uint)
dca:Disable Direct Cache Access (DCA): 0 = disable, 1 = enable (default) (uint)
InterruptThrottleRate:Maximum interrupts per second, per vector: 0=off, 1=dynamic, 956-488281=fixed rate (default 1) (array of int)
FdirPballoc:Flow Director packet buffer allocation level:
        1 = 8k hash filters or 2k perfect filters
        2 = 16k hash filters or 4k perfect filters
        3 = 32k hash filters or 8k perfect filters (uint)
allow_unsupported_sfp:Allow unsupported and untested SFP+ modules on 82599-based adapters (uint)

Line-by-Line Explanation

• max_vfs:... (uint): Controls hardware virtualisation slicing; expects an unsigned integer between 0 and 63.
• dca:... (uint): Enables Direct Cache Access, delivering packet headers straight into the CPU cache.
• InterruptThrottleRate:... (array of int): The critical performance knob. Setting this to 0 turns off interrupt throttling completely, processing incoming packets immediately at the cost of higher CPU utilisation.
• allow_unsupported_sfp:... (uint): Allows third-party optical transceivers to connect without being rejected by vendor locks.

What the Admin Does Next

Using the exact parameter names revealed by modinfo, the engineer creates a dedicated configuration file to disable throttling across both ports, then safely reloads the driver:

# 1. Write the low-latency parameter overrides
cat <<EOF > /etc/modprobe.d/ixgbe-lowlatency.conf
options ixgbe InterruptThrottleRate=0,0 DCA=1
EOF

# 2. Apply settings by bouncing the network interface
ip link set dev eth0 down
ip link set dev eth1 down
modprobe -r ixgbe && modprobe ixgbe

3. Diagnosing Hardware Detection Failures and Missing Microcode

The Scenario

Following an operating system upgrade across a fleet of edge servers, several wireless interface cards and storage accelerators fail to appear. The physical devices are visible when running lspci, but no driver attaches to them. The administrator must check whether the driver supports the card's exact PCI identifier and whether it is failing silently due to missing microcode firmware.

The Command

# Query the firmware binary files demanded by the driver
modinfo -F firmware iwlwifi

# Check if the physical hardware ID is supported by the driver
modinfo -F alias iwlwifi | grep -i "00008086d000043F0"

Terminal Telemetry

# Firmware output:
iwlwifi-ty-a0-gf-a0-59.ucode
iwlwifi-ty-a0-gf-a0.pnvm
iwlwifi-so-a0-gf-a0-64.ucode
iwlwifi-so-a0-gf-a0.pnvm
iwlwifi-QuZ-a0-hr-b0-67.ucode
iwlwifi-QuZ-a0-jf-b0-67.ucode
iwlwifi-Qu-c0-hr-b0-67.ucode

# Hardware Alias output:
alias:          pci:v00008086d000043F0sv*sd*bc*sc*i*

Line-by-Line Explanation

• iwlwifi-ty-a0-gf-a0-59.ucode: The exact microcode firmware image the driver will look for inside /lib/firmware/ during boot.
• alias: pci:v00008086d000043F0...: The hardware matching pattern compiled into the driver. v00008086 matches Intel (Vendor ID), and d000043F0 matches the exact physical card model (Device ID).

What the Admin Does Next

The output confirms that the driver does support the physical card (8086:43F0), but requires iwlwifi-ty-a0-gf-a0-59.ucode. A quick filesystem check shows the driver package was installed without the corresponding firmware binaries in the boot RAM disk (initramfs). The engineer restores the firmware package and rebuilds the initial RAM disk:

# Reinstall firmware files
apt-get install --reinstall linux-firmware

# Rebuild the early-boot RAM disk
update-initramfs -u -k all

4. Preventing Fleet-Wide Boot Failures in CI/CD Driver Builds

The Scenario

An automated build pipeline compiles a custom out-of-tree storage driver (such as OpenZFS) using DKMS. Before rolling out the resulting binary package to 4,000 production servers running kernel 6.8.0-40-generic, the release engineer must verify that the compiled module adheres to the exact Kernel Vermagic and multiprocessing parameters of the fleet. Loading a driver compiled against mismatched kernel headers can trigger immediate kernel panics.

The Command

modinfo -F vermagic -F retpoline -F intree -k 6.8.0-40-generic /tmp/staging/zfs.ko

Terminal Telemetry

6.8.0-40-generic SMP preempt modversions 
retpoline:      Y
intree:         N

Line-by-Line Explanation

• 6.8.0-40-generic: The target kernel version. This must match the output of uname -r on the production servers down to the last character.
• SMP: Confirms symmetric multiprocessing support (CONFIG_SMP=y). Loading a uniprocessor module on a multi-core server will cause CPU lockup bugs.
• preempt: Indicates the kernel task preemption model. Mixing preemption modes causes unpredictable memory corruptions.
• modversions: Verifies that symbol checksums are active, ensuring binary interface compatibility.
• retpoline: Y: Proves that Spectre Variant 2 compiler mitigations are active.
• intree: N: Identifies the code as an external third-party module compiled outside the core Linux kernel repository.

What the Admin Does Next

Because the vermagic string matches the production fleet, the binary is safe to deploy. The engineer adds an automated safety gate to the CI/CD deployment script to catch future mismatches before they reach production:

TARGET_KVER="6.8.0-40-generic"
MOD_VERMAGIC=$(modinfo -F vermagic -k "${TARGET_KVER}" /tmp/staging/zfs.ko | awk '{print $1}')

if [ "${MOD_VERMAGIC}" != "${TARGET_KVER}" ]; then
    echo "DEPLOYMENT HALTED: Module built for ${MOD_VERMAGIC}, but target is ${TARGET_KVER}" >&2
    exit 1
fi
echo "Binary compatibility verified. Proceeding with rollout."

5. Auditing Production Fleets for Proprietary Licences and Kernel Taints

The Scenario

A regulated financial services firm operates under strict open-source governance. Loading proprietary drivers triggers a "kernel taint" flag (TAINT_PROPRIETARY_MODULE), which invalidates vendor enterprise support contracts, blocks kernel debugging hooks, and introduces legal compliance risks. The engineering team must scan all installed modules across their fleet to locate any non-GPL proprietary code.

The Command

find /lib/modules/$(uname -r) -name "*.ko*" -print0 | \
  xargs -0 -P $(nproc) -n 1 modinfo -0 -F filename -F license -F description -F author | \
  awk 'BEGIN { RS="\0"; ORS="\n" } {
    file=$1; getline lic; getline desc; getline auth;
    if (lic !~ /^(GPL|GPL v2|GPL and additional rights|Dual BSD\/GPL)$/) {
      printf "PROPRIETARY TAINT RISK:\n  File: %s\n  License: %s\n  Description: %s\n  Author: %s\n\n", file, lic, desc, auth
    }
  }'

Terminal Telemetry

PROPRIETARY TAINT RISK:
  File: /lib/modules/6.8.0-40-generic/updates/dkms/nvidia.ko.zst
  License: NVIDIA
  Description: NVIDIA UNIX x86_64 Kernel Module
  Author: NVIDIA Corporation

PROPRIETARY TAINT RISK:
  File: /lib/modules/6.8.0-40-generic/extra/proprietary_hba.ko.xz
  License: Proprietary
  Description: Enterprise RAID Controller Acceleration Engine
  Author: Megacorp Hardware Storage Solutions LLC

Line-by-Line Explanation

• find ... -print0 | xargs -0 -P $(nproc) ...: Searches the module tree in parallel across all CPU cores. The -0 flag ensures paths with spaces or special characters are safely handled.
• modinfo -0 -F ...: Emits raw field values separated by null bytes (\0) so descriptions containing line breaks do not corrupt the script.
• awk 'BEGIN { RS="\0" ... }': Reads the stream record by record.
• if (lic !~ /^(GPL...)/): Filters out standard open-source licences, flagging proprietary licences such as NVIDIA or Proprietary.

What the Admin Does Next

The audit exposes an unapproved proprietary storage driver (proprietary_hba.ko.xz). The administrator blacklists the module so it cannot be loaded automatically by the operating system:

# 1. Prevent the module from loading automatically
echo "blacklist proprietary_hba" > /etc/modprobe.d/blacklist-proprietary.conf

# 2. Verify that the runtime kernel remains clean and untainted
cat /proc/sys/kernel/tainted
# A return value of '0' confirms a completely clean, open-source kernel state

Common Diagnostic Pitfalls and How to Avoid Them

1. Interrogating the Running Kernel Instead of the Staged Update

When you run modinfo <module> without flags, the tool automatically queries the directory of the currently running kernel (/lib/modules/$(uname -r)). During an automated system upgrade where a new kernel package has been installed on disk but the machine has not yet been rebooted, modinfo will inspect the old running modules rather than the new ones waiting for the next boot.

• The Danger: You verify that a parameter exists or a bug is fixed, schedule a maintenance reboot, and discover upon startup that the new kernel fails because its module tree was never inspected.
• The Fix: Always specify the target kernel version explicitly with the -k flag when verifying updates: bash modinfo -k 6.8.0-40-generic nvme

2. Confusing Built-in Drivers with Missing Modules

Not all Linux drivers live as independent .ko files on disk. Core drivers (such as essential disk controllers or filesystem drivers like OverlayFS) are often compiled directly into the monolithic kernel executable (vmlinuz).

• The Danger: Running modinfo overlay returns an alarming error: modinfo: ERROR: Module overlay not found. An administrator might waste hours attempting to compile or install a driver that is already running inside the core kernel.
• The Fix: Check the modules.builtin index file before assuming a module is absent: bash grep "overlay" /lib/modules/$(uname -r)/modules.builtin For built-in drivers, inspect /sys/module/<module_name>/parameters/ to view active parameters rather than relying on modinfo.

3. Whitespace Splitting in Shell Scripts

In shell automation, capturing field outputs like modinfo -F parm <module> can easily break scripts if parameter descriptions contain spaces, colons, or newlines.

• The Danger: A simple loop like for p in $(modinfo -F parm $MOD) splits single descriptions into multiple broken tokens.
• The Fix: Always use the -0 null-delimiter flag in combination with xargs -0 or tr '\0' '\n': bash modinfo -0 -F parm e1000e | tr '\0' '\n'

Complete Metadata Field Reference

The table below outlines all metadata fields accessible through modinfo -F <field>, their location inside the compiled binary, and how they help diagnose issues in production.

Today's Takeaway

The modinfo command is more than a simple query tool; it is a forensic magnifying glass that reveals the exact relationship between your hardware, your drivers, and the Linux operating system. You can put it to work on your own machine right now in less than five minutes: open a terminal, pick an active driver from your system by running lsmod | head -n 5, and run modinfo -p <module_name> to explore the hidden hardware dials built into your computer. Checking your drivers before an outage happens is the simplest, most effective habit you can form to ensure your systems remain stable, secure, and fast.

Authoritative Technical References & Documentation

• kmod modinfo Manual Page (man7.org)
• Linux Kernel Documentation: Module Signing Infrastructure
• Linux Kernel Security: Kernel Lockdown Modes & Trust Rings
• ArchWiki: Linux Kernel Modules & Hardware Aliasing
• Linux Kernel Build System: Building External Modules (Kbuild)