random: crng init 卡死几分钟的 haveged/rng-tools 加速方案

crng init 卡住是因内核启动早期熵不足，需等待足够随机性；常见于虚拟机、容器等缺乏硬件RNG的环境，表现为启动慢、ssh延迟、/proc/sys/kernel/random/entropy_avail长期低于100。

为什么 crng init 卡住几分钟？

linux 内核在启动早期需要足够熵（entropy）来初始化密码学随机数生成器（CRNG），否则会阻塞直到收集到足够随机性。现代虚拟机、容器或无硬件 RNG 的嵌入式设备常因缺乏熵源而卡在 random: crng init done 之前，表现为系统启动慢、SSH 登录延迟、openssl rand 等命令 hang 住。

常见现象包括：dmesg | grep -i random 显示长时间停留在 random: crng init not ready；cat /proc/sys/kernel/random/entropy_avail 长期低于 100（理想应 >200）。

haveged vs rng-tools：选哪个更靠谱？

二者都用于补充熵池，但机制和适用场景不同：

• haveged 基于 CPU 时间戳抖动提取熵，启动快、依赖少，适合大多数 x86_64 虚拟机和云实例
• rng-tools 依赖硬件 RNG（如 Intel RDRAND、amd SVM），需确认 CPU 支持且内核已启用 CONFIG_HW_RANDOM_INTEL 或类似选项；否则可能静默失效

实际建议：

• 优先试 haveged：安装后默认即用，无需额外配置硬件
• 若已有可信硬件 RNG（如 AWS c5/c6、GCP e2，或物理服务器带 TPM/RDRAND），再启用 rng-tools 并验证是否真正注入熵（rngd -f -v 查日志）
• 切勿同时运行两者，避免熵源冲突或重复注入导致内核熵计数异常

实操：快速启用 haveged 并验证效果

ubuntu/debian：

sudo apt install haveged sudo systemctl enable haveged sudo systemctl start haveged

centos/RHEL 8+：

sudo dnf install haveged sudo systemctl enable haveged sudo systemctl start haveged

验证是否生效：

• 检查服务状态：systemctl status haveged 应为 active (running)
• 查看熵值变化：watch -n1 'cat /proc/sys/kernel/random/entropy_avail'，几秒内应从
• 观察内核日志：dmesg | grep -i "crng|random"，确认出现 random: crng init done

注意：haveged 默认以非特权用户运行，若 SELinux 启用，可能需临时设为 permissive 模式排查权限问题；某些精简镜像（如 Alpine）需手动编译或换用 rng-tools。

/dev/random 仍阻塞？检查内核参数和容器环境

即使熵池充足，某些旧应用或容器仍可能因以下原因卡住：

• 内核启用了 random.trust_cpu=0（尤其在较新 kernel 中默认开启），抑制了 RDRAND 等硬件熵源
• 容器未挂载 /dev/random 和 /dev/urandom（docker 默认已挂载，但 LXC/LXD 或自定义 runtime 可能遗漏）
• systemd 服务设置了 RestrictAddressFamilies=AF_NETLINK 等限制，间接影响熵获取路径

临时缓解可加启动参数（仅调试用）：

random.trust_cpu=1

但更稳妥的做法是确保 haveged 运行 + 容器共享宿主机的 /dev/random（Docker 无需额外操作，podman 需加 --device /dev/random:/dev/random）。

熵补充不是“越快越好”，而是要稳定、可信、不干扰内核 CRNG 初始化流程。最容易被忽略的是：很多云平台镜像已预装 haveged，但服务被 disable；还有人误以为装了就万事大吉，却没验证 entropy_avail 是否真实上升。