☰

无论 force_ro 值如何，u-boot 分区环境变量始终可写

tag-icon • tag-icon linux bootloader boot-partition yocto-project
无论 force_ro 值如何，u-boot 分区环境变量始终可写

在我的平台上，u-boot 环境变量始终可以修改。目前，我将的值更改为force_ro“1”，这将权限模式设置为只读。此更改反映在命令的输出中lsblk。但是，即使在重新启动设备后，我仍然可以将值写入启动分区，并且更改仍然存在。

以下是我的测试结果：

$ cat /sys/block/mmcblk0boot1/force_ro
1
$ fw_setenv primary 2
$ fw_printenv primary
2

以下是有关我的平台的一些详细信息：

  • 交叉编译器：Yocto EL40（Kirkstone）
  • 引导加载程序：u-boot
  • U-boot 来源：git://github.com/nxp-imx/uboot-imx.git；protocol=https
  • U-boot 源码分支：lf_v2022.04
  • fw_setenv以及fw_printenvYocto 中的软件包版本：libubootenv_0.3.2

硬件详细信息：

  • 系统架构：arm
  • CPU：armv8
  • SoC：imx8m

有人能根据 的值建议一个解决方案来使我的启动分区变为只读吗force_ro？

我检查了所有的 u-boot 配置，尝试了多次测试

答案1

无论 force_ro 值如何，u-boot 分区环境变量始终可写

这是你未经证实的假设，可能无关紧要。
如果我们简单地假设 U-Boot 环境存储在/dev/mmcblk0boot1，然后“我的测试结果“是完全合理的。

U-Boot 环境实际上存储在哪里
？/etc/fw_env.config文件？
您是否尝试使用斯特拉斯命令检查哪个设备fw_setenv命令测试“实际上被访问了吗？

换句话说，您是否在实际存储环境变量的正确分区上实施保护？
或者环境可能在其他地方，例如文件或原始扇区中？

你没有提供任何证据证明这一点”启动分区“是 U-Boot 环境的存储位置。
您尚未令人信服地证明该force_ro属性无法正常运行。

有人可以根据 force_ro 的值建议一个解决方案来使我的启动分区变为只读吗？

为什么？
系统用这个干什么？”启动分区“ 为了？

你的情况和问题似乎都基于一个（错误的）前提，即/dev/mmcblk0boot1eMMC 的硬件启动分区是 U-Boot 环境的容器。
这两个名称中的“boot”一词是否让你觉得认为那个（不正确的）关联？

答案2

这个问题的原因是libubootenv犯罪：https://github.com/sbabic/libubootenv/commit/92949816720d7af2ac722016e7a5b9a85ff141bc. 绕过 force_ro 保护进行写入。因此，对于我的平台，我将编辑 libubootenv 的源代码

  • 关于该线程的最后一次重播，是的，我确信环境变量存储在/dev/mmcblk0boot1[ dd if=/xx/<uboot>.img of=/dev/mmcblk0boot1 conv=notrunc seek=xx bs=1k]
  • cat /etc/fw_env.config有条目为/dev/mmcblk0boot1 xx xx
  • fw_setenv 的 strac 命令显示为openat(AT_FDCWD, "/dev/mmcblk0boot1",enter code here

无论如何，问题的根本原因已经找到并解决。

相关内容