Carlos Wei (Haochen)

# 16_OPTEE-OS_应用之（一）TA镜像的签名和加载 使用OP-TEE实现特定功能需求则需要开发一个特定的TA，TA调用GP规范定义的接口实现该功能需求。TA镜像文件会被保存在REE侧的文件系统中并以动态TA的方式运行于OP-TEE中，**当用户需要调用该TA的功能时，通过在CA中调用libteec库中的接口，完成创建会话的操作，将REE侧文件系统中的TA镜像文件加载到OP-TEE的用户空间运行**。为防止该TA镜像文件被篡改或被破坏，在加载TA镜像文件的过程中会对该TA镜像文件的合法性进行检查，只有校验通过的TA镜像文件才允许运行于OP-TEE的用户空间。编译TA镜像文件过程中会对TA镜像文件做电子签名操作。本章将详细介绍TA镜像文件的编译、签名，以及加载过程。 # 1. TA文件的编译和签名 TA镜像文件在OP-TEE工程编译过程中生成，也可通过单独调用TA目录下的脚本来进行编译，但前提是OP-TEE工程被完整编译过。编译过程会先生成原始的TA镜像文件，然后使用签名脚本对该文件进行电子签名，并最终生成.ta文件，即最终会被加载到OP-TEE中的TA镜像文件。 ## 1.1 TA镜像文件编译 对某个TA源代码目录中的Makefile文件执行make指令可触发编译生成TA镜像文件的操作，该Makefile文件将会包含optee_os/ta/mk/ta_dev_kit.mk文件，该文件中会定义各种目标依赖关系和Object，编译完目标和object后，编译器将会按照optee_os/ta/arch/arm/link.mk文件中的依赖关系将目标和object链接成xxx.ta文件，其中xxx是该TA UUID的值。link.mk中的链接依赖关系如下： ```makefile link-script$(sm) = $(ta-dev-kit-dir$(sm))/src/ta.ld.S link-script-pp$(sm) = $(link-out-dir$(sm))/ta.lds link-script-dep$(sm) = $(link-out-dir$(sm))/.ta.ld.d SIGN_ENC ?= $(PYTHON3) $(ta-dev-kit-dir$(sm))/scripts/sign_encrypt.py TA_SIGN_KEY ?= $(ta-dev-kit-dir$(sm))/keys/default_ta.pem ifeq...

# 15_OPTEE-OS_内核之（七）系统调用及IPC机制 OP-TEE运行时分为用户空间和内核空间，以此来保证OP-TEE运行时用户空间和内核空间的相互独立。TA程序、OP-TEE提供的一些外部库、各种算法的对外接口都存在于用户空间，而**OP-TEE的线程管理、TA管理、内存管理**等都运行于内核空间。用户空间的程序无法直接访问到内核空间的资源和内存，如果用户空间的程序需要访问内核空间的资源可以通过OP-TEE的系统调用（System Call）的来实现。 OP-TEE按照GP规范定义的大部分接口都是给OP-TEE中的TA使用的。GP统一定义了高级加密标准（Advanced Encryption Standard，ASE）、RSA、安全散列算法（Secure Hash Algorithm，SHA）、哈希消息论证码（Hash-based Message Authentication Code，HMAC）、基于密码的密钥导出算法（Password-Based Key Derivation Function，PBKDF2）等算法的调用接口，该部分在OP-TEE编译时会被编译成libutee.a库文件。TA可通过调用该库中的相关接口来完成对数据的加解密以及签名和验签等操作。如果板级具有硬件密码学引擎实现，调用这些算法接口后最终会使用底层驱动引擎来完成密码学的相关操作。**密码学引擎驱动是处于内核空间的，这也就衍生出了OP-TEE的系统调用的需求**。 进程间通信（Inter-Process Communication，IPC）机制是指系统中进程或线程之间的通信机制，用于实现线程与线程之间进行通信、数据交互等功能。Linux具有多种方式能够实现进程或线程之间的通信和数据共享，例如：消息队列、信号量、共享内存等。而在OP-TEE中**并未**提供如此丰富的IPC方法，本章将介绍OP-TEE中的IPC机制。 # 1. 系统调用 OP-TEE用户空间的接口一般定义成utee_xxx_xxx的形式，而其对应的系统调用则为syscall_xxx_xxx。即在OP-TEE的用户空间调用utee_xxx_xxx函数，OP-TEE最终会调用syscall_xxx_xxx来实现处理，可参考Linux中系统调用的概念。 OP-TEE的系统调用是通过让ARM核进入svc模式来使系统陷入内核态中，然后根据系统调用ID来命中系统调用的内核实现，整个系统调用的过程：  这个过程可以理解为，当用户的调用触发了进入了optee的系统调用，optee需要使用svc产生异常，进入异常之后进行一些上文的备份，调入异常handler，在handler里面找到系统调用的函数，开始执行，执行完成之后返回恢复上文，最后回到用户空间。 OP-TEE系统调用的关键点是通过svc从OP-TEE用户空间切换到OP-TEE的内核空间。使用切换时带入的系统调用ID，在OP-TEE的系统调用数组中找到对应的函数并执行，完成系统调用后切换ARM核的模式返回到用户空间。 一个系统调用的定义是在用户空间通过UTEE_SYSCALL宏来实现的。在OP-TEE中，所有的utee_xxx类的接口都使用该宏定义在utee_syscalls_asm.S文件中，该宏使用汇编实现`optee_os/lib/libutee/arch/arm/utee_syscalls_a32.S`。 OP-TEE的内核空间中定义了一个系统调用的数组表——`tee_svc_syscall_table`，该数组中包含了当前OP-TEE中支持的所有系统调用在内核空间的实现，该数组定义在optee_os/core/arch/arm/tee/arch_svc.c文件中。由于该数组较大，在此就不贴出。在用户空间中触发svc后，会调用tee_svc_handler函数，该函数会使用在用户空间传入的scn值从tee_svc_syscall_table中查找到系统调用的实现，tee_svc_syscall_table[scn]内容所指向的函数即为系统调用在OP-TEE内核空间的具体实现。  tee_svc_handler会调用tee_svc_do_call来执行tee_svc_syscall_table[scn]中定义的函数。在执行tee_svc_syscall_table[scn]之前会保存相关寄存器，以便执行完系统调用后恢复到执行系统调用之前的用户空间的状态，而且还需要将用户空间中带入的数据复制到内核空间供tee_svc_syscall_table[scn]中的函数使用。 系统调用主要是给用户空间的接口提供对内核空间接口的调用，使用户空间可以访问到内核空间的资源。例如在使用安全存储功能时，对object的所有操作最终都是在内核空间完成的，包括安全文件查找、文件树建立、RPC请求发送等。所以理解OP-TEE中系统调用的实现，对理解OP-TEE在用户空间提供的接口的具体实现有很大帮助。...

# 14_OPTEE-OS_内核之（六）线程管理与并发 OP-TEE中使用线程的方式来管理当前系统中需要运行的任务。当TA被调用时，OP-TEE都会使用一个线程空间来运行执行流程，待调用完成后，该线程的状态将会被重置，以备后续被再次调用。本章将详细介绍OP-TEE中线程管理的相关内容。 # 1. OP-TEE中的线程 OP-TEE中的每一个线程作为一个任务的运行载体。OP-TEE中定义了一个线程的数组，线程数组中的每一个元素都表示一个单独的线程空间。该数组定义在optee_os/core/arch/arm/kernel/thread.c文件中，其内容如下： `struct thread_ctx threads[CFG_NUM_THREADS]; ` 该定义并不是动态分配，而是通过静态定义，因此OP-TEE中并没有线程的创建一说，可通过修改CFG_NUM_THREADS来控制OP-TEE中支持的线程的最大个数。当CA端触发了安全监控模式调用（smc）时，OP-TEE会从该数组中找寻到可用的线程元素作为一个任务。如果REE侧触发的安全监控模式调用（smc）是由RPC引起的，OP-TEE会直接使用参数中的线程ID值找到对应的线程上下文，然后执行恢复操作继续执行该线程，该线程ID的值是OP-TEE发起RPC请求时的线程ID。 **多核** 由于OP-TEE支持多核处理安全监控模式调用（smc）（即CPU中的每一个核都可以用来处理安全监控模式调用），故在OP-TEE中还存在另外一个数组变量： `static struct thread_core_local thread_core_local[CFG_TEE_CORE_NB_CORE]` OP-TEE的线程数组是共用，即CPU中的所有核共用线程数组。thread_core_local数组中的每一个元素表示一个核的相关信息，元素中的tmp_stack_va_end用于指定每个ARM核的栈空间，curr_thread用于表示当前核使用的是哪个线程空间。 当CA触发安全监控模式调用（smc）来调用TA中的命令时，OP-TEE会使用一个线程来完成对该安全监控模式调用（smc）的处理。而如果CA调用的是动态的TA，则该线程最终需要切到用户空间去执行，而在进入到用户空间之前会重新设定该线程的栈空间地址。 # 2. 线程状态切换 OP-TEE中的每个线程都具有三种状态，OPTEE通过判定每个线程的状态来决定该线程是否可用。OP-TEE中线程的三种状态及含义如表所示。 | 线程状态 | 表示状态值 | 含义...

# 02_OPTEE-OS_基础之（二）TrustZone和ATF功能综述、简要介绍 TrustZone的原理以及在ARMv7和 ARMv8架构下TrustZone技术实现的差异。TrustZone对系统实现了硬件隔离，将系统资源划分成安全和非安全两种类型，同时在系统总线上增加安全读写信号位，通过读取安全读写信号位电平来确定当前处理器的工作状态，从而判断是否具有该资源的访问权限。因此，TrustZone从硬件级别实现了对系统资源的保护。  ARM可信任固件（ARM Trusted Firmware，ATF）是由ARM官方提供的底层固件，该固件统一 了ARM底层接口标准，如电源状态控制接口（Power Status Control Interface，PSCI）、安全启 动需求（Trusted Board Boot Requirements， TBBR）、安全世界状态（SWS）与正常世界状态 （NWS）切换的安全监控模式调用（secure monitor call，smc）操作等。ATF旨在将ARM底层的操作统一使代码能够重用和便于移植。 # 1. TrustZone 我们来了解一下TrustZone在硬件上提供了哪些支持 ，能够实现物理的隔离。ARM早在ARMv6架构中就引入了TrustZone技术，且在ARMv7和 ARMv8中得到增强，TrustZone技术能提供芯片级别对硬件资源的保护和隔离，当前在手机芯片领域已被广泛应用。 ## 1.2 一个支持TZ的SoC设计 一个完整的片上系统（System...

# 12_OPTEE-OS_内核之（四）对TA请求的处理 当在REE侧执行CA时，OP-TEE中的tee_entry_std函数会根据CA调用libteec库文件中不同的接口而采取不同的处理方式，这些操作包括打开会话、关闭会话、调用TA中的命令、取消对TA中命令的调用。**OP-TEE中存在动态和静态两种TA**，本章将详细介绍OP-TEE对这两种TA操作的具体实现。 # 1. session 会话是CA调用TA中具体命令的基础，如果CA与TA之间没有建立会话，CA就无法调用TA中的任何命令。在CA中通过调用libteec库文件中的**TEEC_OpenSession**函数来建议CA与特定TA之间的会话，该函数执行时会调用OP-TEE驱动中的**optee_open_session**函数发送标准安全监控模式调用（std smc）请求，通知OP-TEE开始执行创建会话的操作。该标准安全监控模式调用会被Monitor模式（ARMv7）或者EL3阶段（ARMv8）处理后转发给OP-TEE，OP-TEE调用**entry_open_session**函数来完成创建会话的操作。在OP-TEE中一次完整的创建会话操作的流程如图所示。 综上所述，**REE(TEEC)-> Driver(open_session) -> OPTEE(entry_open_session) ->ARM(switch to EL3)**  OP-TEE支持**动态TA和静态TA**。 * 静态TA镜像将与OP-TEE镜像编译在同一个镜像文件中，因此静态TA镜像会存放在OP-TEE镜像的特定区段中，静态TA在OP-TEE启动时会被加载到属性为`MEM_AREA_TA_RAM`的安全内存中。 * 动态TA则是将TA镜像文件保存到文件系统中，**在创建会话时OP-TEE通过发送RPC请求将动态TA镜像加载到OP-TEE的安全内存中**。 创建会话在OP-TEE中的操作是根据TA对应的UUID值找到对应的TA镜像，读取TA镜像文件的头部数据，并将相关数据保存到`tee_ta_ctx`结构体变量中，然后将填充好的`tee_ta_ctx`结构体变量保存到`tee_ctxes`链表中，以便后期CA执行调用TA命令操作时可通过查找`tee_ctxes`链表来获取对应的会话。最后根据会话的内容进入到指定的TA，根据需要被调用的命令的ID执行特定的操作。 ## 1.1 静态TA的创建session过程 静态TA是与OP-TEE OS镜像编译在一起的，在OP-TEE的启动阶段，静态TA镜像的内容会被加载到OP-TEE的安全内存中，且在启动过程中会调用verify_pseudo_tas_conformance函数对所有的静态TA镜像的内容进行检查。 调用创建会话操作后，OP-TEE首先会在已经被创建的会话链表中查找是否有匹配的会话存在。如果找到则将该会话的ID直接返回给REE侧，如果没有找到则会根据UUID去静态TA的段中进行查找，然后将找到的静态TA的相关信息填充到tee_ta_ctx结构体变量中，再将该变量添加到全局的tee_ctxes链表中，并调用静态TA的enter_open_session函数执行创建会话操作。静态TA创建会话的操作全过程如图13-2所示。 静态查找TA的优先级： 已创建的TA...

# 11_OPTEE-OS_内核之（三）中断与异常的处理 一个完整的系统都会存在中断，ARMv7架构扩展出了Monitor模式，而ARMv8使用EL的方式对ARM异常运行模式进行了重新定义，分为EL0~EL3。在ARMv8架构系统中，**OP-TEE运行于安全侧的EL1，bl31运行于EL3**。系统运行过程中任何阶段都有可能会产生外部中断。本章将主要介绍FIQ事件和IRQ事件在OP-TEE、ARMv7架构中的Monitor模式、ARMv8架构中的EL3的处理过程。 # 1. 系统的中断处理 ARM核处于安全世界状态（SWS）和正常世界状态（NWS）都具有独立的VBAR寄存器和中断向量表。而当ARM核处于Monitor模式或者EL3时，ARM核将具有独立的中断向量表和MVBAR寄存器。想实现各种中断在三种状态下被处理的统一性和正确性，就需要确保各种状态下中断向量表以及GIC的正确配置。**ARM的指导手册中建议在TEE中使用FIQ，在ROS中使用IRQ，即TEE侧会处理由中断引起的FIQ事件，而Linux内核端将会处理中断引起的IRQ事件**。而由于ATF的使用，Monitor状态或者EL3下中断的处理代码将会在ATF中实现。(ATF来处理更高级及跟敏感的中断) 针对ARMv7核，中断与ARM核每种状态的关系图如图所示：  系统中的中断主要被分为Native Interrupt和Foreign Interrupt事件，FIQ会被TEE侧处理，IRQ会被REE侧处理，如果在Monitor模式或EL3阶段产生了中断，则处于Monitor模式或者EL3的软件会使用MVBAR寄存器中保存的异常向量表中的处理函数对FIQ或者IRQ事件进行处理。 # 2. 中断控制器 中断控制器（General Interruption Controller，GIC）模块是CPU的外设之一，它的作用是接收来自其他外设的中断引脚输入，然后根据中断触发模式、中断类型优先级等设置来控制发送不同的中断信号到CPU。ARM对GIC的架构也在不断改进，已经从GICv1发展到现在的GICv4版本。目前主要使用的是GICv2和GICv3架构。本书将介绍在支持TEE安全扩展的ARM处理器平台上这两个版本的中断控制器是如何工作的。 参考：[12_ARMv8_异常处理（三）- GICv1/v2中断处理](https://github.com/carloscn/blog/issues/51) ## 2.1 GIC寄存器 GIC模块中的寄存器主要分为中断控制分发寄存器（缩写为GICD）以及CPU接口寄存器（缩写为GICC）两部分。GICD接收所有的中断源，然后根据中断的优先级来判定是否响应中断，以及是否将该中断信号转发到对应的CPU。GICC和各个ARM核相连。当收到来自GICD的中断信号时，由GICC来决定是否将中断请求发送给ARM核。 支持安全扩展的GIC模块将中断分为了两组：Group0中断和Group1中断。 * 对于ARMv7架构，Group0为安全中断，Group1为非安全中断。 * 对于ARMv8架构，Group0为安全中断且有最高的优先级，而Group1又分安全中断（Group1 Secure，G1S）和非安全中断（Group1...

## 1. Overview 演示普通的UART demo可以参考： https://youtu.be/_mwpw3nDrL8 使用LPUART_Flexio demo可以参考： https://youtu.be/VgoZpgZNC0A S32K344 LPUART的使用。低功耗通用异步收发器（Low Power Universal Asynchronous Receiver/Transmitter, LPUART）支持带有DMA 接口功能的基本UART，和x4 到x32 的过采样波特率，支持LIN 主从操作。该模块在Stop 和VLPS 模式提供的时钟保持启用时，仍可保持功能。         在S32K344 中有如下15个LPUART 模块： ## 2. 特性 ### 2.1...

# [S32K344] HSE Installation # 1. HSE固件bin文件下载 由于下载HSE是exe打包好的，你也可以从 https://github.com/carloscn/libs/tree/master/nxp/s32k344 下载，这里面包含了解压之后的所有HSE及HSE demo的源代码。也可以从官方渠道获取，如下： > Please downloaded from [S32K3 Standard Software](https://www.nxp.com/webapp/swlicensing/sso/downloadSoftware.sp?catid=SW32K3-STDSW-D&_gl=1*9ipxvx*_ga*MTQ4MzQ3NTIzNS4xNzE3MTIzMTQ5*_ga_WM5LE0KMSH*MTcyMjkwNjQ5Ni42Ni4wLjE3MjI5MDY1MDAuMC4wLjA.) > > Automotive SW - S32K3 - HSE Firmware >  S32K344 HSE...

# [S32K344] PE调试器的使用 普通JLINK没有办法去下载HSE的程序，因此需要用PE调试器去下载HSE启动之后的程序。 # 硬件接口 [https://www.nxp.com/docs/en/supporting-information/USBMLUNIVERSALFX.pdf](https://www.nxp.com/docs/en/supporting-information/USBMLUNIVERSALFX.pdf) 根据文档以下是链接器的针脚：  根据文档A，B，F，G接口都可以给S32使用。我们使用B接口。   # 和板子连接 通过转接板和板子连接，其中IN部分和仿真器相连，OUT和板子相连。  # HOST连接 USB和HOST相连，在Linux上自动就有驱动：  启动S32DS的时候可能会更新固件：  # 使用S32DS调试  分步调试证明仿真器和板子已经建立了连接。 

# High Assurance Boot (HAB) for dummies This post intends to provide all the information you need to understand and use the **HAB** on your Boundary Devices' platform. **For i.MX8...