解读

边缘节点往往部署在无人值守的机房、基站或车间，TPM（可信平台模块）一旦物理损坏或 BIOS 报错，节点会拒绝按“可信启动链”继续，导致磁盘加密密钥无法自动解封、系统进入 dracut 紧急模式，Docker 服务自然无法拉起。面试官想考察的是：

1. 你是否理解 Linux 早期启动与容器启动的耦合点；
2. 能否在“安全机制失效”与“业务连续性”之间做权衡，给出可落地、可回滚、符合国内安全合规的应急方案；
3. 是否具备边缘场景特有的“远程+无人”运维意识。

知识点

• TPM2 与 LUKS 的绑定关系：systemd-cryptenroll、clevis、dracut 配置
• 内核启动参数：rd.break、init=/bin/bash、systemd.mask=
• Docker 的 daemon.json 与 live-restore：保证引擎不依赖系统服务即可重启容器
• 国产加密卡/国密芯片替代：天津飞腾、海光、兆芯平台常用的SDF 接口
• 远程串口与 IPMI SOL：在边缘盒子无 KVM 时唯一通道
• 国密算法合规：GM/T 0012-2020、GB/T 39786-2021 对“应急解密”要求记录审计日志并事后补录原因

答案

1. 确认故障范围
   通过 IPMI SOL 或 4G 串口登录，观察 dracut 报错“TPM2_PCR_READ failed”，判定为 TPM 硬失效。

2. 临时绕过可信启动（不破坏数据）
   重启进入 GRUB，在启动项末尾加 rd.break=pre-mount 进入 initramfs 紧急 shell；
   手工挂载原 /boot 与 /etc/luks-keys 分区，使用提前离线备份的 LUKS 密钥文件执行：

   cryptsetup open /dev/sda3 root --key-file=/etc/luks-keys/slot0.key
   

   随后 exit 继续启动，系统可正常进入 multi-user.target。

3. Docker 引擎自恢复
   确保 /etc/docker/daemon.json 已开启 "live-restore": true，这样即使 systemd 重启，容器不会强制下线；
   执行 systemctl start docker 后，边缘业务容器按 restart-policy 自动恢复。

4. 持久化应急通道
   为避免二次重启再次卡死，在 /etc/crypttab 中新增临时条目，把 slot0.key 放入 USBKey 并设置“nofail”，实现“插 Key 就启动”的运维模式；
   同时把 TPM 相关 systemd 单元 mask 掉：

   systemctl mask tpm2-abrmd.service
   

5. 合规与审计
   登录堡垒机，在**《异常启动记录表》**补录“TPM 损坏+应急解密”原因，保存串口日志与审计日志至少 180 天，满足等保 2.0 要求；
   48 小时内申请更换主板或焊接 TPM 芯片，恢复可信链。

拓展思考

• 双因子备份：边缘节点出厂时同步把 LUKS 密钥写入国密 USBKey+堡垒机密钥管理系统，实现“硬件失效即插即启”，但 USBKey 需铅封、一次性封条，防止运输途中被掉包。
• 软件 TPM 过渡：若边缘 CPU 支持 Intel PTT 或 AMD fTPM，可在 BIOS 关闭独立 TPM，临时切换为固件 TPM，再重新 enroll PCR7，实现“零硬件更换”快速恢复。
• 容器级加密下移：把机密数据从宿主机 LUKS 下沉到容器内 Vault+国密 SM4 信封加密，即使宿主持久化解密失败，业务 Pod 也能通过 KMS 拉取会话密钥继续运行，把“启动阻断”降级为“功能降级”。