企业官网建设流程全解析

做车品的网站,短视频运营培训学校,网站集约化建设方案,装修公司名称大全#x1f4fa; B站#xff1a;博主个人介绍 #x1f4d8; 博主书籍-京东购买链接*#xff1a;Yocto项目实战教程 #x1f4d8; 加博主微信#xff0c;进技术交流群#xff1a; jerrydev RK 系统安全#xff08;System-Verity / System-Encryption#xff09;原理与落…B站博主个人介绍博主书籍-京东购买链接*Yocto项目实战教程加博主微信进技术交流群jerrydevRK 系统安全System-Verity / System-Encryption原理与落地实战关键词Secure Boot、boot.img、Ramdisk(/init)、Device-Mapper、dm-verity、dm-crypt、luksmeta、vroot、switch_root、RPMB、security 分区本文围绕 Rockchip Linux SDK 中“系统安全System Security”方案系统讲清楚它到底保护什么、如何工作、如何在工程中配置与验证并给出从 PC 侧打包到板端启动的完整落地路径。本文关注点内核→rootfs 阶段的系统保护通过 Ramdisk 调用 Device-Mapper把系统分区映射成vroot再switch_root切换到最终系统。两条主线System-Verity完整性防篡改读到被改的块会 I/O error。System-Encryption保密性系统分区为密文离线无法解析启动时映射成明文vroot。重要定位本文所述“系统安全”主要保护的是rootfs/system 分区承载的块数据即根文件系统内容。boot.img/内核本体的保护属于Secure Boot / FIT 签名链路它是系统安全方案能够成立的前提条件两者分工不同但互相依赖。1. 先把概念对齐你到底在保护什么在 Rockchip 文档语境中“系统安全”并不等价于“Secure Boot”。它解决的是rootfs 内容不能被静态篡改完整性——对应 System-Verity。rootfs 内容不能被离线读取/复制保密性——对应 System-Encryption。它依赖一个“执行者”boot.img内的Kernel Ramdisk。Ramdisk 里的/init脚本在内核启动后第一时间运行决定是否启用 dm-verity验签/校验是否启用 dm-crypt解密最终把系统分区统一映射为vroot然后switch_root切换到真正的根文件系统。1.1 为什么文档强调 boot.img 必须处于 Secure Boot 保护下因为 Ramdisk 里的/init就是“系统安全的入口”。如果boot.img可被替换攻击者可以修改/init直接跳过 verity/encryption挂载原始分区替换root_hash或密钥处理逻辑甚至把系统引导到攻击者准备的 rootfs。因此Secure Boot解决“执行者可信”boot.img 未被替换。System Security本文解决“被保护对象可信/保密”rootfs/system 分区。一句话总结Secure Boot 让“执行校验/解密的人”可信System Security 让“最终被挂载的系统分区内容”可信或保密。2. 总体架构从 Security-System 到 vroot系统安全方案的核心链路非常稳定可以用一张文字化流程图记住eMMC/Flash ├── boot 分区boot.imgkernel ramdisk ←应由 Secure Boot 保护 └── system/rootfs 分区Security-System ←被保护对象 启动 1) kernel 启动 → 解压并挂载 ramdisk 2) ramdisk 执行 /init 3) /init 调用 device-mapper - veritySecurity-System → dm-verity → /dev/mapper/vroot - encryptSecurity-System(密文) → dm-crypt → /dev/mapper/vroot 4) mount /dev/mapper/vroot 5) switch_root 切换到最终系统释放 ramdisk 最终用户态对 / 的读写 → /dev/mapper/vroot → device-mapper → Security-System这里有两个非常关键的“理解抓手”vroot 是唯一入口最终系统看到的根分区不是原始分区而是/dev/mapper/vroot。device-mapper 是枢纽校验/解密都在块设备层完成文件系统只是“挂载在 vroot 上的上层”。3. 两条主线System-Verity vs System-Encryption3.1 System-Veritydm-verity完整性防篡改目标任何对系统分区的离线篡改都应在运行时被发现。原理块级完整性树PC 侧对系统镜像生成 Hash Tree文档中称 Hash-Map并计算 Root-Hash。Root-Hash 作为“信任根”放入boot.img的 Ramdisk 中。启动时Ramdisk 使用 Root-Hash 建立 dm-verity 映射。运行时读取某个 4K 块时内核会在 dm-verity 中校验该块对应 hash不一致则返回 I/O error。关键点verity 解决的是“是否被改过”不解决“内容是否泄露”。被篡改后通常表现为系统读文件报错、服务异常、甚至无法继续启动。3.2 System-Encryptiondm-crypt保密性防离线读取目标系统分区为密文拿到存储介质也无法解析 rootfs。原理块设备加密容器PC 侧用 dmsetup 建立 dm-crypt 容器把明文系统写入映射设备输出为密文镜像。启动时Ramdisk 提供 cipher 与 key通过 dmsetup 将密文分区映射成明文vroot。关键点encryption 解决“内容不可见”不天然等价于“不可篡改”。量产方案中密钥不能明文放在 Ramdisk需要结合RPMB 或 security 分区 OP-TEE 安全存储。3.3 两者能否同时存在对同一份 rootfs文档默认脚本通常按ENC_ENtrue/false二选一。理论上可以叠加先 dm-crypt 解密得到cryptroot再对cryptroot做 dm-verity 映射得到verityroot最终把verityroot作为vroot。工程建议先跑通 verity 或 encryption 其中之一再考虑“叠加”方案脚本复杂度、性能、异常处理都会提高。4. PC 侧打包生成可被 Ramdisk 驱动的“保护对象”系统安全不是只改 Ramdisk 就能生效。PC 侧必须先把系统镜像加工成 verity/encryption 需要的形态并产出security.info供后续 Ramdisk/init配置使用。4.1 System-Verity对 rootfs 镜像附加 Hash-Map并保存 Root-Hash核心流程选择输入系统镜像通常是rootfs.img或 buildroot 输出的rootfs.ext2/ext4。计算hash_offset示例以 1MiB 对齐并在镜像尾部预留空间。veritysetup format写入 Hash-Map并输出 Root-Hash。生成security.info保存root_hash与hash_offset。工程注意veritysetup format会修改镜像文件写入 hash 区建议对镜像副本操作。security.info是 Ramdisk 配置的输入之一不存在就无法完成 init 配置。4.2 System-Encryption创建加密容器并输出密文系统镜像核心流程读取明文系统镜像。准备密钥key.txt与 cipher 名称如aes-cbc-plain。创建输出文件密文镜像并绑定 loop。dmsetup create建立 crypt 映射。dd把明文写入/dev/mapper/name写入即加密。清理映射与 loop。生成security.info保存cipher与key开发阶段可用量产阶段应改为安全存储。工程注意输出密文镜像无法直接 mount必须通过 dmsetup 建立映射才能读出明文文件系统。cipher 与 key 长度必须匹配例如 AES-256-CBC 需要 32 byteshex 64 字符XTS 模式通常需要双倍 key。5. Ramdisk 的角色/init 做“校验/解密 vroot 统一出口”在 Rockchip Linux SDK 的实现中Ramdisk 是由 Buildroot 生成的小系统与 Kernel 一同打包进boot.img。它在系统安全方案中的职责非常明确读取配置security.info、分区信息、工作模式verity/encrypt。准备内核能力确保 device-mapper、dm-verity/dm-crypt 等内核模块或内建选项可用。建立 vrootverity使用 Root-Hash 与 hash_offset 建立 dm-verity 映射。encrypt使用 cipher 与 key 建立 dm-crypt 映射。挂载与切根挂载/dev/mapper/vroot执行switch_root。释放自身切根后 ramdisk 不再作为根文件系统。5.1 init.in → init为什么需要“模板渲染”文档中的做法是buildroot/board/rockchip/common/security-ramdisk-overlay/init.in作为模板。通过脚本cp init.in init后用sed把变量填充进去ENC_EN、OFFSET、HASH、CIPHER、SECURITY_STORAGE 等。这样做的目的把“PC 侧产物”security.info转化为“启动期可执行配置”。保持同一份模板支持多种模式verity/encrypt。5.2 关于SECURITY_STORAGERPMB/SECURITYSystem-Encryption 在量产时通常要求密钥不能明文存放在 Ramdisk。启动时由 Ramdisk 从某个临时介质如 misc取到密钥材料转存到RPMB或security 分区随后清理临时介质。这是为了避免攻击者只要读出boot.img就获得密钥。6. 实战路径从镜像加工到板端验证的完整步骤本节给出一条“从 PC 到板端”的通用落地流程。你可以按自己的 SDK 结构替换路径。说明本流程刻意不展开 OTP 烧录等不可逆步骤开发阶段重点先验证机制是否正确。6.1 选择被保护对象通常是 rootfs 分区镜像常见候选output/firmware/rootfs.img打包输出buildroot/output/xxx/images/rootfs.ext2Buildroot 生成的 rootfs判断原则最终刷进 rootfs 分区的是什么镜像就对那份镜像做 verity/encryption。6.2 System-Verity 方案落地步骤备份输入镜像建议运行veritysetup format生成 Root-Hash 与 hash_offset写security.info配置 Ramdisk initENC_ENfalse填入 OFFSET/HASH重新打包 Ramdisk → 重新生成 boot.img刷机或更新 boot/rootfs 分区板端验证/dev/mapper/vroot是否存在根分区是否来自 vroot篡改后是否出现 I/O error6.3 System-Encryption 方案落地步骤生成key.txt开发阶段可用 openssl rand量产阶段应迁移到安全存储PC 侧用 dmsetup 创建加密容器输出密文rootfs_enc.img生成security.infocipher/key配置 Ramdisk initENC_ENtrue填入 CIPHER/SECURITY_STORAGE 等重新打包 Ramdisk → 重新生成 boot.img刷机rootfs 分区刷入密文镜像板端验证直接挂载原始 rootfs 分区应无法解析密文/dev/mapper/vroot可挂载并切根成功7. 如何验证“真的生效”最小检查清单系统安全是否生效最重要的是验证“最终根分区来自 vroot”。7.1 运行时结构验证在最终系统中执行查看根挂载来源mount | grep on / 期望/来自/dev/mapper/vroot或同等映射名查看 mapper 设备ls -l /dev/mapper期望存在vroot查看 dm 状态dmsetup status vroot7.2 Verity 的行为验证篡改触发 I/O error思路离线修改 rootfs 分区某个块内容。再启动或在运行时访问该文件期望出现 I/O error。注意这属于破坏性验证建议在测试介质上进行。7.3 Encryption 的行为验证密文不可直接 mount思路在 PC 上尝试直接挂载密文镜像应失败。用同样的 cipher/key 建立 dmsetup 映射后才可以 mount 并看到正常目录结构。8. 常见问题与定位方法8.1security.info找不到现象source security.info: No such file or directory。结论PC 侧前置步骤未执行或路径不正确。建议在生成脚本执行目录确认security.info的存在与内容。使用find . -name security.info明确位置。8.2sed报错、变量替换未生效常见原因命令行复制时把两条sed粘在同一行。模板字段与替换字段不一致例如模板是ROOT_HASH但你替换HASH。建议grep -n ENC_EN\|OFFSET\|HASH\|CIPHER\|SECURITY_STORAGE init.in init对比。8.3 rootfs 镜像被 veritysetup 写入时 I/O error常见原因目标镜像不可写权限/只读/构建系统管理产物。宿主机磁盘空间不足。hash_offset 单位理解不一致bytes vs sectors具体依赖 veritysetup 版本。建议对镜像副本操作。df -h检查空间。veritysetup --help查看 hash-offset 解释。8.4 你看到 rootfs 镜像依然能被普通方式挂载是否说明 verity 无效不说明。原因verity 的 Hash-Map 附加在镜像尾部不改变镜像前部的文件系统结构。普通 mount 仍然会把它当作正常文件系统。真正生效的标志运行时根分区必须来自/dev/mapper/vroot并且访问篡改块会 I/O error。8.5 Yocto 能不能生成 Ramdisk没有 Buildroot 是否无法做系统安全不必拘泥于“Buildroot 还是 Yocto”。关键在于需要一个 initramfs/ramdisk里面包含/init、必要工具dmsetup/veritysetup/luksmeta/busybox 等以及配置文件。因此Yocto 完全可以生成 initramfs也可以在 initramfs 中实现同样的/init逻辑。Rockchip SDK 给的是 Buildroot 路线属于“参考实现”机制本身与发行构建系统无关。8.6 开发阶段不烧 OTP能不能先做系统安全可以做“功能层面”的系统安全验证verity/encryption 的链路能跑通、vroot能建立、switch_root能切换。但要明确边界未启用 Secure Boot 时攻击者可替换 boot.img从而绕过这套机制。工程建议开发阶段先验证机制、验证脚本与镜像流程。量产阶段再把 Secure Boot含 boot.img 保护纳入闭环。9. 最佳实践如何把“可运行”提升到“可量产”9.1 把链路闭环Secure Boot System Security建议的闭环目标Secure Boot 确保 boot.img 不可被替换。verity/encryption 确保 rootfs/system 不可被篡改或不可被离线解析。9.2 密钥管理从开发明文到量产安全存储开发阶段为了验证链路常见做法是security.info里明文保存 cipher/key。量产阶段应演进为密钥或密钥材料存入 RPMB 或 security 分区。Ramdisk 通过 OP-TEE 安全接口获取或解封密钥。9.3 只读根文件系统与更新策略verity 更适合“只读根系统”例如 squashfs/erofs verity更新时整体替换镜像并重新生成 hash。encryption 更关注“保密”更新时需要考虑密钥轮换策略是否每版本不同 key。A/B 或 OTA 流程中密钥与元数据如何同步。10. 总结一张表记住核心差异维度System-Verity (dm-verity)System-Encryption (dm-crypt)主要目标完整性防篡改保密性防离线读取PC 侧处理生成 hash tree root_hashHash-Map 可附加镜像尾部创建加密容器并写入明文输出密文镜像Ramdisk 输入root_hash、hash_offsetcipher、key量产应来自安全存储启动时动作建立 dm-verity 映射 →vroot建立 dm-crypt 映射 →vroot篡改表现访问到被改块 → I/O error不一定立刻报错取决于是否叠加完整性机制是否能直接 mount 原镜像可以镜像仍是正常 FS不可以密文不可解析量产关键点root_hash 必须可信依赖 boot.img 可信密钥必须安全存储RPMB/security/OP-TEE11. 附录建议的“最小验证步骤”模板11.1 Verity 的最小验证启动后mount | grep on / →/dev/mapper/vrootdmsetup status vroot篡改验证离线修改 rootfs 分区块 → 启动/访问文件 → I/O error11.2 Encryption 的最小验证PC 上直接 mount 密文镜像失败用 dmsetup 映射后 mount 成功启动后/dev/mapper/vroot存在/挂载来自 vroot结语Rockchip 的“系统安全”方案本质是用 Ramdisk 把系统分区统一封装成 vroot然后以 device-mapper 作为安全边界的执行层。理解了“谁是执行者boot.img”与“谁是被保护对象rootfs/system”并掌握 PC 侧镜像加工 Ramdisk/init配置 板端验证三件事系统安全就能在工程中稳定落地。B站博主个人介绍博主书籍-京东购买链接*Yocto项目实战教程加博主微信进技术交流群jerrydev