指纹是android系统中目前应用比较广发的一种安全验证手段，它使得我们的手机安全得到了极大的提高，同时指纹它也拥有了极高权限，这就意味着，对于指纹这个软件需要一个绝对安全的运行环境，让外界很难突破去破解它。在高通平台中，手机内是分为安全环境和非安全环境的，安全环境是trustzone,简称TZ，这这里面运行的应用程序被称为qsapp，是需要经过签名验证通过才能运行，除TZ意外的地方被称为非安全环境，如下图：

在这里插入图片描述

一、TrustZone

trustzone由两部分软件组成：TZBSP(TrustZone board support package)和QTEE(5.x之前是QSEE,Qualcomm Secure Execution Environment，5.x之后改成QTEE,Qualcomm Trust Execution Environment)

TZBSP:

为芯片安全提供软件支持
公开芯片安全功能的硬件抽象层（HAL）API,如：crypto(加密),fuse lock(熔丝),pseudo-random number generator(RPNG)(伪随机数生成)
为软件和硬件在从断电启动和唤醒期间初始化系统安全环境
在运行时提供内存、子系统保护和服务

QTEE:

向TZ apps提供安全服务，如：镜像加载，签名认证，缓存管理，加密，日志打印和QFPROM (Qualcomm Fuse Programmable Read Only Memory)
提供一套符合全平台的API

TZ 软件镜像是在boot loader中在开机启动时加载，所以，一般分析和查看TZ相关联的一些问题，需要抓取机器中的开机kernel log 和qsee log, tz log 进行分析，指纹的主要处理逻辑的应用程序就运行在QTEE中。

外围设备app的镜像是如何加载的？

HLOS(High-level operating system) 调用QHEE(Qualcomm Hypervisor Execution Environment)进行身份验证并重置外围设备
QHEE申请必要的访问权限并调用QTEE进行身份验证
QTEE第一次调用验证镜像的元数据（metadata），如果加载的镜像有一个更高的版本则QTEE会熔断防回滚保险丝
QTEE解密ELF部分并对其进行散列(hash)以完成身份验证过程
QHEE启动clocks，并重置外围设备

二、TrustZone BSP drivers

1、QFPROM 熔丝可编程只读存储器

QFPROM熔断框架是TZ的一部分
OEM开发上可以在自己的TA(TrustZone application)中使用相关API对QFPROM进行读写，如：qsee_fuse_read()，qsee_fuse_write()

2、Crypto engine 加密引擎

两个通用加密引擎，modem 和 TZ 各一个
支持的加密方式：
- AES 128/192/256 with the following modes: ECB, CBC, CTR, GCM, CCM, CTS, and XTS
- DES 128/192/256
- 3DES (Triple DES)
- SHA1, SHA256/384/512
- HMAC SHA1/SHA2
- ECDH and ECDSA
- RSA 1K/2K/4K

3、Random number generator(RNG) 随机数生成

只能被TZ配置
TZ 和HLOS都能访问生成的随机数
每个函数调用最多生成2048字节的随机数

4、SPI driver

可用于与外部设备接口，比如指纹
由TZ配置，默认启用

5、I2C driver

外部设备使用的安全接口
用于安全触摸功能

三、QTEE

TrustZone从硬件级别开始，创建两个可以在单个核心上同时运行的环境：安全世界和非安全世界。

HLOS非安全世界由以下组成：

用户空间
- 客户端程序
- Listener servie:监听任何来自QSAPP的请求
- QSEEComAPI 库：用于访问QSEECom 内核驱动
内核空间
- QSEECom 驱动
- SCM 驱动：用于访问QTEE的接口

安全世界的组成：

QTEE
QSAPP/TZAPP

四、QSEECom Client

QSEECom Client 是与QTEE 中APP相互通信的客户端，它存在于TZ之外的非安全世界，想要与QTEE数据交换的话必须使用特定的API 接口，它的初始化过程如下：

调用QSEECom_start_app() 来请求加载TA
取回指向QSEECom driver的句柄
当TA被加载之后，用取回的句柄向TZ 发送指令或者请求

指纹的TA也是这么一个过程，首先开机之后，指纹的CA会调用上面start 方式去加载指纹的TA，然后返回相应的句柄，这个句柄是后面给指纹TA发送指令的关键，指纹的CA也就对应于是QSEECom Client

五、QSEECom Lisetener

QSEECom Listener的使用用于接收QSAPP的消息，它的过程如下：

调用QSEECom_register_listener()
注册成功之后，保存listener ID在一个listener service队列中
在QSEECom driver 注册之后，每个listener服务都必须调用QSEECom_receive_req()用来启动监听服务

六、SCM Driver

安全通道管理驱动程序维护HLOS、TZBSP和QTEE之间的通信通道。它使用ARM SMC指令从内核非安全监控模式切换到trustZone 安全监控模式。在kernel中已经被封装好了API，具体代码在kernel/msm-4.9/drivers/soc/qcom/scm.c

关键API：

 int scm_call(u32 svc_id, u32 cmd_id, const void *cmd_buf, size_t cmd_len,void *resp_buf, size_t resp_len)

这个函数在qsee 驱动程序中会被调用用来访问TZ中的应用程序，与之数据交换，TZ里面的代码闭源，再想往下追代码就不行了，还有一个与之相应的关键结构体：

struct scm_command {
    
    
    u32    len;
    u32    buf_offset;
    u32    resp_hdr_offset;
    u32    id;
    u32    buf[0];
};

七、QSEEComAPI Library

QSEECom API库提供了一个用于I/O控制（IOCTL）的抽象API。这是QSEE clinet APP用于间接与TrustZone app进行数据交换的唯一手段，它中间实际上直接访问的是QSEECom driver，然后通过QSEECom driver调用SCM driver的API与TZ发生数据交换，它的实现方法存在于QSEEComAPI.c中，有如下API:

int QSEECom_start_app (struct QSEECom_handle *handle, const char *fname,uint32_t sb_size);                               加载TA
int QSEECom_shutdown_app (struct QSEECom_handle *handle);                                                                                 卸载TA
int QSEECom_send_cmd (struct QSEECom_handle *handle, void *send_buf,uint32_t sbuf_len, void *rcv_buf, uint32_t rbuf_len);               向TA发送指令
int QSEECom_register_listener (struct QSEECom_handle *handle,uint32_t lstnr_id, uint32_t length, uint32_t flags);
int QSEECom_unregister_listener (struct QSEECom_handle *);
int QSEECom_receive_req (struct QSEECom_handle *handle, void * buf, uint32_t  len);
int QSEECom_send_resp (struct QSEECom_handle *handle, void *send_buf,uint32_t len);

八、QSEECom Driver

QTEECom driver是一个内核模块，用于在kernel和QTEE之间进行通信。IOCTL进程是从QSEEComAPI层传入的。代码存在于:/kernel/drivers/misc/qseecom.c。API 如下：

qseecom_open() – 打开驱动
qseecom_release() – 关闭释放驱动
qseecom_ioctl() – 处理与TZ APP、listener、command和request相关的各种IOCTL

到此，对于trustzone大概简单介绍了一下，整个过程中设计的模块都有提及，因为TZ高通对于外界是闭源的，所以想要知道更详细的可能也不会太多，但是对于了解指纹的工作工程和解决指纹过程中的一些问题会有一些帮助，然后接下来就说一下指纹

九、指纹

指纹一般是由第三方厂家支持，提供硬件和软件，硬件就不说了，说软件组成，一般指纹供应商给过来的代码会分为以下几个主要部分;

指纹CA，一般是以库的形式提供，在整个指纹体系中代表着client，可以控制指纹模组及指纹TA加载与卸载、数据交互，及与framework数据交互，与qsee交互的库需要在源码环境下编译，一般存放于vendor下
指纹TA，会伴随着部分代码，以及部分库，在整个指纹体系统是核心地位，负责指纹的核心处理逻辑及算法，最终是运行在QTEE中，以QTEE APP的形式，整个TA代码需要在源码环境下编译，一般存放在trustzone下面
指纹驱动以及设备树文件，供应商提供代码，向指纹CA提供IOCTL 指令API操作指纹模组，一般存放于kernel下面

指纹开机运行过程：

开机 -------》 指纹驱动最先初始化 --------》framework层[email protected]启动，开始启动指纹hal的库，也就是指纹CA库 -----》CA调用相关方法加载指纹TA ----》QTEE开始对指纹进行身份验证，并加载指纹TA，指纹TA加载成功，TA开始运行 -----》 CA调用驱动解析指纹设备树，进行相关指纹模组初始化 ----》指纹正常运行，但是有些厂家会为了方便指纹进行工模测试会单独加个指纹服务，指纹自身编写的指纹服务开始注册，注册成功

注意：在整个指纹开机运行过程中这任何一个阶段出现问题，指纹都没办法正常运行

那么指纹问题无非就分为以下几个种类：

指纹驱动加载异常
CA库启动异常
指纹TA加载异常
指纹软件体系逻辑bug

1、指纹驱动加载异常

首先，指纹驱动代码供应商一般会提供源码，源码在kernel下面，如何去断定是不是驱动加载出问题，主要查看kernel log，对应于驱动代码相关log打印进行查看，a.驱动是否正常加载启动 b.设备树的解析有没有问题 c.CA的指令是否正常到达驱动，主要对这几方面进行排查，自己实在不懂可以让供应商协助分析

2、CA库启动异常

库如果启动异常一般会在main log中报crash之类的报错，是很容易被发现，但是确实不太好解，需要使用addr2line工具对于报错地址进行定位找到crash的函数进行相应的问题解析

3、指纹TA加载异常

TA的加载过程主要会体现在kernel log和tz log中，tz log对于我么来说是加密的，无法查看，只能从kernel log入手，主要查看qseecom.c里面的相关打印，因为这是QSEECom driver的主要代码，可以从log中直观的看到指纹TA是否加载成功，如果加载失败，一般需要提case给高通去分析，因为tz 代码是闭源的，并且tz log加密，自己是没办法定位问题原因的

4、指纹软件体系逻辑bug

像这类问题出现的主要原因是，指纹软件在开发过程中及在平台适配过程中存在问题，比如说：指纹的稳定性不够引发崩溃问题、指纹在测试过程中fail概率比较大、增加删除指纹容易不生效之类的。如果没有出现上面三类情况，那么就可以定位为这类，需要给供应商去排查

从以上几种问题分析发现，其实就算定位出问题所在，我们自己也是没办法修改的，没错因为在指纹整个体系中涉及到的地方代码都是我们无权修改或者没有代码的，作为指纹模块维护者更多的是对问题大致发生位置进行定位，以便在把问题丢出去之后真正的分析者能够更快速的找到问题的根因，作为协助者也可以成为整个模块的holder

高通平台fingerprint指纹框架