Bug fix in tspd interrupt handling when TSP_NS_INTR_ASYNC_PREEMPT is enabled
Typically, interrupts for a specific security state get handled in the same security execption level if the execution is in the same security state. For example, if a non-secure interrupt gets fired when CPU is executing in NS-EL2 it gets handled in the non-secure world. However, interrupts belonging to the opposite security state typically demand a world(context) switch. This is inline with the security principle which states a secure interrupt has to be handled in the secure world. Hence, the TSPD in EL3 expects the context(handle) for a secure interrupt to be non-secure and vice versa. The function "tspd_sel1_interrupt_handler" is the handler registered for S-EL1 interrupts by the TSPD. Based on the above assumption, it provides an assertion to validate if the interrupt originated from non-secure world and upon success arranges entry into the TSP at 'tsp_sel1_intr_entry' for handling the interrupt. However, a race condition...
Please register or sign in to comment