- 问题现象:
刷机或恢复出厂设置后指纹无法录入
- 原因分析
最初定位到开机初始化时,指纹通过TEE的接口操作校准文件时失败
[sst_mtk67xx.cc:1213/vfs_create_ta_root_dir]<err>create vfs 7778c03fc30c4dd0a319ea29643d4d4b. directory failed,errno 0x2.
[GF_TA][E][gf_tee_storage][gf_tee_open_object] exit. err=GF_ERROR_OPEN_SECURE_OBJECT_FAILED, errno=1035
[GF_TA][E][gf_tee_storage][gf_tee_open_object] exit. err=GF_ERROR_OPEN_SECURE_OBJECT_FAILED, errno=1035
[GF_TA][E][gf_tee_storage][gf_tee_open_object] exit. err=GF_ERROR_OPEN_SECURE_OBJECT_FAILED, errno=1035
[GF_TA][E][gf_secure_object][gf_so_load_persistent_object] so(cali_data.so) not exist
[GF_TA][E][gf_secure_object][gf_so_load_persistent_object] exit. err=GF_ERROR_OPEN_SECURE_OBJECT_FAILED, errno=1035
[GF_TA][E][gf_persist_object][gf_hw_persist_load_file] load cali data from file fail
[GF_TA][E][gf_persist_object][gf_hw_persist_load_file] exit. err=GF_ERROR_OPEN_SECURE_OBJECT_FAILED, errno=1035
[GF_TA][E][gf_persist_object][gf_hw_persist_load_info] read file error
[GF_TA][E][gf_persist_object][gf_hw_persist_load_info] exit. err=GF_ERROR_OPEN_SECURE_OBJECT_FAILED, errno=1035
[GF_TA][E][gf_persist_object][gf_hw_persist_load_spmt_info] fail to load spmt info from rpmb.
[GF_TA][E][gf_persist_object][gf_hw_persist_load_spmt_info] exit. err=GF_ERROR_OPEN_SECURE_OBJECT_FAILED, errno=1035
但是实际上校准文件时存在,此时现象已经暴露另一个问题,此时没有过多去关注,后面会说到
该问题之前调试没有从来没有遇到过,用当时最新的问题版本测试,复现的概率大概为40%-50%,所以意识到是修改引起的,接下来就进行二分法刷版本排查问题。
最终排查到是2月16日的打开内存融合功能引起的,具体修改内容是默认打开内存融合功能,并且分配6G内存。将这部分分配到8G,问题复现率可达到80%-90%,更加确定是实现内存融合功能引起的。
内存融合开关也是依赖底层功能实现,指纹数据是保存在persist分区的,该笔提交实际上是在data分区开辟了内存,不会影响到persist分区
在rc文件中,内存融合服务在post-fs-data阶段启动的,这个阶段是在准备data,创建下面目录
而刚好指纹操作校准数据是通过/data/vendor/thh/7778c03fc30c4dd0a319ea29643d4d4b的相对路径进行的具体如下:/data/vendor/thh/7778c03fc30c4dd0a319ea29643d4d4b./../../../../mnt/vendor/persist/goodix/cali_data.so
所以这个问题的原因就是当指纹去操作校准文件时,开启内存融合后,data分区并没有完全准备好,操作persist下的校准文件的路径需要通过/data/vendor/thh/7778c03fc30c4dd0a319ea29643d4d4b.的相对路径
参考上面提到过的,内存融合服务是在post-fs-data阶段启动的,指纹服务是开机默认自动动的,大概也是在post-fs-data运行,我们要做的是,指纹服务启动前确保data分区可以完全准备好。
首先将指纹服务默认自启动关掉
service vendor.fps_hal /vendor/bin/hw/android.hardware.biometrics.fingerprint@2.1-service
# "class hal" causes a race condition on some devices due to files created
# in /data. As a workaround, postpone startup until later in boot once
# /data is mounted.
class core
user system
group system input uhid
writepid /dev/cpuset/system-background/tasks
disabled
然后让服务在load_persist_props_action阶段启动,这个阶段是post-fs-data的下一个阶段,加载永久属性,确保data分区已经完全准备好了。
on load_persist_props_action
..........
..........
..........
chmod 0755 /data/vendor/thh/tee_0D
chown system system /data/vendor/thh/tee_0D
chmod 0755 /data/vendor/thh/tee_0E
chown system system /data/vendor/thh/tee_0E
chmod 0755 /data/vendor/thh/tee_0F
chown system system /data/vendor/thh/tee_0F
chmod 0755 /data/vendor/thh/tee_log
chown system system /data/vendor/thh/tee_log
chmod 0755 /data/vendor/thh/ta
chown system system /data/vendor/thh/ta
chmod 0755 /data/vendor/thh/system
chown system system /data/vendor/thh/system
restorecon_recursive /data/vendor/thh
chmod 0771 /data/vendor/key_provisioning
chown system system /data/vendor/key_provisioning
write /proc/bootprof "start teei cfg end (on load_persist_props_action)"
start vendor.fps_hal
- 组合问题
实际上,这个问题还是个组合问题,当时按照这样修改深圳的同事还复现到了问题,差点以为自己走错了方向。
下面这些问题log在处理之前问题就存在,上面的问题已经定位到原因,当看到这部分,只是让人觉得疑惑,时间紧急也没有去细追。这部分log是TEE的打印,很明显这个路径是指纹的校准文件,不过显示成一堆乱码。
[mTEE] : pathname = /data/vendor/thh/7778c03fc30c4dd0a319ea29643d4d4b./../../../../mnt/vendor/persist/goodix/c459ab9637cb5520a3b58a64
[mTEE] : flags = 0 mode = 432 retval = -2
[mTEE] : come into the TZ_VFS_OPEN function
[mTEE] : pathname = /data/vendor/thh/7778c03fc30c4dd0a319ea29643d4d4b.
[mTEE] : flags = 0 mode = 0 retval = 6
[mTEE] : come into the TZ_VFS_CLOSE function
[mTEE] : fd = 6
[mTEE] : retVal = 0
[mTEE] : come into the TZ_VFS_OPEN function
[mTEE] : errno = 2
[mTEE] : pathname = /data/vendor/thh/7778c03fc30c4dd0a319ea29643d4d4b./../../../../mnt/vendor/persist/goodix/c459ab9637cb5520a3b58a64
[mTEE] : flags = 0 mode = 432 retval = -2
[mTEE] : come into the TZ_VFS_OPEN function
[mTEE] : pathname = /data/vendor/thh/7778c03fc30c4dd0a319ea29643d4d4b.
[mTEE] : flags = 0 mode = 0 retval = 6
[mTEE] : come into the TZ_VFS_CLOSE function
[mTEE] : fd = 6
[mTEE] : retVal = 0
[mTEE] : come into the TZ_VFS_OPEN function
[mTEE] : errno = 2
[mTEE] : pathname = /data/vendor/thh/7778c03fc30c4dd0a319ea29643d4d4b./../../../../mnt/vendor/persist/goodix/c459ab9637cb5520a3b58a64
TEE和汇顶都说不是自己的问题,TEE的解释是这些文件都是指纹ta访问的,tee没有主动访问的功能。汇顶解释自己是直接通过file_path操作的。
指纹这边是通过TEE_OPEN调用tee的接口 ut_pf_ts_open/ut_pf_ts_cp_open,所以让汇顶在TEE_OPEN中加了log。经排查,近期对TEE的修改只有实现L1功能,修改前后的log确实不同,修改前都是正常操作明文文件,修改后都是密文文件。
所以,汇顶这边传的是没有问题的,但是TEE打印确实一些加密文件名
[TZ_LOG] fp_ta | [GF_TA][E][gf_hw_dc][gf_hw_create_szdc] flash_id = 0x0000.
[TZ_LOG] fp_ta | [GF_TA][E][gf_tee_storage][gf_tee_open_object]file_path = ../../../../mnt/vendor/persist/goodix/cali_data.so
[TZ_LOG] fp_ta | [GF_TA][E][gf_secure_object][gf_so_load_persistent_object] fail to get object size. size=4294967295
[TZ_LOG] fp_ta | [GF_TA][E][gf_secure_object][gf_so_load_persistent_object] exit. err=GF_ERROR_READ_SECURE_OBJECT_FAILED, errno=
[TZ_LOG] fp_ta | [GF_TA][E][gf_persist_object][gf_hw_persist_load_file] load cali data from file fail
[TZ_LOG] fp_ta | [GF_TA][E][gf_persist_object][gf_hw_persist_load_file] exit. err=GF_ERROR_READ_SECURE_OBJECT_FAILED, errno=1036
接下来,替换了豆荚更新了teei.raw文件,该镜像文件修改是豆荚打开了DEV_FEATURE_SFSV1_SUPPORT,问题得到解决。这些部分都是豆荚和汇顶没有释放的源码,所以只能向他们询问。
① 是什么原因导致校准文件生成为加密文件
文件名加密,这个是版本的关系。以前的版本文件名支持明文的文件名和密文文件名,最新的版本只支持明文文件名
② ut_pf_ts_open 和ut_pf_ts_cp_open的逻辑有什么区别
在以前的版本里,不带cp的函数是直接按明文文件名操作的,带cp的是按密文文件名操作的。最新的版本,这两个接口逻辑相同, 只支持明文文件名
③DEV_FEATURE_SFSV1_SUPPORT具体做什么
OTA升级的时候,这个要保持OTA之前和OTA之后状态一致即可。其他的你们不需要关注。
这个问题可以100%复现的,在实现L1功能前,格式化刷机然后校准指纹,这时候指纹是可以正常使用的,再去普通刷机到实现L1功能后版本,指纹就无法录入了。总之按这个手法,L1实现前后是不能互刷的。