硬件攻击指利用漏洞固件、恶意pcie设备或带毒驱动在内核加载阶段植入后门，表现为dmesg中异常设备识别、dma越权、iommu绕过及固件行为失常等痕迹，需结合基线比对与多源日志交叉验证。
内核层没有“硬件攻击”这个概念——硬件本身不会主动发起攻击，也不会被黑客远程“黑进主板芯片”后执行恶意指令。所谓“来自硬件的攻击”，实际是指利用存在漏洞或后门的固件（如UEFI/BIOS、网卡ROM、硬盘控制器、IPMI基板管理控制器）、恶意PCIe设备（如BadUSB变种、恶意FPGA卡）或带毒驱动，在内核加载阶段植入持久化后门。这类行为会在dmesg中留下异常痕迹，但需要结合上下文谨慎判断，不能单凭一两条warn就断言“被攻击”。
盯住设备初始化阶段的非常规行为
真正的硬件级恶意行为往往藏在设备“自报家门”和驱动加载环节。正常设备会按标准流程上报厂商ID、设备类、资源分配情况；而恶意设备可能伪造ID、申请异常IO端口、触发非法DMA映射或绕过IOMMU检查。
- 运行 dmesg -T | grep -E "(pci|usb|platform|acpi)" | head -50，重点看系统刚启动时的前几十条记录
- 留意出现但无对应厂商信息的设备，例如："PCI bridge: Device 1234:5678"（1234:5678不是任何公开PCI ID）
- 警惕反复重置或probe失败却不报错的设备，比如："nvme 0000:05:00.0: timeout on controller reset" 后紧跟 "nvme 0000:05:00.0: pci_pm_resume+0x0/0xf0 returned 0" —— 表明设备在恢复时悄悄绕过了校验
识别驱动加载中的隐蔽异常
恶意固件常通过合法驱动入口注入代码，因此dmesg里不会显示“恶意模块已加载”，而是表现为驱动行为失常：超时延长、寄存器值异常、中断号冲突、或与硬件规格明显不符的配置。
- 搜索：dmesg -T | grep -i "timeout\|dma\|iommu\|bar\|resource.*conflict"
- 特别注意含 "iommu=off" 或 "intel_iommu=disabled" 的启动参数日志——这不是攻击痕迹本身，但为攻击创造了条件，dmesg里会明确记录该配置生效
- 发现类似 "eth0: invalid MAC address, using random" 或 "iwlwifi 0000:02:00.0: firmware version not supported" 且设备实际能联网，说明固件可能已被篡改
比对基线，发现“多出来”或“少掉”的东西
单看一次dmesg意义有限。攻击者若控制了固件，通常会让设备表现得“基本可用”，只在特定条件下激活后门。所以必须有可信基线做对比。
- 在新装系统、未连外网、未插第三方设备时，运行 dmesg -T > /root/dmesg_baseline.log 保存初始状态
- 后续怀疑异常时，再执行相同命令生成新日志，用 diff /root/dmesg_baseline.log dmesg_current.log 查看差异
- 重点关注新增的 unclaimed device、unknown hardware、failed to disable ASPM（ASPM是节能功能，禁用它常为规避DMA防护）等字段
配合其他内核证据交叉验证
dmesg只是线索入口，不能单独定性攻击。需联动查看：
- /sys/firmware/acpi/tables/ 下是否存在异常DSDT/SSDT表（需用iasl反编译分析）
- lspci -vvv -s XX:XX.X 输出中是否出现未声明的Capability项（如恶意设备添加了自定义PCI Capability ID）
- cat /proc/iommu_groups/*/devices 看是否有设备被错误地分到同一IOMMU组，导致DMA越权访问
- 检查 journalctl -k -b | grep -i "efi\|uefi\|smbios" 是否有固件更新失败、SMAP/SMEP被意外关闭等低层异常
