16. OP-TEE中的中断处理（二）------系统FIQ事件的处理

    历经一年多时间的系统整理合补充，《手机安全和可信应用开发指南:TrustZone与OP-TEE技术详解 》一书得以出版，书中详细介绍了TEE以及系统安全中的所有内容，全书按照从硬件到软件，从用户空间到内核空间的顺序对TEE技术详细阐述，读者可从用户空间到TEE内核一步一步了解系统安全的所有内容，同时书中也提供了相关的示例代码，读者可根据自身实际需求开发TA。目前该书已在天猫、京东、当当同步上线，链接如下(麻烦书友购书时能给予评论，多谢多谢)：

京东购买地址

当当购买地址

天猫购买地址

非常感谢在此期间大家的支持以及各位友人的支持和帮助！！！。

为方便和及时的回复读者对书中或者TEE相关的问题的疑惑，也为了大家能有一个统一的交流平台。我搭建了一个简单的论坛，网址如下：

https://www.huangtengxq.com/discuz/forum.php

关于您的疑问可在“相关技术讨论“”中发帖，我会逐一回复。也欢迎大家发帖，一起讨论TEE相关的一些有意思的feature。共同交流。同时该论坛中也会添加关于移动端虚拟化的相关技术的板块，欢迎各位共同交流学习

　　

当系统使用了ATF的时候，monitor态的中断向量表将会在bl31中被设置，本文将介绍不带ATF的情况下系统出现FIQ的时候，整个系统时如何处理的。从《15. OP-TEE中的中断处理（一）------中断配置和向量表的配置》文中的图上可以看出，FIQ只会在当系统处于secure world和monitor态的时候才会生效。下面将分别介绍两种状态下对FIQ的处理流程。在OP-TEE的文档资料中给出了FIQ的整个处理流程如下，包括monitor态和secure world态的处理流程：

1.monitor态下FIQ事件的处理

　　由于不带ATF，所以当CPU处于monitor态时产生FIQ，则必然进入的是monitor的中断向量中去寻找处理函数。而monitor的中断向量是怎么样的呢？在monitor态下FIQ又是被如何才处理的呢？

　　下图为在monitore态下整个FIQ事件的初始化流程图：

1.1 monitor态的中断处理向量表的配置

　　在OP-TEE的启动的过程中，将会调用init_sec_mon函数来完成monitor态的相关初始化，该函数被定义在optee_os/core/arch/arm/kernel/thread.c文件中，从初始化的时候调用的流程如下：

_start--> b reset-->b reset_primary-->bl generic_boot_init_primary-->init_primary_helper-->init_sec_mon

　　init_sec_mon函数的内容如下：

 

static void init_sec_mon(size_t pos __maybe_unused)
{
#if !defined(CFG_WITH_ARM_TRUSTED_FW)
	/* Initialize secure monitor */
/* 调用sm_init函数完成Monitor态的相关初始化 */
	sm_init(GET_STACK(stack_tmp[pos]));
#endif
}

该函数会调用sm_init来进行monitor的相关初始化，sm_init函数定义在optee_os/core/arch/arm/sm/sm_a32.S文件中,内容如下：

 

 

/* void sm_init(vaddr_t stack_pointer); */
FUNC sm_init , :
UNWIND(	.fnstart)
	/* Set monitor stack */
	mrs	r1, cpsr	//设置monitor的栈
	cps	#CPSR_MODE_MON
	/* Point just beyond sm_ctx.sec */
	sub	sp, r0, #(SM_CTX_SIZE - SM_CTX_NSEC)
	msr	cpsr, r1

	/* Set monitor vector (MVBAR) */
	ldr	r0, =sm_vect_table	//获取monitor态的中断向量表变量
	write_mvbar r0		//将中断向量表的地址写入到MVBAR寄存器中

	bx	lr
END_FUNC sm_init

　　该函数将会将monitor态下的中断向量事件的处理地址写入到MVBAR寄存器中，以便在monitor态下产生中断时能够找到中断处理函数。而monitore的中断向量表就是sm_vect_table。该变量内容如下：

 

 

LOCAL_FUNC sm_vect_table , :
UNWIND(	.fnstart)
UNWIND(	.cantunwind)
	b	.		/* Reset			*/
	b	.		/* Undefined instruction	*/
	b	sm_smc_entry	/* Secure monitor call */
	b	.		/* Prefetch abort		*/
	b	.		/* Data abort			*/
	b	.		/* Reserved			*/
	b	.		/* IRQ				*/
	b	sm_fiq_entry	/* FIQ				*/
UNWIND(	.fnend)
END_FUNC sm_vect_table

　　从sm_vect_tabl函数可知，当在monitor态下才产生smc时，将会调用sm_smc_entry函数来进行处理，而当在monitor下出现FIQ时，将会调用sm_fiq_entry函数来进行才处理。

 

1.2 monitor态下FIQ事件的处理过程

　　当在monitor态下产生FIQ时，CPU将会调用存放在MVBAR寄存器中的的sm_smc_entry函数来进行处理。由于是产生了FIQ事件，故最终会调用sm_fiq_entry函数来进行处理。该函数定义在optee_os/core/arch/arm/sm/sm_a32.S文件中，内容如下：

LOCAL_FUNC sm_fiq_entry , :
UNWIND(	.fnstart)
UNWIND(	.cantunwind)
	/* FIQ has a +4 offset for lr compared to preferred return address */
	sub	lr, lr, #4
	/* sp points just past struct sm_sec_ctx */
	srsdb	sp!, #CPSR_MODE_MON
	push	{r0-r7}

	clrex		/* Clear the exclusive monitor */

	/*
	 * As we're coming from non-secure world the stack pointer points
	 * to sm_ctx.nsec.r0 at this stage. After the instruction below the
	 * stack pointer points to sm_ctx.
	 */
	sub	sp, sp, #(SM_CTX_NSEC + SM_NSEC_CTX_R0)

	/* Update SCR */
	read_scr r1
	bic	r1, r1, #(SCR_NS | SCR_FIQ) /* Clear NS and FIQ bit in SCR */
	write_scr r1

	/* Save non-secure context */
	add	r0, sp, #SM_CTX_NSEC
	bl	sm_save_modes_regs
	stm	r0!, {r8-r12}

	/* Set FIQ entry */
	ldr	r0, =(thread_vector_table + THREAD_VECTOR_TABLE_FIQ_ENTRY)
	str	r0, [sp, #(SM_CTX_SEC + SM_SEC_CTX_MON_LR)]

	/* Restore secure context */
	add	r0, sp, #SM_CTX_SEC
	bl	sm_restore_modes_regs

	add	sp, sp, #(SM_CTX_SEC + SM_SEC_CTX_MON_LR)

	rfefd	sp!
UNWIND(	.fnend)
END_FUNC sm_fiq_entry

　　上面的代码中的ldr r0, =(thread_vector_table + THREAD_VECTOR_TABLE_FIQ_ENTRY)就是用来获取在TEE中用来处理FIQ事件的handle地址，而thread_vector_table从上一章节中可以知道，该变量将会与TEE中真正的FIQ函数关联起来。所以最终会调用到main_fiq函数来进行处理该FIQ事件。等处理完之后，CPU将会重新回到处理前的状态。

 

1.3 main_fiq函数

　　main_fiq函数函数是TEE用来处理FIQ事件的最终函数。该函数定义在optee_os/core/arch/rm/tee/entry_fast.c文件中,函数内如如下：

 

static void main_fiq(void)
{
	gic_it_handle(&gic_data);
}

 

　　该函数根据具体的参数和FIQ时间的ID来判定具体需要执行哪些操作，至于具体的操作，以后如果碰到将会具体讲述。

 

2. OP-TEE中对FIQ事件的处理

　　在OP-TEE的初始化的时候会调用thread_init_vbar函数来完成在seure world态的中断向量表的初始化，且在GIC中配置FIQ在secure world态时才有效。所以当在secure world态中产生了FIQ事件的时候，CPU将直接通过VBAR寄存器查找到中断向量表的地址，并命中FIQ的处理函数。整个处理过程如下：

2.1thread_fiq_handler函数

 

　　当在secure world产生了FIQ事件的时候，通过查找中断向量表可以知道，CPU将调用thread_fiq_handler函数，该函数定义在optee_os/core/arch/arm/kernel/thread_a32.S文件中，其内容如下：

LOCAL_FUNC thread_fiq_handler , :
UNWIND(	.fnstart)
UNWIND(	.cantunwind)
#if defined(CFG_ARM_GICV3)
	foreign_intr_handler	fiq
#else
	native_intr_handler	fiq
#endif
UNWIND(	.fnend)
END_FUNC thread_fiq_handler

　　由于没有开启CFG_ARM_GICV3的支持，所以该函数会调用native_intr_handler函数来完成FIQ事件的处理

 

2.2 native_intr_handle宏

　　native_intr_handle宏是用汇编实现的，用来在secure world态中处理FIQ事件。该函数定义在optee_os/core/arch/arm/kernel/thread_a32.S文件中，内容如下：

 

.macro	native_intr_handler mode:req
	/*
	 * FIQ and IRQ have a +4 offset for lr compared to preferred return
	 * address
	 */
	sub     lr, lr, #4

	/*
	 * We're saving {r0-r3}. The banked fiq registers {r8-r12} need to be
	 * saved if the native interrupt is sent as FIQ because the secure
	 * monitor doesn't save those. The treatment of the banked fiq
	 * registers is somewhat analogous to the lazy save of VFP registers.
	 */
	.ifc	\mode\(),fiq
	push	{r0-r3, r8-r12, lr}
	.else
	push	{r0-r3, lr}
	.endif
	bl	thread_check_canaries	//检查栈空间没被破坏
	ldr	lr, =thread_nintr_handler_ptr	//加载FIQ处理函数的地址到lr寄存器中
	ldr	lr, [lr]
	blx	lr	//跳转到thread_nintr_handler_ptr函数执行
	.ifc	\mode\(),fiq
	pop	{r0-r3, r8-r12, lr}
	.else
	pop	{r0-r3, lr}
	.endif
	movs	pc, lr
.endm

 

2.3 main_fiq函数

 

　　在初始化的时候会调用init_handlers函数将thread_nintr_handler_ptr指向handlers->nintr变量，而handlers->nintr的值为main_fiq函数。所以最终会调用到main_fiq来对FIQ事件进行处理。

　　main_fiq函数需要根据不同的板级的需要和板级需要处理的FIQ事件类型进行实际的编写和处理，在此就不做详细介绍。