1、前言

我们前面知道了整个构建TEE的执行环境的软件有REE侧部分和TEE侧部分，分别包括CA、REE侧接口库（libteec）、常驻进程（tee_supplicant）、OP-TEE驱动、OP-TEE OS、TA等部分。

黄色是我们已经搞过的，红色是等着咱们去解决的。

这一步就是开始我们的安全驱动-REE侧OP-TEE的驱动：

2、REE侧OP-TEE的驱动

（华为就是那个teecd）

OP-TEE驱动是REE侧与TEE侧之间进行交互的重要通道，在REE侧的CA接口以及RPC请求的接收和结果的返回最终都会被发送到驱动中，由驱动对数据做进一步的处理。

OP-TEE驱动通过解析传入的参数，重新组合数据，将需要被传入到TEE侧的数据载入到共享内存中，触发安全监控模式调用（smc）进入到Monitor模式或EL3中将数据发送给TEE。

知道了这个的作用，我们结合代码看看：

1 OP-TEE驱动模块的编译保存

OP-TEE的驱动通过subsys_initcall和module_init宏来告知系统在初始化阶段的什么时候去加载OP-TEE驱动。

subsys_initcall定义在linux/include/init.h文件中，内容如下：

        #define __define_initcall(fn, id) \static initcall_t __initcall_##fn##id __used \__attribute__((__section__(".initcall" #id ".init"))) = fn;#define core_initcall(fn)                __define_initcall(fn, 1)#define core_initcall_sync(fn)          __define_initcall(fn, 1s)#define postcore_initcall(fn)           __define_initcall(fn, 2)#define postcore_initcall_sync(fn)     __define_initcall(fn, 2s)#define arch_initcall(fn)                __define_initcall(fn, 3)#define arch_initcall_sync(fn)          __define_initcall(fn, 3s)#define subsys_initcall(fn)             __define_initcall(fn, 4)#define subsys_initcall_sync(fn)       __define_initcall(fn, 4s)#define fs_initcall(fn)                  __define_initcall(fn, 5)#define fs_initcall_sync(fn)            __define_initcall(fn, 5s)#define rootfs_initcall(fn)             __define_initcall(fn, rootfs)#define device_initcall(fn)             __define_initcall(fn, 6)#define device_initcall_sync(fn)       __define_initcall(fn, 6s)#define late_initcall(fn)                __define_initcall(fn, 7)#define late_initcall_sync(fn)          __define_initcall(fn, 7s)

使用subsys_initcall宏定义的函数最终会被编译到．initcall4.init段中，Linux系统在启动时会执行initcallx.init段中的所有内容，而使用subsys_initcall宏定义段的执行优先级为4。

module_init的定义和相关扩展在linux/include/linux/module.h文件和linux/include/linux/init.h中，内容如下：

                                                  #define device_initcall(fn)          __define_initcall(fn, 6)#define __initcall(fn) device_initcall(fn)#define module_init(x)  __initcall(x);

由此可见，使用module_init宏构造的函数将会在编译时被编译到initcall6.init段中，该段在Linux系统启动过程中的优先等级为6。

结合上述两点来看，在系统加载OP-TEE驱动时，首先会执行OP-TEE驱动中使用subsys_init定义的函数，然后再执行使用module_init定义的函数。

在OP-TEE驱动源代码中，使用subsys_init定义的函数为tee_init，使用module_init定义的函数为optee_driver_init。

2 REE侧OP-TEE驱动的加载

OP-TEE驱动是REE侧与TEE侧之间进行数据交互的桥梁。

tee_supplicant和libteec库中的接口最终都会通过系统调用的方式陷入到Linux内核空间，

然后Linux内核根据传递的参数找到OP-TEE驱动，并命中驱动的operation结构体中的具体处理函数来完成实际的操作。（这里我认为当成一个驱动来看就行，想想linux内核是不是有很多的系统调用都会调用到驱动，比如显卡驱动，就是类似同级别的东西。）

对于OP-TEE驱动，一般会触发安全监控模式调用（smc），并带参数进入到ARM核的Monitor模式或EL3中，在Monitor模式或EL3中执行正常世界状态（NWS）与安全世界状态（SWS）之间的切换，待状态切换完成后，会将驱动端带入的参数传递给OP-TEE中的线程进行进一步的处理。

OP-TEE驱动的源代码存放在linux/drivers/tee目录中。（业界的实现都是相似的，不同的安全系统它的驱动也是在这个位置。）

OP-TEE驱动的加载过程分为两部分，

第一部分是创建class和分配设备号，
第二部分是probe过程。

在正式介绍OP-TEE具体内容之前，首先需要明白两个Linux内核中加载驱动的宏：subsys_initcall和module_init。

OP-TEE驱动的第一部分是调用subsys_initcall宏来实现，而第二部分则是调用module_init宏来实现。（先后顺序）

整个OP-TEE驱动的初始化流程如图9-1所示。

OP-TEE驱动会创建两个设备，分别为/dev/tee0和/dev/teepriv0，这两个设备分别被libteec库和tee_supplicant使用，用于实现各自的功能，而驱动与TEE侧之间的数据传递是通过共享内存的方式来完成的，即在OP-TEE驱动挂载过程中会创建OP-TEE与TEE之间的专用共享内存空间，在Linux的用户空间需要发送到TEE的数据最终都会被保存在该共享内存中，然后再切换ARM核的状态后，OP-TEE从该共享内存中去获取数据。（这个共享内存和TEE侧专门分配的安全内存不一样的，想想这个共享内存的访问权限是都有，而安全内存只有安全侧才有。）

3、OP-TEE driver的实现流程

这个在之前参考前辈的书已经做了一系列笔记这里就不再重复

在本专栏从：

【OP-TEE driver（一）：OP-TEE驱动（OP-TEE driver）的工作流程】

…
【OP-TEE driver（六）：tee_supplicant接口在驱动中的实现】

共六篇，讲述了安全驱动的工作流程与设计实现。

4、小结

介绍了libteec库中的接口和tee_supplicant的调用在驱动中的具体实现，libteec库中的接口主要是发送REE侧的请求到OP-TEE, REE侧与OP-TE之间的数据传递是通过共享内存的方式来实现的，而该共享内存是在挂载驱动时被分配好的。

从tee_supplicant处理来自OP-TEE的请求过程来看主要有三点。

□ 驱动在触发安全监控模式调用后会进入到loop循环中，根据OP-TEE中的返回值来判定该返回是来自OP-TEE的RPC请求还是CA请求的处理结果。如果是RPC请求，也就是需要驱动或者tee_supplicant执行相关操作，驱动将RPC请求保存到OP-TEE驱动的请求消息队列中，然后等待直到收到处理结果；
□ tee_supplicant作为一个常驻进程存在于Linux中，它会不停地尝试从驱动的请求消息队列中获取来自OP-TEE的请求。如果请求消息队列中并没有请求则会一直等待，直到拿到请求才返回，拿到请求之后会对请求进行解析，然后根据请求ID执行具体的操作；
□ tee_supplicant处理完来自OP-TEE的请求后，会调用send操作将处理结果存放到该消息队列的参数区域，并使用complete函数通知OP-TEE驱动该请求已经被处理完毕。OP-TEE驱动block住的地方可以继续往下执行，通过安全监控模式调用将结果返回给OP-TEE（SMC）。

到这里我们就完成了REE侧得学习，下一部分就是搞清楚怎么通过SMC跳转到TEE侧，然后切换到TEEOS去实现一些功能。比如说动态TA加载的时候，会将数据发送给OP-TEE驱动，OP-TEE驱动来完成将数据发送给OP-TEE的操作，OP-TEE会对接收到的TA镜像的合法性进行校验，主要是验证TA镜像文件的电子签名是否合法。那么这些部分在OP-TEE中的校验是怎么实现的。还有很多类似的问题，让我们带着这些问题出发好好来研究一下安全内核吧，毕竟这个玩意开源的可不多哦。

参考资料：
《手机安全和可信应用开发指南》

【CA-TA实战系列九】安全驱动OP-TEE（华为tzdriver）相关推荐

Prometheus监控实战系列九：主机监控
前面我们介绍了Prometheus的基础概念,包括数据格式 .PromQL语法等,本节我们将讲解如何通过Prometheus实现主机的监控 . Prometheus使用各种Exporter来监控资源. ...
xen虚拟化实战系列(六)之xen虚拟机破解密码
xen虚拟化实战系列文章列表 xen虚拟化实战系列(一)之xen虚拟化环境安装 xen虚拟化实战系列(二)之xen虚拟机安装 xen虚拟化实战系列(三)之xen虚拟机复制 xen虚拟化实战系列(四)之 ...
xen虚拟化实战系列(一)之xen虚拟化环境安装
原创作品,允许转载,转载时请务必以超链接形式标明文章原始出处 .作者信息和本声明.否则将追究法律责任.http://koumm.blog.51cto.com/703525/1284516 xen目前 ...
xen虚拟化实战系列(二)之xen虚拟机安装
xen虚拟化实战系列文章列表 xen虚拟化实战系列(一)之xen虚拟化环境安装 xen虚拟化实战系列(二)之xen虚拟机安装 xen虚拟化实战系列(三)之xen虚拟机复制 xen虚拟化实战系列(四)之 ...
ElasticSearch实战系列十一: ElasticSearch错误问题解决方案
前言本文主要介绍ElasticSearch在使用过程中出现的各种问题解决思路和办法. ElasticSearch环境安装问题 1,max virtual memory areas vm.max_ma ...
【CA-TA实战系列六】CA与TA背后的故事一：TEE OS
一.前言 TEE OS就是可信环境的操作系统,这里我们的参考资料是前辈的<手机安全和可信应用开发指南>,因此这里我们的TEE OS就是OP TEE. 那么为什么在搞TA CA的设计实现要关 ...
[.NET领域驱动设计实战系列]专题二：结合领域驱动设计的面向服务架构来搭建网上书店...
原文:[.NET领域驱动设计实战系列]专题二:结合领域驱动设计的面向服务架构来搭建网上书店一.前言在前面专题一中,我已经介绍了我写这系列文章的初衷了.由于dax.net中的DDD框架和Bytear ...
基于 abp vNext 和 .NET Core 开发博客项目 - Blazor 实战系列（九）
基于 abp vNext 和 .NET Core 开发博客项目 - Blazor 实战系列(九) 转载于:https://github.com/Meowv/Blog 终于要接近尾声了,上一篇基本上将文 ...
[.NET领域驱动设计实战系列]专题八：DDD案例：网上书店分布式消息队列和分布式缓存的实现...
原文:[.NET领域驱动设计实战系列]专题八:DDD案例:网上书店分布式消息队列和分布式缓存的实现一.引言在上一专题中,商家发货和用户确认收货功能引入了消息队列来实现的,引入消息队列的好处可以保证 ...

【CA-TA实战系列九】安全驱动OP-TEE（华为tzdriver）