双重触发的嵌入式系统内核安全访问控制

黄姝娟,朱怡安,高武奇,罗钧旻

(1.西安工业大学计算机科学与工程学院，陕西 西安 710021; 2.西北工业大学计算机学院，陕西 西安 710072)

0 引 言

随着分布式应用的不可预知性和任务复杂性的增加，采用单纯基于事件触发机制的系统在很多情况下难以保证系统的安全性与可靠性[1-3]。而时间触发可控的特点从根本上提高了系统的实时性，为此，很多研究者在事件触发机制的系统中融入了时间触发的设计思想[4-8]。

μC/OS-Ⅱ作为一款开源、可移植、可裁剪、事件触发的实时嵌入式操作系统，拥有很好的稳定性与可靠性，广泛应用于航空航天等嵌入式领域[9]。但其内核不具备时间触发特征并且所有应用都运行在同一特权级，应用程序可以无限制地访问整个系统地址空间，这会危害系统的正常运行，严重的甚至会造成系统崩溃[10]。因此需要研究具有应用保护机制的操作系统内核。

OSEK/VDX[11](Open System and the Corresponding Interfaces for Automotive Electronics /Vehicle Distributed Executive)标准是汽车电子控制领域的一种成熟应用和良好典范。它规定了操作系统的系统行为及相关接口功能，具有实时性、可移植性和可扩展性等特点，对基于事件驱动的控制系统有良好的支持[12]。其操作系统规范OSEK OS[13]以及衍生的时间触发操作系统规范OSEKtime OS[14]对操作系统的架构作了较好的设计和定义。本文根据OSEKtime OS规范设计一种基于时间触发的任务调度表，然后将事件触发的任务根据其关键级别安排到时间触发任务空闲间隙去执行；并实现了时间/事件触发任务之间的切换。此外，为了保证外界对系统访问的安全性，结合通用访问控制框架(Generalized Framework for Access Control，GFAC)[15]设计一种安全属性映射表，实现多级安全规则的强制访问控制策略。

1 时间/事件混合触发的内核调度方法设计

1.1 内核设计

首先通过修改μCOS-II内核，实现符合OSEKtime OS标准的时间触发调度模块。OSEK OS标准定义了一个统一的运行环境，旨在提供一套具有标准接口、可扩展、应用程序可移植、具有错误检测的实时操作系统，标准包含的主要模块有任务管理、资源管理、中断处理、事件机制等[16]。

OSEKtime OS是为满足时间触发架构的需求而进行特别裁剪的操作系统标准，它可以和OSEK OS共存[17]，这时OSEK OS只作为整个系统的子系统而存在。OSEKtime OS把它的空闲时间分配给OSEK OS使用，OSEK OS的中断或任务，优先级都比OSEKtime OS中的任务低。两者共存时，OSEK OS的接口和系统服务都不需要改变。OSEKtime OS系统处理层次图如图1所示。

OSEK OS要与OSEKtime OS共存的话，必须满足3个条件：

1)整个OSEKtime OS部分具有比OSEK OS子系统部分更高的优先级，OSEKtime OS的所有任务将会优先得到处理。

2)系统使用的微控制器需要为实现混合系统提供足够数量的中断级别。

3)必须有硬件或者软件上的内存保护机制来确保程序的高可靠性。

图1 OSEKtime OS系统处理层次图

OSEKtime OS中的任务称为时间触发任务(Time-triggered Tasks)。OSEK OS标准中的任务可认为是事件触发任务(Event-triggered Task)。TT任务具有一个特别的属性——最坏执行时间(Worst Case Execution Time，WCET)，表示一个TT任务在某种环境下执行时需要的最长时间。TT任务也具有3个状态：运行态、被抢占态和挂起态。

OSEKtime OS的基本调度策略是基于抢占式调度的。外部调度器根据任务的时间特性(发布时间、最坏执行时间、时限等)生成一张调度表来确定任务的执行顺序。系统内调度器根据调度表，按照时间激活相应任务。

调度表完全执行一次称为一轮调度，两轮调度之间只能执行空闲任务或者事件触发任务。调度表中所有任务的激活都按照预先设计好的调度表进行，系统在每时刻的状态都是可以预测的。调度表循环执行，一轮调度的时间是所有任务周期的最小公倍数。调度器是由中断服务程序调用的，中断源是本地逻辑时钟，即只有在每个系统tick到来的时候才会进行任务调度和任务切换。

TT任务可以相互抢占，OSEK OS中的事件阻塞机制和资源管理对TT任务不可用。根据调度表，调度器激活一个TT任务后，则会抢占另一个处于运行态的任务，被抢占的任务保持被抢占态直到新激活的任务结束。

时间/事件触发系统内核是能够同时支持TT任务和ET任务。因此，根据管理和调度的任务的不同，将系统分为2大部分，时间触发模块和事件触发模块。根据OSEKtime OS和OSEK OS的联系与区别，以及OSEKtime OS系统处理层次图，将系统架构设计为以时间触发部分为上层主要模块、事件触发部分为下层基础模块的层次性架构，如图2所示。

作为系统内核主要部分，时间触发模块和事件触发模块向上都提供系统服务API，向下都能和硬件通信交互。时间触发模块包括TT任务间的同步与通信、中断管理以及任务超时等错误处理。事件触发模块包括ET任务间的同步与通信、中断管理、资源管理、内存管理与警报等。

图2 符合OSEK标准的系统内核架构图

该系统架构图分为3个层次：

1)应用层。

应用层位于整个系统架构的最上层，包括系统服务API和用户应用程序。

利用系统服务API，用户可以对操作系统所支持的任务的最大数量、任务类型、任务同步与通信机制、系统支持的应用模式数等进行静态配置，使得系统能够根据实时系统应用环境和需求的不同，灵活配置系统资源。系统服务接口满足OSEK/VDX标准，能够支持应用程序的移植。用户应用程序包含时间触发任务和事件触发任务，它们合作完成一定的功能。

2)操作系统配置层。

操作系统配置层位于系统架构的中间层，是操作系统的核心。根据管理任务的类型，可分为相对独立的2大部分：事件触发OSEK OS部分与时间触发OSEKtime OS部分。

①事件触发OSEK OS部分。

这部分包含的主要模块有：事件触发任务管理与调度模块、事件管理模块、资源管理模块、内存管理模块、中断管理模块、警报等。OSEK OS部分是基于μC/OS-II操作系统，并按照OSEK OS标准对内核进行部分重新设计和修改实现的。

a 事件触发任务管理与调度模块用于管理事件触发任务，提供事件触发任务的创建、初始化、任务状态查询、删除等服务，并进行事件触发任务调度。

b 事件管理模块支持OSEK标准描述的事件机制，并提供事件的创建、设置、清除等系统服务接口。系统创建时，可以设置任务是否支持事件机制。

c 资源管理模块用于协调多个任务对于共享资源的互斥性访问，且避免产生优先级的反转问题。

d 内存管理模块是可配置的，可以满足事件触发任务对于动态内存的申请。

e 中断管理模块用于管理OSEK OS类型的中断，该模块的中断具有用户定义的静态优先级，且其处理优先级低于OSEKtime OS部分的时间触发任务和中断的执行优先级。

f 警报模块用于满足操作系统处理与时间有关重复事件的需要。

②时间触发OSEKtime OS部分。

这部分包含的主要模块有：时间触发任务管理与调度模块、中断管理模块、错误处理模块和同步与通信模块。OSEKtime OS部分是按照OSEKtime OS标准，基于μC/OS-II操作系统内核，设计添加时间触发任务管理与调度、错误处理、中断管理等模块实现的。

a 时间触发任务管理与调度模块。

该模块用于管理时间触发任务，提供时间触发任务的创建、初始化及任务状态查询等服务，并进行时间触发任务调度。

时间触发任务采用基于静态调度表的调度策略，其优先级高于OSEK OS部分的中断和事件触发任务的优先级。任务创建时，需要有实际的执行时间参数，如最坏执行时间等。时间参数一般需要结合具体的工程应用实践经验并利用专用软件测量；当任务创建完成后，任务被安排在特定的时间点执行，因此任务执行具有良好的确定性和可预测性，能够保证系统对于实时性的要求。

该模块的任务调度需要考虑时间触发任务之间的抢占与恢复，系统同步，以及与事件触发任务之间的相互切换。任务调度需要在不同的调度表之间灵活切换，并且涉及中断嵌套、事件触发任务调度器的加锁/解锁、超时错误检测与处理等，设计实现较为复杂。

该模块包含的主要函数有：任务创建与初始化函数ttTaskCreate()，中断级任务调度主函数ttSchedTick()，任务级任务调度主函数ttTaskEnd()，任务状态查询函数ttGetTaskState()等。

b 中断管理模块。

该模块实现系统的开/关中断功能，管理由系统或外围设备产生的各类中断，并进行中断处理。

时间/事件触发OSEK操作系统支持中断的嵌套，因此需要中断进入/退出函数来记录系统中断的嵌套层数。在时钟中断中系统会进行时间/事件触发任务的调度，并在中断退出时进行任务切换，需要实现相应机制。

该模块包含的主要函数有：中断使能/禁止函数EnableAllInterrupts()/DisableAllInterrupts()，时钟中断服务函数OSTickISR()，时钟中断进入/退出函数TickISREnter()/TickISRExit()等。

c 错误处理模块。

该模块对系统执行过程中产生的各种类型错误进行处理，包括超时错误、操作系统内部错误、参数错误等。错误分为一般性错误与系统严重错误，用户可以自定义错误的处理方式。该模块包含的主要函数有：超时错误检测函数ttTestDeadline()，错误处理钩子函数ttErrorHook()等。

d 同步与通信模块。

该模块用于支持操作系统的分布式应用，包含的主要函数有：获取系统同步状态函数ttGetOSSyncStatus()，同步函数ttSyncTimes()等。

3)硬件相关层。

该层实现与具体的硬件环境相关，主要包括任务堆栈、任务切换、时钟中断、临界区处理以及设备驱动等。硬件相关层包含的主要函数有：任务堆栈初始化函数OSTaskStkInit()，任务级/中断级任务切换函数ttOSCtxSw()/ttIntCtxSw()，时间触发任务切换宏TT_TASK_SW()，事件触发任务切换宏OS_TASK_SW()，时钟中断与中断向量寄存器初始化函数OSInitInterrupts()，进入/退出临界区宏OS_ENTER_CRITICAL()/OS_EXIT_CRITICAL()等。

1.2 调度方法实现

根据静态周期性可抢占式调度策略，时间触发任务在触发时开始执行，任务可以被抢占，被抢占的任务在其他时间触发任务空闲时，采用调度恢复策略。若当前无时间触发任务，且被抢占任务均恢复完成，系统将启动事件触发任务调度。具体流程如图3所示。

图3 双重触发内核周期任务调度流程图

当进行当前周期的任务调度时，首先检测是否有新的时间触发任务需要触发：

1)若有新的时间触发任务，即调度表中任务不为空，且下一个时间触发任务开始时间OSTTNext->OSTT_TCBStartTime等于当前时刻OSTTTick，则需抢占当前正在执行的任务。具体分为3种情形：

①若当前未执行时间触发任务，即OSTTCur为NULL，则锁定事件触发任务调度，直接进行新的时间触发任务的切换；

②若当前正在执行恢复链表中的任务，即OSTTCur等于OSTTResumeFirst->OSTT_PTcb，则抢占恢复链表任务，进行新的时间触发任务切换；

③若上一个时间触发任务未执行完毕，则将任务加入到恢复链表中，抢占当前任务，进行新的时间触发任务切换。

2)若无新的时间触发任务，则需判断是否有时间触发任务正在执行：

①若时间触发任务已执行完毕，则启动事件触发任务调度；

②否则，锁定事件触发任务调度，继续执行当前时间触发任务。

2 安全访问机制的设计与实现

为了保证时间/事件触发的嵌入式内核具有良好的安全性，有必要对内核中μC/OS-II为基础的事件触发模块提供一定的安全访问的保障机制。传统的访问控制技术中，若只采用自主访问控制达不到理想效果，故引入强制访问控制来实现主客体之间严格的访问控制。本文采用GFAC框架，实现了一套多级安全规则的强制访问控制策略。系统内核架构设计如图4所示。

图4 增加访问控制系统内核架构图

GFAC将访问控制的决策和实施分开，形成了访问控制决策模块和访问控制实施模块2个部分。实施模块将拦截到的主体对客体的访问请求发送给决策模块，决策模块查看主客体的访问控制信息并根据访问控制规则来决定是否允许访问，判定结果发回给实施模块，实施模块根据决策结果采取相应措施。决策模块还可以对访问控制规则进行更新或修改。

1)访问控制实施模块的实现。

事件触发模块的运行和μC/OS-Ⅱ一样分为用户态和核心态这2种。系统内核原有的函数定义为核心类型，运行在核心态；应用程序创建的用户任务定义为用户类型，运行在用户态。任务从用户态进入核心态只能调用系统服务，从而访问系统资源，访问控制发生在用户态任务调用安全相关的系统函数的过程中。在事件触发模块中，主体代表一个用户进程，即任务；客体有信号量、互斥型信号量、消息邮箱、消息队列、内存控制块等。访问模式包括创建、只读、只写、读写、删除等。

为了保证系统的可裁剪性，使用宏定义OS_SECURITY_EN来开启或关闭访问控制功能。实施模块以OSACPermission()函数为基础，在所有安全相关的系统调用中添加OSACPermission()，使得用户任务使用系统调用时必须访问拦截。

2)访问控制决策模块的实现。

本文实现自主访问控制(Discretionary Access Control，DAC)和强制访问控制(Mandatory Access Control，MAC)这2种策略，为了增强系统灵活性，可以在编译时选择需要实施的访问控制策略。SECURITY_ACL_EN是自主访问控制的开关，SECURITY_MAC_EN是强制访问控制的开关。

①DAC的实现。

DAC的实现使用了ACL(Access Control List)模式，为了提高效率，使用一个静态的二维数组来存储主体与客体的关系，这样对于权限的管理与查找都更方便。二维数组OS_ACL_TABLE[MAX_SUBJECT _NUM][MAX_OBJECT_NUM]存储访问权限控制列表，MAX_SUBJECT_NUM是可配置的最大主体数量，MAX_OBJECT_NUM为最大客体数量。列表元素OS_ACL_TABLE[s][o]存储主体s对客体o具有的访问权限。权限用OS_RIGHT类型来表示，它是一个INT8U型的变量，每一位分别用来表示创建、读、写、读写、删除、设置权限、删除权限、有效标志。

当任务主体s创建一个信号量客体o时，就会得到对应的主体身份编号subjectId和客体身份编号objectId，该任务对此信号量具有所有模式的访问权限，就将对应的OS_ACL_TABLE[subjectId][objectId]设置为249(11111001)。当OSACPermission()拦截到主体对客体的访问请求后，就根据主体的编号和客体的编号发送给ADF模块，ADF负责查询ACL表的对应权限，返回允许(OS_AC_ALLOWED)或者拒绝(OS_AC_DENIED)。

②MAC的实现。

MAC将BLP模型和Biba模型结合起来，同时保证机密性和完整性的控制。本文将机密性和完整性统称安全属性，为主体和客体设计了一个标示安全属性的结构体：

typedef struct os_security_label

{OS_SECURITY_BIT OSLabelBit;

/*有效性标识位*/

INT8U OSConfidentialityLevel;

/*机密性级别*/

INT8U OSIntegrityLevel;/*完整性级别*/

INT8U OSCategories;

/*类别集合*/

OS_SUBJECT_TYPE OSSubType;

/*主体类型*/

void*data;/*预留空间*/

}OS_SECURITY_LABEL;

分别为主体和客体设计了一个强制访问控制表，这2个表包括系统中所有主客体的安全属性,OS_SUBJECT_SECLABEL_TABLE[MAX_SUBJ ECT_NUM]和OS_OBJECT_SECLABEL_TABLE[MAX_OBJECT_NUM]。同DAC一样，主客体的数量也是通过预先估计来配置的。

主体强制访问控制表结构包含的字段有可信用户类型、机密性级别、完整性级别、主体类型、类别集合、预留字段。客体强制访问控制表与它相似。

在强制访问控制表中，可信用户类型分为超级用户和安全管理员。超级用户负责管理系统资源，在创建、只写、读写、删除等模式下，可以对所有客体进行带写操作的访问。安全管理员负责定义和修改主客体安全属性，在设置权限和删除权限模式下，可以对所有客体进行带写操作的访问。

MAC控制策略的基础是安全属性，由机密性级别、完整性级别和类别集合共同决定，比较主客体之间的安全属性是强制访问控制策略的基础。安全属性的比较需要按规则得出2个安全属性是否相等、是否一个安全属性大于另一个，或者2个安全属性是否不可比较。机密性级别和完整性级别通常不会超过4级，通过一个数组映射为一个INT8U类型的变量再保存到标示安全属性的结构体中。

为了提高扩展性，映射数组设计为8个元素，但目前只需要用到前4个。例如主体的机密性级别是cs，则将OSCLMapTable[cs]数据保存到对应的机密性级别属性OSConfidentialityLevel中，主体完整性级别以及客体的相关属性与此相同。定义一个INT32U类型的临时变量subjectLabel，通过移位和按位或操作，将主体的类别集合、机密性级别、完整性级别全部保存，客体的安全属性采用同样方法保存到objectLabel中。比较安全属性级别时，将subjectLabel和objectLabel进行按位或操作，将结果与主客体安全属性进行比较，即可得出主客体安全属性之间的关系。通过此映射，将多次数字大小的比较转换为集合的关系比较，可迅速得出结果，对系统效率提升明显。

MAC控制模式下，当OSACPermission()拦截到主体对客体的访问请求后，就根据主体的编号和客体的编号发送给ADF模块，ADF模块根据编号查询主客体强制访问控制表，然后根据对应的安全属性信息进行决策，返回允许访问或拒绝访问。

3 实验结果分析

本文的研究和实验都基于Xilinx Virtex-5 FXT FPGA ML507评估平台，设计实现的内核也最终移植到该平台上进行测试。内核在开发板上的移植工作主要通过Xilinx ISE Design Suite 12.3软件完成。首先针对内核调度，设计了多组ET任务和TT任务，经过多次实验求得平均值。实验环境下，系统的时钟节拍为1 ms，TT任务调度周期为50 ms。在完成多次实验后，选取部分任务在第一个周期内的执行结果，如图5所示。

图5 实验结果图

由实验结果可知，tick=0时刻，ET任务etTask1、etTask2、etTask3、etIdle在任务创建后就绪，由于优先级etTask3>etTask2>etTask1>etIdle，所以任务etTask3优先执行，此后etTask2、etTask1和etIdle依次执行。当tick=10时，ttTask1开始执行，直到tick=12时，ttTask1还未执行结束，这时ttTask2触发并抢占ttTask1任务执行。当tick=15时，ttTask2执行结束，ttTask1恢复执行；当tick=22时，ttTask1执行结束。之后，ET任务etIdle、etTask2、etTask3依次就绪并执行。当tick=30时，ttTask3抢占etTask3开始执行；在tick=32时ttTask3执行结束，之后etTask3恢复执行，并在tick=37时执行结束。此后，ET任务etIdle、etTask1、etTask2就绪并执行。

针对访问控制涉及的5种基本访问类型——创建、只读、只写、读写、删除进行实验，验证强制访问控制的实施模块能否正确拦截用户任务的访问请求，决策模块能否做出正确决策并反馈。

表1列出了15种不同的访问情形，通过对信号量、消息邮箱、消息队列、内存控制块等4种客体在上述情形下的访问控制进行测试，实现的访问控制只是在系统函数调用时加入访问拦截和权限判断，主要由OSACPermission()函数实现及其内部调用的决策函数实现，对系统重要功能如任务管理和进程调度及切换等没有影响，带来的额外系统开销集中在函数OSACPermission()中。因此，对时间性能的测试主要就是对访问控制使用前后以及正确与否的判定。

表1 访问控制测试用例表

访问模式安全属性创建只读只写读写删除s>o允许允许不允许不允许允许s=o允许允许允许允许允许s

表2 加入访问控制API前后开销对比 单位：μs

如表2所示，经过对相关API多次测量求平均值，得出未加访问控制时函数调用开销平均值和加了访问控制后平均值。从表2中可以看到对各个API来说，访问控制增加的开销绝对量都是几乎一致的，不受系统运行状态的影响。由表2中可以看出开销增加最大的是信号量的Post函数，增加了6.42%；开销增加最少的是内存的Accept函数，增加了2.21%；平均开销增加了4.53%。结果显示访问实施模块拦下了对相关API的所有调用，并且根据决策模块做出的反馈对调用进行了放行或阻止。实验说明访问控制模块的实现达到了设计要求，决策模块做出了正确的决策。

4 结束语

本文在μC/OS-II内核中设计了一种支持时间和事件双重触发的内核调度机制，将事件触发任务安排到时间触发任务的空闲时刻执行，使系统具有良好的可预测性，并通过在内核中实现访问控制机制来增强系统安全性。实验表明，该嵌入式内核具有良好的安全性与实时交互性能。

参考文献：

[1] Martijn M H P van den Heuvel, Bril R J, Lukkien J J, et al. Towards RTOS support for mixed time-triggered and event-triggered task sets[C]// Proceedings of the 17th IEEE International Conference on Emerging Technologies and Factory Automation. 2012:1-4.

[2] Prashanth K V， Akram P S， Reddy T A. Real-time issues in embedded system design[C]// 2015 International Conference on Signal Processing and Communication Engineering Systems(SPACES). 2015：167-171.

[3] Borgers D P， Heemels W P M H. Event-separation properties of event-triggered control systems[J]. IEEE Transactions on Automatic Control， 2014，59(10)：2644-2656.

[4] 张巍，蒋乐天，罗泽雄. 基于时间触发架构的网络技术研究与设计[J]. 航空电子技术， 2017，48(2)：44-49.

[5] 黄姝娟，刘白林，张雅，等. 时间/事件双重触发的安全关键系统调度机制研究[J]. 电子科技大学学报, 2017,46(3):631-635.

[6] 苏罗辉,郑小宁,张超. 面向安全关键系统的时间触发软件[J]. 计算机应用, 2014,34(S1):277-279.

[7] 焦文喆,翟正军,王国庆. 时间触发AFDX调度设计及实时性分析[J]. 计算机工程， 2016，42(6):42-48.

[8] 朱怡安,魏润之，苏世游，等. 一种基于μC/OS-II符合OSEK标准的实时系统内核设计[J]. 计算机科学， 2016，43(4)：173-201.

[9] 刘淼,王田苗，魏洪兴，等. 基于uCOS-Ⅱ的嵌入式数控系统实时性分析[J]. 计算机工程, 2006,32(22):222-224.

[10] 王丽杰,熊光泽,罗蕾. 嵌入式安全保护机制的研究与实现[J]. 电子科技大学学报, 2006,34(5):650-653.

[11] John D. OSEK/VDX history and structure[C]// Proceedings of IEEE Seminar on OSEK/VDX Open Systems in Automotive Networks. 1998:2/1-214.

[12] Dieu-Huong Vu, Toshiaki Aoki. Faithfully formalizing OSEK/VDX operating system specification[C]// Proceedings of the 3rd Symposium on Information and Communication Technology. 2012:13-20.

[13] OSEK Group. OSEK/VDX Operating System Specification 2.2.22[S].

[14] OSEK Group. OSEK/VDX Time-triggered Operating System Specification, Version 1.0[S].

[15] 欧晓鸥,王志立,魏建香. 基于RBAC与GFAC架构的访问控制模型[J]. 计算机应用, 2008,28(3):612-614.

[16] 毛成勇，高慧敏. 基于OSEK的任务调度算法改进及实现[J]. 计算机工程， 2010，36(4)：233-235.

[17] 谢昊飞,陈家佳,舒强. 基于OSEKTime的共存模型的改进与实现[J]. 重庆邮电大学学报(自然科学版)， 2009，21(5)：6-11.