👹
Carlos's Tech Blog
  • 🧔ECUs
    • ZYNQ_Documents
      • [ZYNQ] 构建ZYNQ的BSP工程
      • [ZYNQ] 启动流程
      • [ZYNQ] Secure Boot Flow
      • [ZYNQ] Provisioning Guideline
      • [ZYNQ] Decrypting Partition by the Decrypt Agent Using PUF key
      • [ZYNQ] enabling the cryptsetup on ramdisk
      • [ZYNQ] Encrypt external files based on file system using PUF key
      • [ZYNQ] Loading an Encrypted Linux kernel at U-Boot with a KUP Key
      • [ZYNQ] cross-compile the cryptsetup on Xilinx ZYNQ aarch64 platform
      • [ZYNQ] Linux Linaro系统镜像制作SD卡启动
    • S32G_Documents
      • [S32G] Going through the s32g hard/soft platform
      • [S32G] S32g247's Secure Boot using HSE firmware
        • S32g2 HSE key config
        • How S32g verify secure boot image
        • S32g secure boot signature generation
        • How to download and build S32g Secure boot image
        • [S32G] OTA with Secure Boot
    • RT117x_Documents
      • [RT-117x]IMX RT1170 Provisioning Guideline
      • [RT-117x] Going through the MX-RT1170 hard/soft platform
      • [RT-117x] i.MX-RT1170's Secure Boot
        • [RT-117x]Signing image with the HSM (SignServer)
    • LS104x_Documents
      • [LS104x] bsp project
      • [LS104x] boot flow
      • [LS104x] secure boot
      • [LS104x] Application Note, Using the PKCS#11 in TCU platform
      • [LS104x] 使用ostree更新rootfs
      • [LS104x] ostree的移植
      • [LS104x] Starting with Yocto
      • [LS104x] 使用FIT的kernel格式和initramfs
    • IMX6/8_Documents
      • [IMX6] Defining A U-Boot Command
      • NXP IMX6 嵌入式板子一些笔记
      • NXP-imx6 initialization
    • Vehicle_Apps
      • [SecOC] Tree
        • [SecOC] SecOC Freshness and MAC Truncation
  • 😾TECH
    • Rust Arm OS
      • ARMv7m_Using_The_RUST_Cross_Compiler
    • ARM
      • ARM-v7-M
        • 01_ARMv7-M_处理器架构技术综述
        • 02_ARMv7-M_编程模型与模式
        • 03_ARMv7-M_存储系统结构
        • 04_ARMv7-M_异常处理及中断处理
      • ARM-v8-A
        • 02_ARMv8_基本概念
        • 03_ARMv8_指令集介绍_加载指令集和存储指令集
        • 04_ARMv8_指令集_运算指令集
        • 05_ARMv8_指令集_跳转_比较与返回指令
        • 06_ARMv8_指令集_一些重要的指令
        • 0X_ARMv8_指令集_基于汇编的UART驱动
        • 07_ARMv8_汇编器Using as
        • 08_ARMv8_链接器和链接脚本
        • 09_ARMv8_内嵌汇编(内联汇编)Inline assembly
        • 10_ARMv8_异常处理(一) - 入口与返回、栈选择、异常向量表
        • 11_ARMv8_异常处理(二)- Legacy 中断处理
        • 12_ARMv8_异常处理(三)- GICv1/v2中断处理
        • 13_ARMv8_内存管理(一)-内存管理要素
        • 14_ARMv8_内存管理(二)-ARM的MMU设计
        • 15_ARMv8_内存管理(三)-MMU恒等映射及Linux实现
        • 16_ARMv8_高速缓存(一)cache要素
        • 17_ARMv8_高速缓存(二)ARM cache设计
        • 18_ARMv8_高速缓存(三)多核与一致性要素
        • 19_ARMv8_TLB管理(Translation Lookaside buffer)
        • 20_ARMv8_barrier(一)流水线和一致性模型
        • 21_ARMv8_barrier(二)内存屏障案例
      • ARM Boot Flow
        • 01_Embedded_ARMv7/v8 non-secure Boot Flow
        • 02_Embedded_ARMv8 ATF Secure Boot Flow (BL1/BL2/BL31)
        • 03_Embedded_ARMv8 BL33 Uboot Booting Flow
      • ARM Compiler
        • Compiler optimization and the volatile keyword
      • ARM Development
        • 在MACBOOK上搭建ARMv8架构的ARM开发环境
        • Starting with JLink debugger or QEMU
    • Linux
      • Kernel
        • 0x01_LinuxKernel_内核的启动(一)之启动前准备
        • 0x02_LinuxKernel_内核的启动(二)SMP多核处理器启动过程分析
        • 0x21_LinuxKernel_内核活动(一)之系统调用
        • 0x22_LinuxKernel_内核活动(二)中断体系结构(中断上文)
        • 0x23_LinuxKernel_内核活动(三)中断体系结构(中断下文)
        • 0x24_LinuxKernel_进程(一)进程的管理(生命周期、进程表示)
        • 0x25_LinuxKernel_进程(二)进程的调度器的实现
        • 0x26_LinuxKernel_设备驱动(一)综述与文件系统关联
        • 0x27_LinuxKernel_设备驱动(二)字符设备操作
        • 0x28_LinuxKernel_设备驱动(三)块设备操作
        • 0x29_LinuxKernel_设备驱动(四)资源与总线系统
        • 0x30_LinuxKernel_设备驱动(五)模块
        • 0x31_LinuxKernel_内存管理(一)物理页面、伙伴系统和slab分配器
        • 0x32_LinuxKernel_内存管理(二)虚拟内存管理、缺页与调试工具
        • 0x33_LinuxKernel_同步管理_原子操作_内存屏障_锁机制等
        • 01_LinuxDebug_调试理论和基础综述
      • Userspace
        • Linux-用户空间-多线程与同步
        • Linux进程之间的通信-管道(上)
        • Linux进程之间的通信-管道(下)
        • Linux进程之间的通信-信号量(System V)
        • Linux进程之间的通信-内存共享(System V)
        • Linux进程之间的通信-消息队列(System V)
        • Linux应用调试(一)方法、技巧和工具 - 综述
        • Linux应用调试(二)工具之coredump
        • Linux应用调试(三)工具之Valgrind
        • Linux机制之内存池
        • Linux机制之对象管理和引用计数(kobject/ktype/kset)
        • Linux机制copy_{to, from}_user
        • Linux设备树 - DTS语法、节点、设备树解析等
        • Linux System : Managing Linux Services - inittab & init.d
        • Linux System : Managing Linux Services - initramfs
      • Kernel Examples
        • Linux Driver - GPIO键盘驱动开发记录_OMAPL138
        • 基于OMAPL138的Linux字符驱动_GPIO驱动AD9833(一)之miscdevice和ioctl
        • 基于OMAPL138的Linux字符驱动_GPIO驱动AD9833(二)之cdev与read、write
        • 基于OMAPL138的字符驱动_GPIO驱动AD9833(三)之中断申请IRQ
        • Linux内核调用SPI驱动_实现OLED显示功能
        • Linux内核调用I2C驱动_驱动嵌套驱动方法MPU6050
    • OPTEE
      • 01_OPTEE-OS_基础之(一)功能综述、简要介绍
      • 02_OPTEE-OS_基础之(二)TrustZone和ATF功能综述、简要介绍
      • 03_OPTEE-OS_系统集成之(一)编译、实例、在QEMU上执行
      • 05_OPTEE-OS_系统集成之(三)ATF启动过程
      • 06_OPTEE-OS_系统集成之(四)OPTEE镜像启动过程
      • 07_OPTEE-OS_系统集成之(五)REE侧上层软件
      • 08_OPTEE-OS_系统集成之(六)TEE的驱动
      • 09_OPTEE-OS_内核之(一)ARM核安全态和非安全态的切换
      • 10_OPTEE-OS_内核之(二)对安全监控模式的调用的处理
      • 11_OPTEE-OS_内核之(三)中断与异常的处理
      • 12_OPTEE-OS_内核之(四)对TA请求的处理
      • 13_OPTEE-OS_内核之(五)内存和cache管理
      • 14_OPTEE-OS_内核之(六)线程管理与并发
      • 15_OPTEE-OS_内核之(七)系统调用及IPC机制
      • 16_OPTEE-OS_应用之(一)TA镜像的签名和加载
      • 17_OPTEE-OS_应用之(二)密码学算法和安全存储
      • 18_OPTEE-OS_应用之(三)可信应用的开发
      • 19_OPTEE-OS_应用之(四)安全驱动开发
      • 20_OPTEE-OS_应用之(五)终端密钥在线下发系统
    • Binary
      • 01_ELF文件_目标文件格式
      • 02_ELF文件结构_浅析内部文件结构
      • 03_ELF文件_静态链接
      • 04_ELF文件_加载进程虚拟地址空间
      • 05_ELF文件_动态链接
      • 06_Linux的动态共享库
      • 07_ELF文件_堆和栈调用惯例以ARMv8为例
      • 08_ELF文件_运行库(入口、库、多线程)
      • 09_ELF文件_基于ARMv7的Linux系统调用原理
      • 10_ELF文件_ARM的镜像文件(.bin/.hex/.s19)
    • Build
      • 01_Script_makefile_summary
    • Rust
      • 02_SYS_RUST_文件IO
    • Security
      • Crypto
        • 1.0_Security_计算机安全概述及安全需求
        • 2.0_Security_随机数(伪随机数)
        • 3.0_Security_对称密钥算法加解密
        • 3.1_Security_对称密钥算法之AES
        • 3.2_Security_对称密钥算法之MAC(CMAC/HMAC)
        • 3.3_Security_对称密钥算法之AEAD
        • 8.0_Security_pkcs7(CMS)_embedded
        • 9.0_Security_pkcs11(HSM)_embedded
      • Tools
        • Openssl EVP to implement RSA and SM2 en/dec sign/verify
        • 基于Mac Silicon M1 的OpenSSL 编译
        • How to compile mbedtls library on Linux/Mac/Windows
    • Embedded
      • eMMC启动介质
  • 😃Design
    • Secure Boot
      • JY Secure Boot Desgin
    • FOTA
      • [FOTA] Module of ECUs' FOTA unit design
        • [FOTA] Tech key point: OSTree Deployment
        • [FOTA] Tech key point: repositories role for onboard
        • [FOTA] Tech key point: metadata management
        • [FOTA] Tech key point: ECU verifying and Decrpting
        • [FOTA] Tech key point: time server
      • [FOTA] Local-OTA for Embedded Linux System
    • Provisioning
      • [X-Shield] Module of the Embedded Boards initialization
    • Report
由 GitBook 提供支持
在本页
  • 1. ARMv7基础知识(复习)
  • 1.1 ARMv7运行模式扩展
  • 1.2 ARMv7安全状态位扩展
  • 1.3 ARMv7安全相关的重要寄存器
  • 1.4 Monitor指令
  • 1.5 Monitor下处理过程
  • 2. ARMv8基础知识(复习)
  • 2.1 Monitor模式指令
  • 2.2 EL3处理过程
  • 3. 总结
  1. TECH
  2. OPTEE

09_OPTEE-OS_内核之(一)ARM核安全态和非安全态的切换

https://github.com/carloscn/blog/issues/99

上一页08_OPTEE-OS_系统集成之(六)TEE的驱动下一页10_OPTEE-OS_内核之(二)对安全监控模式的调用的处理

最后更新于1年前

我们根据02_ARMv8_基本概念 和 10_ARMv8_异常处理(一) - 入口与返回、栈选择、异常向量表 中了解到ARMv8有EL0 - EL3四个异常等级,有NS和S两种状态。ARMv8对TZ技术有先天性支持的条件。而对于ARMv7架构,要想使用安全feature就需要做一些手脚。

1. ARMv7基础知识(复习)

ARMv7架构的ARM核为支持TrustZone技术,在ARM核原有七种运行模式的基础上扩展除了Monitor模式,正常世界状态(NWS)与安全世界状态(SWS)之间的切换就是由运行于Monitor模式下的程序来完成的,为方便理解在ARMv7架构中正常世界状态与安全世界状态之间的切换,本节将介绍一些基础知识。

1.1 ARMv7运行模式扩展

在未支持TrustZone技术之前,ARM具有七种运行模式,分别为:

  • usr模式(用户模式):正常程序运行时的模式;

  • fiq模式(快速中断模式):当配置有快速中断时,如果产生fiq事件,ARM核将会切换到该模式;

  • irq模式(用户模式):中断模式,一般用于通用中断处理,被ROS使用;

  • svc模式(管理模式):操作系统使用的保护模式;

  • sys模式(系统模式):运行具有特权的操作系统任务;

  • abt模式(数据访问终止模式):当数据或者指令预取值时终止则会进入该模式;

  • und模式(未定义指令模式):当未定义指令执行时则会进入该模式。

这些模式都是一种硬件反应态,AXI总线强烈依赖访问时的模式。

支持TrustZone技术后,ARM增加了Monitor模式,Monitor模式起到进行安全世界状态与正常世界状态之间切换的桥梁作用。所以在ARMv7架构的ARM核中具有八种类型的运行模式和两种状态,每种状态下具有自己独立的七种模式,Monitor模式是共享的。

1.2 ARMv7安全状态位扩展

在支持TrustZone技术时,ARM在AXI系统总线上增加了一个安全状态位(NS bit)(详细情况可查阅ARM给出的TrustZone白皮书),而安全状态位就是用来标识当前的数据、指令是属于安全世界状态还是正常世界状态,安全状态位会被保存到scr寄存器的第0位。当安全状态位等于1时,处理器处于正常世界状态;当安全状态位等于0时,处理器处于安全世界状态。

除了对总线进行扩展之外,ARM对MMU和Cache也同样进行了安全状态位的扩展,用于标记MMU中存放的物理内存映射后的地址是属于安全内存地址还是非安全地址,而对于Cache该位会被用来标记当前的Cache是属于安全态的Cache还是非安全态的Cache。当ARM核访问物理地址时,会对该虚拟地址的安全状态位进行检查,而在访问物理内存时安全扩展组件会对地址进行权限检查,该权限检查操作属于硬件级别的检查,不受软件的控制。关于安全地址的配置则是在IC设计时通过配置安全组件的参数来设定的。

1.3 ARMv7安全相关的重要寄存器

执行两个世界之间的切换操作会使用到各种寄存器的操作,这些寄存器的作用说明如下。

  • 异常向量基地址寄存器(VBAR)

  • Monitor模式的异常向量基地址寄存器 (MVBAR)

  • 安全配置寄存器 (SCR)

  • 栈指针寄存器 (SP)

  • 当前程序状态寄存器 (CPSR)

  • 程序保存状态寄存器 (SPSR)

  • 链接寄存器 (LR)

1.3.1 异常向量基地址寄存器(VBAR)

异常向量基地址寄存器(Vector Base Address Register,VBAR)将保存异常向量表的基地址,在安全世界状态和正常世界状态都具有各自独有的VBAR寄存器用于存放两种状态各自独有的异常向量表的基地址。

异常向量安全世界有一份,正常世界也有一份。

1.3.2 Monitor模式的异常向量基地址寄存器

Monitor模式的异常向量基地址寄存器(Monitor Vector Base Address Register,MVBAR)用于保存在Monitor模式下异常向量表的基地址,该寄存器在安全世界状态和正常世界状态之间进行切换时起到关键作用。

1.3.3 安全配置寄存器

处理器在运行时,安全配置寄存器(Secure Configuration Register,SCR)中会保存相关的标志,其中用于标记处理器处于安全世界状态还是正常世界状态的安全状态位(NS bit)就被保存在该寄存器中。

1.3.4 栈指针寄存器

栈指针寄存器(Stack Pointer,SP)用来存放处理器使用的栈的偏移地址。

1.3.5 当前程序状态寄存器

当前程序状态寄存器(Current Program Status Register,CPSR)将保存处理器运行时的各种标志位信息,包括标志域、状态域、扩展域和控制域。

1.3.6 程序保存状态寄存器

当特定的异常中断发生时,程序保存状态寄存器(Saved Program Status Register,SPSR)将保存当前程序的cpsr寄存器中的内容,待异常中断退出之后,处理器会使用spsr寄存器中的数据来恢复cpsr寄存器中的数据。

1.3.7 链接寄存器

链接寄存器(Link Register,LR)一般用来保存子程序的返回地址。

1.4 Monitor指令

注意进入成功之后,这些寄存器都是自动被load和维护的。通过在程序中执行smc汇编指令可以让处理器进入Monitor模式。如果该汇编指令执行成功,则处理器就切换到了Monitor模式下,并且更新Monitor模式下的重要寄存器,包括CPSR、SPSR、LR、SCR等。该操作与ARM进入到IRQ、ABT等模式的操作一样,采取的是产生异常来进行模式的切换。当处理器进入到Monitor后,处理器就会去查询该模式下的异常处理向量表的位置,而Monitor模式下具有独立的异常向量表的基地址,该地址被保存在MVBAR寄存器中。在ARMv8架构同样也是使用smc指令切换到EL3阶段。

1.5 Monitor下处理过程

在安全世界状态或者正常世界状态中执行smc指令之后,处理器将会触发异常操作进入Monitor模式,并从MVBAR寄存器中获取到Monitor模式的异常中断向量表基地址,进而找到安全监控模式调用操作的异常处理函数。在11_OPTEE-OS_内核之(三)中断与异常的处理中将详细介绍Monitor模式的异常中断向量表基地址是如何保存到MVBAR寄存器中的,此处不赘述。Monitor模式下整个处理逻辑:

在OP-TEE中,Monitor模式的异常中断向量表定义在optee_os/core/arch/arm/sm/sm_a32.S文件中,其内容如下:

当系统调用smc指令后,处理器将切换到Monitor模式,查找到异常中断向量表,并执行b sm_smc_entry指令来对安全监控模式调用进行处理。该函数定义在optee_os/core/arch/arm/sm/sm_a32.S文件中,其完整内容如下:

LOCAL_FUNC sm_smc_entry , :
UNWIND( .fnstart)
UNWIND( .cantunwind)
	//将当前模式的lr和spsr寄存器中的值分别存储在monitor模式的sp中
    srsdb   sp!, #CPSR_MODE_MON    
    push    {r0-r7}         //将r0到r7中的值压入栈(sp)    
    clrex        //独占清除,可以将关系紧密的独占访问监控器返回为开放模式    
    read_scr r1                //获取当前scr寄存器中的值,并将值保存在r1寄存器中    
    //判定scr寄存器中值的NS位是否为1,如果是1,则将会改变CPSR中的条件标志位为0    
    tst r1, #SCR_NS    
    bne .smc_from_nsec  //如果请求来自于Normal World,则跳转到smc_from_nsec进    
    //将当前处于SWS中,Secure World的运行栈存放的运行栈存放在r0中    
    //所以将当前sp的值减去offset就可以得到Secure World的运行栈地址    
    //并将sp的值指向得到的Secure World的运行栈地址    
    sub sp, sp, #(SM_CTX_SEC + SM_SEC_CTX_R0)    //将sp的值加上secure world context的长度保存在r0寄存器中    
    add r0, sp, #SM_CTX_SEC    //保存secure world中八种模式的主要寄存器的值,并将值存放到r0寄存器    
    //而r0寄存器已经指向了CPU栈的位置中以便实现secure context的保存    
    bl  sm_save_modes_regs    //将sp的值加上secure world context中r0存放的位置    
    add r8, sp, #(SM_CTX_SEC + SM_SEC_CTX_R0)    
    ldm r8, {r0-r4}        //将r8寄存器中的值指向地址中的值依次赋给r0到r4    
    //  将FIQ指向完的值保存到r9寄存器中    
    mov_imm r9, TEESMC_OPTEED_RETURN_FIQ_DONE    
    cmp r0, r9                //对比r0寄存器和r9寄存器中的值    
    //如果r0与r9不相等则将sp加上non-secure context中的r0的值保存到r8寄存器中    
    addne   r8, sp, #(SM_CTX_NSEC + SM_NSEC_CTX_R0)    
    //如果r0与r9不相等则将r1到r4寄存器中的值依次加载到r8指定的位置    
    stmne   r8, {r1-r4}    //将sp的值加上non-secure world context的长度保存到r0寄存器中    
    add r0, sp, #SM_CTX_NSEC    
    bl  sm_restore_modes_regs //获取non-secure context的内容//执行返回到Normal World的操作.sm_ret_to_nsec:    
    //将sp的值加上normal world context中从起始位置到r8寄存器的偏移值    
    //然后将结果保存到r0寄存器中    
    add     r0, sp, #(SM_CTX_NSEC + SM_NSEC_CTX_R8)    
    ldm r0, {r8-r12}        //r0寄存器中值指向的地址中的值一次次赋给r8和r12寄存    
    read_scr r0 //获取当前scr寄存器的值,并保存到r0寄存器中    
    orr r0, r0, #(SCR_NS | SCR_FIQ)        //将scr中的NS位和FIQ位置1    
    write_scr r0        //将修改后的r0的值写入scr寄存器    
    //将sp的值加上non-secure world context中从起始位置到r0寄存器的偏移值    
    //然后将结果保存到sp中    
    add sp, sp, #(SM_CTX_NSEC + SM_NSEC_CTX_R0)    
    b   .sm_exit        //跳转到sm_exit函数继续执行//指向切换到Secure World的操作.smc_from_nsec:
    //当前处于Normal world态,栈指针就是
    sp    //所以将当前sp的值减去offset就可以得到Normal World的运行栈地址    
    //并将sp的值指向得到的Normal World的运行栈地址    
    sub sp, sp, #(SM_CTX_NSEC + SM_NSEC_CTX_R0)    
    bic r1, r1, #(SCR_NS | SCR_FIQ)        //清除r1寄存器中的NS位和FIQ位    
    write_scr r1        //将r1寄存器中的值写入scr寄存器    
    //将sp的值加上non-secure world context中r8存放的值    
    //然后将结果保存到r0寄存器中    
    add r0, sp, #(SM_CTX_NSEC + SM_NSEC_CTX_R8)    
    stm r0, {r8-r12}        //将r8到r12寄存器中的值保存到r0指向的地址位置    
    mov r0, sp        //将sp的值赋值给r0寄存器    
    //跳转到secure world中进行处理来自non-secure world的smc请求    
    bl  sm_from_nsec    cmp r0, #0        //对比返回值是否为零,即判断sm_form_nsec函数是否执行成功    
    beq .sm_ret_to_nsec        //如果执行成功,则执行返回到non-secure world的操    
    //如果sm_from_nsec函数并未执行成功,    //则将sp的值加上secure world context中r8存放的位置    
    //然后将结果保存到sp中    
    add sp, sp, #(SM_CTX_SEC + SM_SEC_CTX_R0) 
    //执行退出sm操作.sm_exit:    
    pop {r0-r7}  //将栈中的r0到r7寄存器中的值进行出栈操作    
    rfefd   sp! //使用sp寄存器中的数据执行返回操作
UNWIND( .fnend) 
END_FUNC sm_smc_entry

1.5.1 正常世界触发Monitor处理

根据上图,判断SCR.ns为1则代表这个call是来来自于正常世界。当在正常世界状态(NWS)触发安全监控模式调用时,SCR寄存器中的安全状态位(NS bit)必定为1,处理器进入Monitor模式后,异常向量表中的sm_smc_entry处理函数会执行smc_from_nsec的分支,正式进入对来自正常世界状态的安全监控模式调用进行具体处理。整个执行过程的流程图:

在整个处理过程中,当SCR寄存器中的安全状态位被设定后,即表示处理器的状态已经处于安全世界状态或者是正常世界状态。判定该安全监控模式调用来自于正常世界状态后将会执行到sm_smc_entry函数中的smc_from_nsec代码块。

在该代码段中有重要的两条语句,将从sm_smc_entry开始获取到的scr值保存到r1寄存器中,并清i空r1寄存器中的安全状态位和FIQ位来完成设定处理器状态和使能FIQ,然后再将r1寄存器重新载入到scr寄存器中来完成正常世界状态到安全世界状态的切换。

当正常世界状态中的安全监控模式调用被OPTEE处理完毕后,处理器将调用sm_ret_to_nsec函数重新回到正常世界状态。从安全世界状态切换到正常世界状态是通过读取当前scr寄存器的值到r0寄存器,将r0寄存器中的值的安全状态位和FIQ位设置成1来实现将处理器切换回正常世界状态和屏蔽FIQ的功能。再通过write_scr函数将修改后的r0寄存器的值重新载入到scr寄存器中。

1.5.2 正常世界触发Monitor处理

当安全监控模式调用是在安全世界状态中触发时,SCR寄存器中的安全状态位必定为0,处理器会执行smc_ret_to_nsec分支,正式进入对来自正常世界状态的安全监控模式调用的处理过程。整个执行过程的流程图:

在上述过程中,从安全世界状态切换到正常世界状态的方法也是通过修改SCR寄存器中的安全状态位来实现的。在执行切换之前需要保存安全世界状态的上下文信息,并将当前处理器的上下文信息恢复成正常世界状态的上下文信息。待正常世界状态上下文信息恢复之后,再修改SCR寄存器的安全状态位来实现切换。保存安全世界状态的上下文信息和恢复正常世界状态的上下文信息的操作分别通过执行sm_save_modes_regs和sm_restore_modes_regs函数来实现。

2. ARMv8基础知识(复习)

ARMv7需要自身处理很多程序逻辑。ARMv8使用ATF来完成正常世界状态与安全世界状态之间切换的过程。ARMv8的切换过程与ARMv7大致一样,也是使用smc汇编指令来触发切换动作,关于切换的软件则需要运行在EL3中,且该部分的具体切换过程是在ATF中的bl31中实现的。

我们根据02_ARMv8_基本概念 和 10_ARMv8_异常处理(一) - 入口与返回、栈选择、异常向量表 中了解到ARMv8有EL0 - EL3四个异常等级,有NS和S两种状态。

ARMv8中关于总线、MMU、Cache以及其他安全组件的扩展与ARMv7中的完全一样。相关扩展功能的说明可参见02_OPTEE-OS_基础之(二)TrustZone和ATF功能综述、简要介绍

2.1 Monitor模式指令

ARMv8中smc指令的作用与ARMv7中完全一样,在ARMv8中,smc指令用来产生目标为EL3的异常(异常类型为:Synchronous),只有EL1或更高的特权等级才能调用smc指令。任何需要交给OPTEE OS完成的任务都需要首先发送相应的安全监控模式调用,ATF再根据该调用的来源、ID号等来决定交给OP-TEE OS中相应的处理函数。触发安全监控模式调用的语法为:

smc #imm16 /* imm4 会被处理器忽略,一般设置为#0 */

安全监控模式调用可以分为SMC32调用规范(参数采用32位寄存器)和SMC64调用规范(参数采用64位寄存器)。这种模式独立于AArch32和AArch64模式。在AArch32模式下,ATF规定只能使用SMC32规范;在AArch64模式下,可以同时使用SMC32/64两种调用规范。该规范的说明如表所示。

两种规范中参数的位数不同,但ID号都是使用的32位。为避免不同安全监控模式调用定义的冲突和混乱,ATF通过定义安全监控模式调用格式中不同域的含义来决定安全监控模式调用的类型、服务范围等(参考SMC Calling Convention PDD)

由图可知,在SMC32规范中,针对TEE OS的快速安全监控模式调用(fast smc)的SMC ID范围为0xB2000000~0xBF00FFFF;针对TEE OS的标准安全监控模式调用(std smc)的SMC ID范围为0x02000000~0x1FFFFFFF。

2.2 EL3处理过程

为了简化不同ARMv8平台Trusted OS的移植,ARM提供了在EL3运行的代码示例,称为ARM Trusted Firmware(以下简称为ATF)。采用的BSD许可证,因此目前各个TEE厂商都是在ATF基础上做相应的定制。在ATF里面提供了各种相应的接口标准,包含:

  • Power State Coordination Interface(PSCI):用于CPU电源管理。·

  • Trusted Board Boot Requirement:描述可信任的系统启动/加载镜像的流程。

  • SMC Calling Convention:定义Secure Monitor Call的请求格式。

2.2.1 ATF的EL3异常向量注册

我们在: 02_Embedded_ARMv8 ATF Secure Boot Flow (BL1/BL2/BL31) 的 “4. SoC BL31 Booting”中介绍:在ATF的bl31启动过程中,会调用函数el3_entrypoint_common来初始化异常向量寄存器(VBAR/MVBAR)。以下是el3_entrypoint_common的部分实现,其中设定异常向量的基地址为:

#if !RESET_TO_BL31
	/* ---------------------------------------------------------------------
	 * For !RESET_TO_BL31 systems, only the primary CPU ever reaches
	 * bl31_entrypoint() during the cold boot flow, so the cold/warm boot
	 * and primary/secondary CPU logic should not be executed in this case.
	 *
	 * Also, assume that the previous bootloader has already initialised the
	 * SCTLR_EL3, including the endianness, and has initialised the memory.
	 * ---------------------------------------------------------------------
	 */
	el3_entrypoint_common					\
		_init_sctlr=0					\
		_warm_boot_mailbox=0				\
		_secondary_cold_boot=0				\
		_init_memory=0					\
		_init_c_runtime=1				\
		_exception_vectors=runtime_exceptions		\
		_pie_fixup_size=BL31_LIMIT - BL31_BASE
#else

	/* ---------------------------------------------------------------------
	 * For RESET_TO_BL31 systems which have a programmable reset address,
	 * bl31_entrypoint() is executed only on the cold boot path so we can
	 * skip the warm boot mailbox mechanism.
	 * ---------------------------------------------------------------------
	 */
	el3_entrypoint_common					\
		_init_sctlr=1					\
		_warm_boot_mailbox=!PROGRAMMABLE_RESET_ADDRESS	\
		_secondary_cold_boot=!COLD_BOOT_SINGLE_CPU	\
		_init_memory=1					\
		_init_c_runtime=1				\
		_exception_vectors=runtime_exceptions		\
		_pie_fixup_size=BL31_LIMIT - BL31_BASE

在runtime_exceptions中会设定不同异常向量的入口函数,其中smc指令产生的异常属于Synchronous异常,分别对应AArch64/32模式下的入口为sync_exception_aarch64/32,两者都调用同一个处理函数handle_sync_exception。

2.2.2 EL3处理Monitor调用流程

ARMv8调用smc指令产生安全监控模式调用后,ARM核会切换到EL3中,然后读取MVBAR寄存器中的异常向量表的基地址来获取异常向量表的内容,并命中安全监控模式调用请求处理函数。对于AArch32和AArch64结构,安全监控模式调用的处理函数不同,但最终都会调用handle_sync_exception函数来对安全监控模式调用进行处理。进入handle_sync_exception函数后会对触发安全监控模式调用的世界进行判定,并设定需要切换到的那个世界的状态并恢复对应的CPU上下文,再根据安全监控模式调用ID进入具体的分支,并将ARM核的运行模式切换成EL1或者EL0,待安全监控模式调用处理完毕后会再次触发安全监控模式调用,触发异常重新进入EL3中继续运行余下流程。

2.2.3 opteed_smc_handler

EL3中用于处理OP-TEE的安全监控模式调用是通过调用opteed_smc_handler来实现的,该函数在ATF启动时会被编译到rt_svc_descs段中。该函数的内容如下:

在该函数中上下文会被保存到全局变量opteed_sp_context中,optee初始化完成后返回smc处理的流程如下(services/spd/opteed/opteed_main.c):

uintptr_t opteed_smc_handler(…)
{
optee_context_t *optee_ctx = &opteed_sp_context[linear_id];
    …
	switch (smc_fid) {
	case TEESMC_OPTEED_RETURN_ENTRY_DONE:                             (1)
		assert(optee_vector_table == NULL);
		optee_vector_table = (optee_vectors_t *) x1;
		…
		opteed_synchronous_sp_exit(optee_ctx, x1);                 (2)
		break;
    …
	}
}

opteed_smc_handler函数是ATF用于处理OPTEE产生的安全监控模式调用的处理函数,该函数会对具体的安全监控模式调用类型进行处理。

2.2.4 安全世界状态中触发monitor调用过程

在安全世界状态中触发安全监控模式调用后,ARM核会进入EL3中,从MVBAR中获取异常向量表的基地址,并找到安全监控模式调用的处理函数,然后进入handle_sync_exception函数,再调用opteed_smc_handler函数对该安全监控模式调用进行处理,该函数中将判定该安全监控模式调用时SCR寄存器中的安全状态位是否为安全值,然后再根据SMC ID来决定是否需要恢复正常世界状态的运行上下文,整体过程如图:

当OP-TEE处理完来自正常世界状态的安全监控模式调用后会再次触发安全监控模式调用重新进入EL3,再次调用EL3的安全监控模式调用处理函数,调用opteed_smc_handler函数,根据SMC ID进入不同的分支。一般情况下会进入TEESMC_OPTEED_RETURN_CALL_DONE的分支,在该分支中会保存安全世界状态的运行上下文并恢复正常世界状态的运行上下文,然后调用SMC_RET4返回到正常世界状态中继续运行。

2.2.5 正常世界状态中触发monitor调用过程

在正常世界状态中调用smc指令触发安全监控模式调用后,ARM核会进入EL3,即ATF中的bl31,进入EL3后会从MVBAR寄存器中获取到EL3的异常向量表,然后命中安全监控模式调用的处理函数,最终调用opteed_smc_handler来处理该安全监控模式调用,EL3处理正常世界状态中触发的安全监控模式调用的整体流程如图所示。

在opteed_smc_handler函数中会调用is_caller_non_secure来判定当前安全监控模式调用是来自正常世界状态还是安全世界状态。如果异常来自正常世界状态,则会保存正常世界状态的运行上下文并恢复安全世界状态的运行上下文,然后根据SMC ID将快速安全监控模式调用(fast smc)或标准安全监控模式调用(stf smc)的处理函数注册到运行上下文中,然后通过调用SMC_RET4进入OP-TEE中对该安全监控模式调用做进一步处理。

3. 总结

ARMv7架构中对安全监控模式调用的处理是在Monitor模式下进行的,Monitor模式具有独立的代码。而在ARMv8架构中,对安全监控模式调用的处理则是在ATF的bl31中实现的,在ATF中ARM为兼容不同厂商的TEE方案,提供了集成接口,只要按照一定规范就可以将TEE方案对安全监控模式调用的最终处理逻辑和接口添加到ATF的bl31中。

值得关注的是NS位,用于指示异常是由NS world进来的,还是Secure world进来的。0代表安全,1代表非安全。

😾