手机版本回刷，导致不能开机一直处在开机动画界面

(不是本人分析，而项目中经常遇到，特意记录)

日志分析如下：

根本原因：因为security_patch level 降低，导致userdata解密失败，系统某些核心服务无法启动。

分析过程：

1. 系统服务无法启动：

12-31 19:03:04.035 0 0 I [01-01 00:03:04.004] (5)[1: init]init 19: [26528][4641]starting service 'tombstoned'...
12-31 19:03:04.095 0 0 I [01-01 00:03:04.064] (7)[1: init]init 29: [26585][50]starting service 'exec 16 (/system/bin/flags_health_check UPDATABLE_CRASHING)'...
12-31 19:03:04.327 0 0 I [01-01 00:03:04.296] (4)[1: init]init 19: [26819][198]starting service 'credstore'...

可以看到，这三行不停的打印，tombstoned和credstore 无法启动。而credstore 看起来是依赖tombstoned的。（这里只是可能，因为tombstoned先出现，不过，我们不用关心，这两个服务，我们都没有更改，不应该是他们引起的错误。）

2. tombstoned 无法启动的原因是啥？

12-31 19:03:24.055 921 921 F tombstoned: failed to open directory: /data/tombstones: No such file or directory

可以看到，它无法打开这个路径。然后就打印如下崩溃信息。

12-31 19:03:24.084 439 439 D AEE_AED : $===AEE===AEE===AEE===$
12-31 19:03:24.084 439 439 D AEE_AED : p 2 poll events 1 revents 1
12-31 19:03:24.085 439 439 D AEE_AED : PPM cpu cores:8, online:8
12-31 19:03:24.085 439 439 D AEE_AED : aed_main_fork_worker: generator 0xb400006ef61c19d0, worker 0x7fdc12adf0, recv_fd 11
12-31 19:03:24.087 923 923 I AEE_AED : handle_request(11)
12-31 19:03:24.088 923 923 I AEE_AED : pid: 921, tid: 921, >>> /system/bin/tombstoned <<<
12-31 19:03:24.088 923 923 I AEE_AED : read_request: receive requirement from aee_core_forwar
12-31 19:03:24.088 923 923 D AEE_AED : u:r:tombstoned:s0
12-31 19:03:24.088 923 923 V AEE_AED : dashboard_record_update() : rec->module = /system/bin/tombstoned
12-31 19:03:24.088 923 923 D AEE_AED : Skip duplicated exception !
12-31 19:03:24.088 923 923 D AEE_AED : Exception Class: 3
12-31 19:03:24.088 923 923 D AEE_AED : Module: /system/bin/tombstoned
12-31 19:03:24.088 923 923 D AEE_AED : Count: 8
12-31 19:03:24.088 923 923 D AEE_AED : Last exception time: 1262304199
12-31 19:03:24.088 923 923 D AEE_AED :
12-31 19:03:24.088 923 923 I AEE_AED : aed_ne_core_session: skip duplicated exception
12-31 19:03:24.088 923 923 E AEE_AED : handle_request: return status is fail
12-31 19:03:24.089 922 922 I aee_core_forwarder: process_coredump: skip process NE
12-31 19:03:24.090 922 922 I aee_core_forwarder: process_coredump: exit
12-31 19:03:24.090 439 439 D AEE_AED : clear ppm settings
12-31 19:03:24.090 439 439 D AEE_AED : $===AEE===AEE===AEE===$

这里，我们看不到tombstones.

那么就无法找到tombstoned  奔溃的原因，我们只有盲猜可能是无法打开/data/tombstones 导致的。（这里打不开这个路径，也就无法记录NE 的相关信息。这是比较麻烦的）

3. 那为什么无法打开/data/tombstones？

（1）按道理，程序在打开这个文件的时候，如果这个路径没有，那么就会创建一个。

（2）查看上面的日志，看看这个文件在哪里创建？

12-31 19:02:42.998 0 0 I [01-01 00:02:42.964] (1)[1: init]init 21: [5490][0]Command 'mkdir /data/tombstones 0771 system system encryption=Require' action=post-fs-data (/system/etc/init/hw/init.rc:663) took 0ms and failed: mkdir() failed on /data/tombstones: Read-only file system

可以看到，在rc文件中，系统是有动作创建这个文件的，但是失败了，原因是data 是只读的。

同时，也可以看到很多的其他类似的操作报错。

data分区怎么可能全部都是只读的呢？那一定data分区是有问题的。

4.为什么data分区是只读的？

我们来查看一下data分区的挂载情况：

12-31 19:02:42.430 0 0 I [01-01 00:02:42.396] (3)[1: init]init 26: [4921][0]starting service 'exec 3 (/system/bin/tune2fs -O has_journal -u 10010 -r 4096 /dev/block/platform/bootdevice/by-name/userdata)'...
12-31 19:02:42.433 0 0 I [01-01 00:02:42.400] (3)[1: init]init 26: [4921][0]SVC_EXEC service 'exec 3 (/system/bin/tune2fs -O has_journal -u 10010 -r 4096 /dev/block/platform/bootdevice/by-name/userdata)' pid 433 (uid 0 gid 0+0 context default) started; waiting...
12-31 19:02:42.456 0 0 I [01-01 00:02:42.424] (3)[1: init]init 26: [4950][23]Service 'exec 3 (/system/bin/tune2fs -O has_journal -u 10010 -r 4096 /dev/block/platform/bootdevice/by-name/userdata)' (pid 433) exited with status 0 waiting took 0.024000 seconds
12-31 19:02:42.457 0 0 I [01-01 00:02:42.424] (3)[1: init]init 21: [4950][23]Sending signal 9 to service 'exec 3 (/system/bin/tune2fs -O has_journal -u 10010 -r 4096 /dev/block/platform/bootdevice/by-name/userdata)' (pid 433) process group...
12-31 19:02:42.737 393 393 I Checkpoint: Validating checkpoint on /dev/block/platform/bootdevice/by-name/userdata
12-31 19:02:42.748 0 0 I [01-01 00:02:42.716] (5)[1: init]init 21: [5239][0]Calling: /system/bin/vdc checkpoint restoreCheckpoint /dev/block/platform/bootdevice/by-name/userdata
12-31 19:02:42.768 0 0 E [01-01 00:02:42.736] (3)[454: vdc]vdc: Command: checkpoint restoreCheckpoint /dev/block/platform/bootdevice/by-name/userdata Failed: Status(-8, EX_SERVICE_SPECIFIC): '22: No magic'
12-31 19:02:42.796 0 0 I [01-01 00:02:42.764] (1)[1: init]init 28: [5239][0][libfs_mgr]superblock s_max_mnt_count:65535,/dev/block/platform/bootdevice/by-name/userdata
12-31 19:02:42.802 0 0 I [01-01 00:02:42.768] (1)[1: init]init 28: [5239][0][libfs_mgr]check_fs(): mount(/dev/block/platform/bootdevice/by-name/userdata,/data,ext4)=0: Success
12-31 19:02:42.845 0 0 I [01-01 00:02:42.812] (5)[1: init]init 26: [5239][0][libfs_mgr]superblock s_max_mnt_count:65535,/dev/block/platform/bootdevice/by-name/userdata
12-31 19:02:42.845 0 0 I [01-01 00:02:42.812] (5)[1: init]init 26: [5239][0][libfs_mgr]Setting reserved block count on /dev/block/platform/bootdevice/by-name/userdata to 32768
12-31 19:02:42.875 0 0 I [01-01 00:02:42.844] (0)[1: init]init 26: [5239][0][libfs_mgr]__mount(source=/dev/block/platform/bootdevice/by-name/userdata,target=/data,type=ext4)=0: Success
12-31 19:02:42.878 0 0 I [01-01 00:02:42.844] (1)[1: init]init 26: [5239][0]Calling: /system/bin/vdc cryptfs encryptFstab /dev/block/platform/bootdevice/by-name/userdata /data
12-31 19:02:42.911 0 0 E [01-01 00:02:42.880] (1)[463: vdc]vdc: Command: cryptfs encryptFstab /dev/block/platform/bootdevice/by-name/userdata /data Failed: Status(-8, EX_SERVICE_SPECIFIC): '0: '

（1）从上面的日志，查看，黑色粗体部分，是userdata挂载的时候，要经过的步骤，没有报错，最后也是挂载成功了的。

（2）查看红色的部分，看起来有问题，第一个红色的部分，和正常日志一样，说明没有问题。第二个红色部分是有问题的，看起来是在加密。

所以，这个问题应该是userdata解密失败导致的。

12-31 19:02:42.876 393 393 I vold : Using Kinibi Keymaster4 from Trustonic for encryption. Security level: TRUSTED_ENVIRONMENT, HAL: android.hardware.keymaster@4.1::IKeymasterDevice/default
12-31 19:02:42.877 441 441 D TlcTeeKeyMaster: TEE_Begin
12-31 19:02:42.877 441 441 D TlcTeeKeyMaster: purpose = 0x00000001
12-31 19:02:42.878 0 0 I [01-01 00:02:42.844] (1)[1: init]init 26: [5239][0]Calling: /system/bin/vdc cryptfs encryptFstab /dev/block/platform/bootdevice/by-name/userdata /data

12-31 19:02:42.878 441 441 E TlcTeeKeyMaster: (keymaster_error_t)tci->response.header.returnCode == -62
12-31 19:02:42.878 441 441 E TlcTeeKeyMaster: transact(session_handle, tci) == -62
12-31 19:02:42.879 441 441 D TlcTeeKeyMaster: TEE_Begin exiting with -62
12-31 19:02:42.879 393 393 E vold : begin failed, code -62
12-31 19:02:42.879 393 393 D vold : Upgrading key: /metadata/vold/metadata_encryption/key
12-31 19:02:42.880 441 441 E TlcTeeKeyMaster: (keymaster_error_t)tci->response.header.returnCode == -38
12-31 19:02:42.880 441 441 E TlcTeeKeyMaster: transact(session_handle, tci) == -38
12-31 19:02:42.881 393 393 E vold : upgrade_key failed, code -38
12-31 19:02:42.895 0 0 I [01-01 00:02:42.864] (0)[463: vdc]vdc: vdc()++ cryptfs encryptFstab
12-31 19:02:42.896 0 0 D [01-01 00:02:42.864] (3)[463: vdc]vdc: Waited 0ms for vold
12-31 19:02:42.907 393 393 I Checkpoint: cp_prepareCheckpoint called
12-31 19:02:42.911 0 0 E [01-01 00:02:42.880] (1)[463: vdc]vdc: Command: cryptfs encryptFstab /dev/block/platform/bootdevice/by-name/userdata /data Failed: Status(-8, EX_SERVICE_SPECIFIC): '0: '

从红色加粗的部分看，确实这里对userdata的加密失败了。

（这里我只是推测，userdata挂载后，是加过密的可能需要先解密，然后再加密）

5. 那么为什么userdata的加密会失败呢？

• userdata 加密，使用的是文件加密的方式，一般是不会出现错误的，出现错误可能是security patch 降低导致。（这里是经验所得）
• 从上面的日志看，我们从HAL层得到的结果就是错误的。即这部分的逻辑是KeyMastrer TA中控制的，我们无从知晓。

12-31 19:02:42.878 441 441 E TlcTeeKeyMaster: (keymaster_error_t)tci->response.header.returnCode == -62

• 结合测试提供的信息：
  • 这是v99->v91 回滚测试。
  • v91 相对于v99 是三个月前的版本。
  • 使用的TSDC，我们的账号没有全擦权限。
  • 通过在recovery中恢复出厂设置后，设备正常启动。
• 从上面这个几个现象来看，可能和security patch 的日期有关。两个版本的security patch level如下：

      V99：[ro.build.version.security_patch]: [2023-04-05]

      V91：[ro.build.version.security_patch]: [2023-01-05]

 

结论：综合上面的分析，我们可以看到，确实是因为security patch level 的降低，导致了userdata 加密失败。

 

建议：

1. 在做回滚版本的时候，可以将security patch level 降低。（可以绕开谷歌的限制）
2. 如果在回滚测试中，无法全擦，可以进入到recovery 模式恢复出厂设置，或者通过fastboot -w 来恢复出厂设置。

     3. userdebug/eng版本使用:adb reboot recovery  .user(userdebug/eng)版本可以强制进入recovery 模式 可以结合项目： 电源键 + 音量上下键组合.

补充：

1. 从日志中，我们也可以看到当前版本的security patch 的版本信息。

12-31 19:02:42.691 441 441 I TrustonicKeymaster4DeviceImpl: Read os_version = 110000, os_patchlevel = 202301, vendor_patchlevel = 20230105, boot_patchlevel = 0

       2. 关于security patch level 的降低，还需要研究，看看，如何从TA 端分析。

       3. 关于文件加密部分的知识，需要加强。