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

[Mario Limonciello <superm1@kernel.org>]

On 11/11/26 01:30, Xiu Jianfeng wrote:
> 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

I do agree with you; this is a different type of threat model that's 
being addressed.

> a different owner.

The problem I see is that in today's day it's incredibly easy to hotplug 
an external PCIe device and not "realize" that it's malicious.  For 
example if I leave a dock on my desk and someone inserts malware into it
I might think it's perfectly fine.

The current mitigation that exists is that in the Linux ecosystem we 
don't turn on PCIe tunneling "automatically" unless the IOMMU is active.

Nominally this happens by way of 'bolt' userspace writing a sysfs file 
after it confirmed IOMMU was enabled both pre-boot and by the kernel.

But come back to me being a user.  If I have the IOMMU off already for
whatever reason I'm used to plugging in the dock and accepting the popup 
asking me to authorize it.  Now a malicious device comes along, that's 
on me to know about?

I feel it's not entirely out of the realm of possibility that such a 
malicious device could subvert lockdown (let alone other bad things that 
can happen).

Thus; lockdown is a very convenient tie in to claim security of the 
system against both user and hardware attacks.

> 
> 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 

Thanks for sharing.

> it goes beyond lockdown's original job.

Right.

> 
> 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.

How would you feel about at least blocking the user from turning off 
IOMMU (if it's present on the system) via the kernel command line while 
lockdown was enabled?

Thinking about the case where most distros enable lockdown by default, 
this will strenghten it's use without much downside that I can see.

At least on a properly configured system that contains an IOMMU it would 
prevent a user from subverting lockdown with a malicious device during 
the boot sequence.
> 
>> 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>
>>
>>
>