IOMMU configuration directive
Ensures the kernel booted with iommu=force, activating the I/O Memory Management Unit so DMA from peripheral devices is mediated and confined.
Checked against the resolved running state (e.g. sshd -T, sysctl, systemctl show), catches drop-ins and Includes a file read would miss. Caveat: runtime ≠ persistence; a value correct now may not survive a reboot.
Pavois asserts the effective configuration, the live, resolved state, not a file. File-based scanners (OVAL/SCAP, Lynis) miss Includes, drop-ins and runtime defaults; this check sees what is actually applied.
A mapping is a cross-reference to where each standard places this requirement, anchored and cross-validated, not a claim of equivalence. A passing check is evidence toward these references, how to read it.
Why this rule matters
On x86 platforms the I/OMMU mediates Direct Memory Access from hardware devices. Without it, a malicious or compromised peripheral (PCIe card, Thunderbolt/USB4 device, firmware) can perform arbitrary DMA reads/writes of system RAM, bypassing OS memory protections entirely, the classic DMA attack used to extract keys or implant code. iommu=force enforces IOMMU translation even when firmware would otherwise leave it passthrough, closing that physical-access attack surface (ANSSI BP-028 R7).
What Pavois checks
Pavois reads /proc/cmdline, the line the running kernel booted with, and checks for iommu=force. Inspecting /etc/default/grub would only show intent for the next boot; /proc/cmdline proves the IOMMU directive is active in the running kernel, catching a botched bootloader regeneration or a drop-in that silently dropped the parameter.
only_if('n/a in a virtualized guest: applied only on bare metal') { command('systemd-detect-virt -q').exit_status != 0 }
describe command('cat /proc/cmdline') do
its('stdout') { should match(/(^| )iommu=force( |$)/) }
end
describe command("grep -hwsF 'iommu=force' /etc/default/grub /etc/kernel/cmdline /boot/grub/grub.cfg /boot/grub2/grub.cfg /boot/efi/EFI/*/grub.cfg 2>/dev/null") do
its('stdout') { should match(/\S/) }
endHow to verify it is applied
Run cat /proc/cmdline and confirm iommu=force is present. Confirm the IOMMU actually engaged with dmesg | grep -e DMAR -e IOMMU (Intel VT-d / AMD-Vi initialisation lines). The flag only appears after a reboot following a config change.
Inspect & investigate
IOMMU initialisation and DMA fault messages are in the kernel ring buffer: dmesg | grep -i -e DMAR -e IOMMU -e AMD-Vi. Persistent faults (a device blocked from rogue DMA) also surface there.
Remediation
pavois harden apply uses the kernel_cmdline resource to add iommu=force to the bootloader (GRUB) configuration and regenerate it. It is flagged reboot_required because the IOMMU is set up at boot, the parameter appears in /proc/cmdline only after the next restart.
Pavois applies this with its own harden engine, the plan below, not a shell script:
| param | iommu=force |
|---|---|
| reboot_required | true |
| resource | kernel_cmdline |
pavois harden plan localwhere the target is local, a user@host SSH alias, or a container , Docs
Impact & precautions
Higher-risk than other cmdline tweaks: forcing the IOMMU can break devices that rely on DMA passthrough (some GPUs, NICs, passthrough/virtualisation setups) and on misbehaving firmware it can cause boot hangs or device failures. Precautions: the platform must have VT-d/AMD-Vi enabled in BIOS/UEFI; test on a non-production host first, keep console/out-of-band access for recovery, and check dmesg for DMA faults after reboot. Have a known-good prior GRUB entry to fall back to.
Standards mapping
| Standard | Reference | Type | Version | Confidence |
|---|---|---|---|---|
| ANSSI BP-028 | R7 | direct | 2.0 | high |
Each reference is a cross-reference anchored in the upstream benchmark and cross-validated against the SCAP Security Guide and ansible-lockdown, not a claim of equivalence. Direct = a prescriptive, line-level requirement; supporting = an abstract control family (NIST) the check provides evidence toward. How to read a mapping.