海思HI3531D上解决udev启动报错‘uninitialized urandom read’的完整实战记录

海思HI3531D平台解决udev启动报错的深度实战指南

问题背景与现象分析

在嵌入式Linux系统开发中，系统启动阶段的每一个警告信息都值得开发者关注。近期，我们在海思HI3531D平台上部署定制系统时，发现了一个看似无害却令人困扰的问题——系统启动日志中反复出现以下警告：

random: udevd: uninitialized urandom read (16 bytes read) random: udevd: uninitialized urandom read (16 bytes read)

这个警告虽然不会导致系统崩溃，但会显著拖慢启动速度，同时污染系统日志，给后续的调试工作带来不便。经过深入分析，我们发现问题的根源在于Linux随机数子系统与udev设备管理器的启动时序冲突。

关键问题点：

• 系统启动时，/dev/random和/dev/urandom设备需要足够的熵值才能正常工作
• 嵌入式设备由于缺乏物理随机事件源（如键盘鼠标输入、磁盘活动等），熵池初始化缓慢
• udev服务启动时急需随机数生成设备节点，但此时熵池尚未准备就绪

解决方案的探索与评估

面对这个问题，我们调研了多种可能的解决方案，每种方案都有其适用场景和局限性：

方案一：内核启动参数调整

最直接的方法是尝试通过内核启动参数解决：

random.trust_cpu=on

这个参数告诉内核信任CPU内置的硬件随机数生成器（如果存在）。然而，在实际测试中我们发现：

• HI3531D的ARM架构处理器可能不具备完整的硬件随机数生成支持
• 即使添加该参数，系统启动时仍然出现相同的警告
• 部分开发板可能需要在uboot阶段额外配置才能启用此功能

方案二：内核补丁修改

另一种思路是修改内核源码，调整随机数子系统的行为：

1. 修改drivers/char/random.c中的熵池初始化逻辑
2. 调整/dev/random和/dev/urandom的阻塞行为
3. 重新编译内核并部署

这种方法虽然理论上可行，但存在明显缺点：

• 需要深入理解Linux内核随机数子系统
• 修改核心代码可能引入不可预知的安全风险
• 每次内核升级都需要重新适配补丁
• 不符合嵌入式系统"最小修改"的原则

方案三：haveged方案

经过综合评估，我们最终选择了haveged作为解决方案。haveged是一个轻量级的守护进程，它通过收集处理器运行时的硬件波动来生成熵值。其优势在于：

• 专门为解决嵌入式系统熵值不足问题设计
• 资源占用极小，适合资源受限的嵌入式环境
• 无需修改内核，部署简单
• 开源项目，社区支持良好

haveged的交叉编译与部署

在海思HI3531D平台上部署haveged需要特别注意交叉编译环境的配置。以下是详细步骤：

1. 准备交叉编译工具链

确保已安装海思官方提供的交叉编译工具链。对于HI3531D平台，通常使用：

export PATH=/opt/hisi-linux/x86-arm/aarch64-himix200-linux/bin:$PATH

2. 下载并解压haveged源码

建议使用官方稳定版本（当前最新为1.9.2）：

wget https://github.com/jirka-h/haveged/archive/refs/tags/v1.9.2.tar.gz tar -xzvf v1.9.2.tar.gz cd haveged-1.9.2

3. 配置编译选项

针对嵌入式系统的特殊需求，我们采用静态编译方式：

./configure \ --host=aarch64-himix200-linux \ --prefix=$(pwd)/install \ --enable-static \ --disable-shared

关键参数说明：

4. 编译与安装

make -j$(nproc) make install

编译完成后，生成的二进制文件位于install/sbin/haveged。

5. 集成到目标系统

将编译好的haveged二进制文件部署到目标板：

cp install/sbin/haveged ${ROOTFS}/sbin/

系统启动脚本优化

为了确保haveged在udev之前启动，我们需要修改启动脚本。以下是针对海思平台的优化方案：

1. 修改udev启动脚本

通常位于/etc/init.d/S01udev，修改内容如下：

#!/bin/sh # 启动haveged熵值生成器 haveged -F -d 32 -w 1024 --verbose=1 & # 确保熵值生成器已启动 sleep 1 # 标准udev启动流程 mkdir /dev/pts mount -t devpts devpts /dev/pts mount -t tmpfs tmpfs /run mkdir -p /dev/.udev udevd --daemon udevadm trigger mdev -s

haveged启动参数解析：

• -F：前台运行模式（便于调试）
• -d 32：设置数据缓存大小为32KB
• -w 1024：设置写缓冲区大小为1024字节
• --verbose=1：输出基本信息级别日志

2. 验证启动顺序

使用以下命令检查服务启动顺序：

ps -ef | grep -E 'haveged|udevd'

正确顺序应该是haveged先于udevd启动。

效果验证与性能评估

完成上述修改后，重新启动系统，观察日志输出：

haveged starting up haveged: ver: 1.9.2; arch: generic; vend: ; build: (gcc 7.3.0 CTV); collect: 128K haveged: cpu: (VC); data: 32K (P); inst: 16K (D); idx: 10/40; sz: 15464/71260 haveged: tot tests(BA8): A:1/1 B:1/1 continuous tests(B): last entropy estimate 7.99538 haveged: fills: 0, generated: 0 random: crng init done udevd[985]: starting version 3.2.9 udevd[986]: starting eudev-3.2.9

关键改进点：

1. 启动时间缩短约30%（具体数值因系统配置而异）
2. 系统日志中不再出现"uninitialized urandom read"警告
3. 所有依赖随机数的服务（如SSL/TLS）都能正常启动

进阶优化与注意事项

对于追求极致启动速度的嵌入式系统，还可以考虑以下优化：

1. 熵值预生成

在系统镜像构建阶段预生成熵值文件：

dd if=/dev/random of=${ROOTFS}/etc/random-seed bs=512 count=1 chmod 600 ${ROOTFS}/etc/random-seed

然后在启动脚本中添加：

# 恢复预生成的熵值 if [ -f /etc/random-seed ]; then cat /etc/random-seed > /dev/urandom fi

2. haveged资源限制

在资源极度受限的系统上，可以调整haveged的资源使用：

haveged -F -d 16 -w 512 --verbose=0

3. 安全性考量

虽然haveged生成的熵值足够大多数应用场景使用，但对于高安全性要求的场景：

• 考虑结合硬件随机数生成器（如果可用）
• 定期检查haveged的运行状态
• 监控系统熵值水平：

cat /proc/sys/kernel/random/entropy_avail

常见问题排查

在实际部署过程中，可能会遇到以下问题：

1. haveged启动失败

现象：haveged无法启动或立即退出

可能原因：

• 静态链接不完整
• 权限不足
• 系统资源限制

解决方案：

# 检查文件属性 ls -l /sbin/haveged # 使用strace调试 strace /sbin/haveged -F

2. udev仍然报错

现象：haveged已启动，但udev仍然报错

可能原因：

• 启动顺序不正确
• 熵值生成速度不足

解决方案：

# 增加haveged启动后的等待时间 sleep 2 # 调整haveged参数增加熵值生成速度 haveged -F -d 64 -w 2048

3. 系统资源占用过高

现象：haveged占用过多CPU资源

解决方案：

# 限制CPU使用率 haveged -F -n 1024 -d 16 -w 512

方案对比总结

在实际项目中，我们最终选择了haveged方案，因为它提供了最佳的平衡点——足够的熵值生成能力、较低的系统开销和简单的维护方式。特别是在海思HI3531D这类资源受限的嵌入式平台上，静态编译的haveged表现尤为出色。