内核DMA保护是Windows 10/11通过IOMMU阻止未授权外围设备执行DMA的安全机制，仅支持Thunderbolt/USB4等PCIe热插拔设备，不防1394/FireWire等旧接口，需驱动支持DMA重映射且默认锁定时禁用不兼容设备。
物理层面的内核攻击（如通过恶意外设、JTAG调试接口、PCIe热插拔设备或直接内存访问DMA）往往依赖于未受控的调试能力或低权限硬件访问通道。限制这些接口不是“关掉一个开关”就能完成的事，而是一套分层收敛策略：从硬件使能、固件配置、内核启动参数到运行时保护机制，环环相扣。
禁用或锁定硬件调试接口
这是最底层也是最关键的防线：
- 在BIOS/UEFI中关闭JTAG、SWD、ICE等调试端口；部分服务器平台（如Intel TXT、AMD SVM）支持“调试禁用位”（Debug Lock），一旦置位，即使物理接触也无法启用调试功能
- 禁用PCIe AER（Advanced Error Reporting）和ACS（Access Control Services）绕过检测——某些DMA攻击会伪造AER事件触发内核异常处理路径，进而获得执行权
- 对支持TPM 2.0或Intel PTT的平台，启用Boot Guard或Measured Boot，确保从固件到内核镜像的完整链式验证，防止引导阶段植入恶意调试桩
内核启动参数强制隔离调试能力
即使硬件接口物理存在，也可通过启动约束使其失效：
- 添加nokaslr必须配合kpti=1 pti=on smap=1 smep=1——KASLR关闭后更需强化页表隔离与执行防护，否则攻击者可轻易定位内核符号并覆盖关键函数指针
- 明确禁用kgdb相关功能：kgdboc=none kgdbwait=0；若必须保留，仅允许串口（kgdboc=ttyS0,115200）且配合console=ttyS0，避免USB或网络调试通道暴露面扩大
- 禁用未签名模块加载：module.sig_unenforce=0 + enforcemodulesig=1，防止攻击者通过物理接入加载带调试后门的驱动
运行时内核自我保护加固
防御已突破物理边界、进入内存空间的攻击者：
- 启用CONFIG_STRICT_KERNEL_RWX和CONFIG_STRICT_MODULE_RWX，确保代码段不可写、只读数据不可执行——这是对抗ROP/JOP攻击的基础内存布局防护
- 开启CONFIG_HARDENED_USERCOPY和CONFIG_FORTIFY_SOURCE，拦截越界copy_to_user/copy_from_user操作，阻断DMA映射导致的内核堆溢出利用
- 限制/dev/mem和/dev/kmem访问：CONFIG_STRICT_DEVMEM=y，并确保iomem=strict启动参数生效，使非白名单内存区域（如PCI BAR、GPU显存）无法被用户态mmap
监控与响应物理接入行为
不单靠“堵”，也要“察”：
- 启用CONFIG_DRM_I915_CAPTURE_ERROR（Intel GPU）或对应厂商驱动的错误捕获，某些DMA攻击会触发GPU异常，日志中出现大量"GPU hang"或"page fault in DMA buffer"是早期信号
- 通过dmesg -w或journalctl -k -f持续监听"PCIe Bus Error"、"iommu: DMAR:[fault]"类消息，这类日志常出现在恶意PCIe设备触发IOMMU故障时
- 部署kernel lockdown模式（lockdown=confidentiality），在安全启动成功后禁止任何运行时内核修改行为，包括kprobe、ftrace动态patch、模块卸载等调试操作
