开发过程中多少多少应该见过这个界面,然后在熔丝并lock的机器,
会一起重启最终进入到9008,当然我这个是QCOM平台。
首先我们需要讲下DmVerityMode
dm-verity保护存在于kernel中. 所以如果任何间谍程序在kernel启动之前进入到系统中,例如修改了kernel的代码, 它将对dm-verity免疫.
为了避免这种风险, 一般设备提供商使用烧入到设备中的密钥来验证kernel. 这个密钥在设备离开工厂后就不能被修改(HW OEM Key).
设备提供商将使用这个密钥来验证最顶级的bootloader的签名, 然后booloader将对后面的分区按照级别进行验证, 可能存在的第二级的bootloader, 直到kernel.
一般设备提供商都会利用verified boot功能来验证kernel的正确性. 当kernel被正确验证后, kernel就能够在某个块设备(block device)被挂载时来进行验证了.
一种验证块设备的方式, 是将整个分区的内容进行hash, 然后将其同预先存储的值进行比较. 但是, 这种方式将会增加额外的耗时, 并消耗设备的电量.
而且这种情况下也会对启动增加时间, 并且不能预先提供服务.
在这种情况下, dm-verity在对每个block进行访问时单独验证. 当block内容被读进内存时, 每个block可以并行进行hash操作. 每个block的hash将继续以树的形式进行hash/验证.
由于在以上操作中, 读取block是最耗时的操作, 所以由这种block级别hash/验证所带来的延时就会相对来讲更能容忍.
如果验证失败(block), 设备将产生I/O错误, 来指明某个block不能读取. 这在预期文件系统可能损坏的情况下是会产生的.
如果无法读取的数据对应用主功能影响不大, 应用在这种情况下可以选择继续进行处理. 但是如果数据影响应用. 那么应用可能无法启动.
DmVerityMode
在 Android 操作系统启动期间使用 dm-verity 模式。
枚举
DM_VERITY_MODE_UNSPECIFIED 未知值。
ENFORCING 表示在检测到损坏时设备将重启。
IO_ERROR 表示尝试读取损坏的数据块(也称为 eio 启动状态)时将返回 I/O 错误。
DISABLED 表示 dm-verity 在设备上处于停用状态。
这个问题其实原因还是很简单的,就是链式安全验证机制引起的,
dm-verity 损坏进入eio mode,就不展开这块业务了,
直接说怎么处理的吧,项目进度问题没有细跟只是一个临时处理方案
主要是abl往分区写了一个结构体,
其实DevInfo.verity_mode=Flase,
只要写成True就可以了
DeviceInfoInit 方法中
DevInfo.verity_mode = TRUE
``ReadWriteDeviceInfo (WRITE_CONFIG, (VOID *)&DevInfo, sizeof (DevInfo));``
然后编译,签名,fastboot/qfile都行
另外参考我另一篇文章,https://blog.csdn.net/lll380475066/article/details/140344941
也操作下这个分区,基本两者同时出现概率比较高
VerifiedBoot.c +1456
/* dm-verity warning */
if ( !IsEnforcing () &&
!Info->BootIntoRecovery) {
//在这块代码中加入上面ReadWriteDeviceInfo write config DevInfo.verity_mode=true
//操作前记得ReadWriteDeviceInfo read config,获取当前设备的DevInfo再单独改变verity_mode,以免产生不必要的其他问题
Status = DisplayVerifiedBootMenu (DISPLAY_MENU_EIO);
if (Status == EFI_SUCCESS) {
WaitForExitKeysDetection ();
} else {
DEBUG ((EFI_D_INFO, "The dm-verity is not started in restart mode." \
"\nWait for 30 seconds before proceeding\n"));
}
}
2、adb shell reboot dm-verity enforcing 没有验证,方向是一致的```