Re: [PATCH 0/2] lockdown: Prevent booting with lockdown enabled but IOMMU disabled

[Xiu Jianfeng <xiujianfeng@huawei.com>]

On 11/2/2026 10:00 PM, Mario Limonciello (AMD) wrote:
> Lockdown is a kernel LSM that restricts access to sensitive kernel
> resources (e.g. /dev/mem, kernel modules, perf, tracing, kprobes,
> BPF access to kernel memory). However, without IOMMU, any PCI/PCIe
> device can perform DMA to arbitrary physical memory, effectively
> bypassing all lockdown protections.
> 
> A malicious or compromised device can:
>    - Read kernel memory directly (encryption keys, credentials, secrets)
>    - Write to kernel memory directly (code patches, rootkits, backdoors)
>    - Circumvent all lockdown LSM checks (which run inside the kernel)
> 

Hi Mario,

Thanks for your contribution.

Let me first make my position clear: I'm not questioning the motivation
behind this series -- "without an IOMMU, PCI/PCIe devices can DMA to
arbitrary physical memory" is a real and legitimate concern. What I'd
like to raise for discussion is: whether this class of problem should be
addressed by lockdown in the first place. I'm honestly doubtful, so I'd
very much welcome other people's views.

My doubt comes from a mismatch between the threat this series is trying
to fix and the threat model lockdown was built around. Lockdown is, by
design, a way to protect the boundary between UID 0 and the kernel: it
came from the UEFI Secure Boot work, and it only limits the ways
software can reach the kernel -- /dev/mem, module loading, kexec, device
access via iopl/MSR/ACPI, and so on. The attacker it thinks about is a
privileged user (root) on the system. The problem in this series,
however, is about a malicious or bad hardware device, whose attack path
lives at the bus/hardware layer rather than in the software access paths
lockdown protects. To me, that looks like a different threat class with
a different owner.

It also does not look like a new question. The DMA-from-untrusted-device
problem was discussed in detail on linux-kernel back in May–June 2020,
in the "RFC Restrict the untrusted devices, to bind to only a set of
'whitelisted' drivers" thread:
	https://lore.kernel.org/all/CACK8Z6E8pjVeC934oFgr=VB3pULx_GyT2NkzAogdRQJ9TKSX9A@mail.gmail.com/

The conclusion of that discussion, as I read it, is that device-level
DMA threats are handled by the PCI/IOMMU line of defense -- the
untrusted-device marking in the PCI core, IOMMU/ACS settings, and
driver/device review -- not by lockdown. Interestingly, that thread also
  shows that "with an IOMMU or without an IOMMU" is not a clean split in
either direction: ATS and driver bugs can defeat DMA isolation even with
an IOMMU in place, while ACS Translation Blocking can still help on
systems without one. So if my reading is correct, "is there an IOMMU?"
is not a good test here. It does not really stop the DMA attack this
series worries about, and it goes beyond lockdown's original job.

Also worth noting: systems without an IOMMU are not rare. Many embedded
boards and virtual machines have no IOMMU at all. Lockdown, meanwhile,
is often enabled automatically in Secure Boot deployments, On such
systems, a panic-on-no-IOMMU check would turn a normal setup into a boot
failure.

Given what lockdown is for and the earlier discussion, the problem of a
device doing DMA without an IOMMU is probably not a problem for the
lockdown LSM to address, and that it belongs with the PCI/IOMMU
subsystems and platform policy instead.

I would welcome other views on this.

> This series adds a two-phase check to prevent booting with lockdown
> enabled and IOMMU disabled:
> 
> 1. Early check (in lockdown_lsm_init()): On x86, check the no_iommu
>     flag, which is set early by the "iommu=off" kernel cmdline option.
>     If lockdown is active and no_iommu is set, panic with a clear error.
> 
> 2. Late check (late_initcall): On all architectures, check
>     iommu_is_available() which returns true if any IOMMU driver
>     registered successfully. This catches cases where:
>     - IOMMU hardware is absent on the platform
>     - IOMMU was disabled by driver initialization failure
>     - IOMMU was not detected (broken firmware, missing ACPI tables)
> 
> This follows the precedent set by s390 UV code which panics when
> security cannot be guaranteed ("System security cannot be guaranteed
> unless the system panics now").
> 
> This also adds a generic iommu_is_available() API in the IOMMU
> subsystem, which is used by the lockdown check. Any IOMMU driver
> that successfully registers will automatically call
> iommu_set_available() from iommu_device_register().
> 
> Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org>
> 
> ---
> Mario Limonciello (AMD) (2):
>        iommu: Add iommu_is_available() API
>        security: lockdown: Prevent boot with lockdown but no IOMMU
> 
>   drivers/iommu/iommu.c        | 48 ++++++++++++++++++++++++++++++++
>   include/linux/iommu.h        | 14 ++++++++++
>   security/lockdown/lockdown.c | 65 ++++++++++++++++++++++++++++++++++++++++++++
>   3 files changed, 127 insertions(+)
> ---
> base-commit: 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4
> change-id: 20261014-lockdown-iommu-08c763d9f91dd
> 
> Best regards,
> --
> Mario Limonciello <superm1@kernel.org>
> 
>