vendor分区未加入avb校验中：
之前负责AVB的同事离职后，接手这个模块。走读代码时，发现vendor分区没有配置avb校验。
可能是之前整体调整fstab时，把这个配置给漏掉了。
拿手机试了下，确实如此：
# cat /sys/block/dm-*/dm/name
system_a
system_ext_a
product_a
vendor_a
system-verity
system_ext-verity
product-verity
userdata
修改点：
-vendor /vendor ext4 ro,barrier=1,discard wait,slotselect,logical,first_stage_mount +vendor /vendor ext4 ro,barrier=1,discard wait,slotselect,avb,logical,first_stage_mount
修改之后：
# cat /sys/block/dm-*/dm/name
system_a
system_ext_a
product_a
vendor_a
system-verity
system_ext-verity
product-verity
vendor-verity
userdata
CTSKeystoreTestcases测试fail：
从log看：
28104 10-31 09:58:06.506 3406 3423 I TestRunner: started: testEcAttestation_DeviceLocked(android.keystore.cts.KeyAttestationTest) 28604 10-31 09:58:07.482 3406 3423 E TestRunner: failed: testEcAttestation_DeviceLocked(android.keystore.cts.KeyAttestationTest) 28605 10-31 09:58:07.482 3406 3423 E TestRunner: ----- begin exception ----- 28607 10-31 09:58:07.484 3406 3423 E TestRunner: junit.framework.AssertionFailedError: expected:<0> but was:<1> //这里不符合预期 28608 10-31 09:58:07.484 3406 3423 E TestRunner: at junit.framework.Assert.fail(Assert.java:50) 28609 10-31 09:58:07.484 3406 3423 E TestRunner: at junit.framework.Assert.failNotEquals(Assert.java:287) 28610 10-31 09:58:07.484 3406 3423 E TestRunner: at junit.framework.Assert.assertEquals(Assert.java:67) 28611 10-31 09:58:07.484 3406 3423 E TestRunner: at junit.framework.Assert.assertEquals(Assert.java:199) 28612 10-31 09:58:07.484 3406 3423 E TestRunner: at junit.framework.Assert.assertEquals(Assert.java:205) 28613 10-31 09:58:07.484 3406 3423 E TestRunner: at android.keystore.cts.KeyAttestationTest.checkRootOfTrust(KeyAttestationTest.java:1142) 28614 10-31 09:58:07.484 3406 3423 E TestRunner: at android.keystore.cts.KeyAttestationTest.checkDeviceLocked(KeyAttestationTest.java:1121) 28615 10-31 09:58:07.484 3406 3423 E TestRunner: at android.keystore.cts.KeyAttestationTest.testEcAttestation_DeviceLocked(KeyAttestationTest.java:301)
对应CTS测试代码：
private void checkRootOfTrust(Attestation attestation, boolean requireLocked) {
RootOfTrust rootOfTrust = attestation.getTeeEnforced().getRootOfTrust();
assertNotNull(rootOfTrust);
assertNotNull(rootOfTrust.getVerifiedBootKey());
assertTrue("Verified boot key is only " + rootOfTrust.getVerifiedBootKey().length +
" bytes long", rootOfTrust.getVerifiedBootKey().length >= 32);
if (requireLocked) {
assertTrue(rootOfTrust.isDeviceLocked());
checkEntropy(rootOfTrust.getVerifiedBootKey());
assertEquals(KM_VERIFIED_BOOT_VERIFIED, rootOfTrust.getVerifiedBootState());//这里检查失败
}
}
结合log中cmdline的输出：
00037 01-14 01:48:31.489 0 0 I : Kernel command line: security=selinux …… androidboot.verifiedbootstate=yellow ……
初步怀疑是AVB校验这边校验出异常了。
追查下来，发现是前面有笔提交，给IsUserKey赋值为true了。修改后复测pass。
查看系统属性，也对上啦：
$ getprop |grep bootstate [ro.boot.verifiedbootstate]: [green]
GSI版本启动失败：
异常日志：
30275 [ 10.307797] device-mapper: verity-fec: 253:0: FEC 0: failed to correct: -74 30276 [ 10.323250] device-mapper: verity: 253:0: data block 0 is corrupted 30304 [ 10.899018] reboot: Restarting system with command 'dm-verity device corrupted'
查看253:0是哪个分区：
# dmctl list devices Available Device Mapper Devices: system_ext_a : 253:1 userdata : 253:8 system_a : 253:0 vendor-verity : 253:7 vendor_a : 253:3 system_ext-verity : 253:5 product-verity : 253:6 system-verity : 253:4 product_a : 253:2
最终追查下来，是使用的fastboot版本太低导致的问题。工作中真的是什么奇奇怪怪的问题都能碰到啊。