acpi表（dsdt/ssdt）是固件与os协商硬件资源的核心数据结构，被恶意篡改可导致设备劫持、驱动隐藏及安全启动绕过；需通过内存写保护、哈希绑定pcr、运行时监控与存储隔离等多层机制防护。
系统硬件描述表（如ACPI的SSDT、DSDT，或UEFI环境中的HOB、Configuration Tables）是固件与操作系统协商硬件资源的关键数据结构。一旦被恶意篡改，攻击者可劫持设备初始化流程、隐藏恶意驱动、绕过安全启动校验，甚至重定向内存映射——这正是LoJax、MoonLight等固件级恶意软件惯用的手法。
锁定关键表的写入权限
多数x86平台在UEFI启动早期会将硬件描述表加载至RAM中，但默认未设写保护。需在PEI或DXE阶段调用SetMemoryAttributes()（UEFI 2.7+）或直接操作页表，将SSDT/DSDT所在页标记为只读（EFI_MEMORY_RO）。若平台支持SMAP/SMEP，还应启用以阻止内核态代码执行用户态地址上的表数据。
- 实操建议：在自定义UEFI驱动中，定位
gEfiAcpiTableGuid或gEfiHobListPointerGuid后，获取其物理地址并调用内存属性设置接口 - 注意：部分OEM BIOS会动态生成SSDT，需确认表是否驻留在固定地址；否则应在每次生成后立即加锁
签名验证与哈希绑定
硬件描述表本身不签名，但可通过“间接绑定”实现可信锚定：将表内容哈希值嵌入固件签名镜像（如UEFI Secure Boot中签名的FV），或在Boot Guard/Intel TXT环境中将其纳入PCR（Platform Configuration Register）扩展链。这样，任何修改都会导致启动时PCR值不匹配，触发TPM平台策略拒绝继续引导。
- 典型路径：DSDT → SHA256 → 写入PCR0（Boot ROM）→ PCR1（Option ROM）→ PCR2（ACPI Tables）→ PCR7（Secure Boot Policy）
- 对ARM平台，可利用ARM TrustZone的Secure Monitor在BL2阶段校验ATF（Arm Trusted Firmware）加载的DTB完整性，并与固化在ROM中的哈希比对
运行时监控与异常拦截
仅靠启动时保护不够——攻击者可能在OS加载后通过PCIe配置空间、MMIO或DMA重写ACPI表。需部署轻量级运行时防护：
- 启用Intel VT-d或AMD-Vi，隔离ACPI表所在内存区域，禁止非特权DMA访问
- 在内核模块中注册
acpi_os_map_table钩子，对每次映射操作记录虚拟地址与物理地址对应关系，并比对初始哈希 - 利用KVM或Hyper-V的Nested Page Tables，在虚拟机场景下将ACPI表页设为“不可执行+只读”，防止guest OS篡改
物理层隔离与存储保护
若硬件描述表从SPI Flash加载（如某些嵌入式SoC的BootROM直接解析FDT），必须同步保护存储介质：
- 启用Flash控制器的WP#引脚硬件写保护，或通过SPI寄存器配置Block Protect位（BP0/BP1/BP2）锁定ACPI相关扇区
- 对含SSDT的UEFI Capsule更新包，强制要求带RSA-2048签名且公钥已预置在ROM中；拒绝无签名或签名无效的更新
- 在SOC级设计中，将ACPI表存储于OTP（One-Time Programmable）区域，或使用eFuse熔断机制固化关键字段（如_FADT中复位寄存器地址）
