2019, Vol. 45
b. 西北工业大学 软件与微电子学院, 西安 710072
b. School of Software and Microelectronics, Northwestern Polytechnical University, Xi'an 710072, China
在工业控制、汽车、航天、航空等应用领域, 一旦操作系统发生故障或不能及时响应任务, 可能造成生命和财产的重大损失。由于开发团队沟通不畅、编程失误等各种人为错误, 因此软件错误不可避免。据统计[1], 旅行者号18 000行代码与伽利略号22 000行代码中, 分别发现87处与122处可能导致灾难性后果的软件错误。因此, 如何设计一种能为安全关键系统提供稳定运行平台的高可靠性、可容错的实时操作系统内核极具现实意义和研究价值。
目前, 国外已有成熟可靠的安全关键嵌入式实时操作系统, 如VxWorks 653与INTEGRITY-178B。VxWorks是美国Wind River公司设计开发的高性能、可扩展、易裁剪的实时操作系统, 其内核衍生出多种面向不同应用领域的版本, 如虚拟化OS VxWorks MILS OS。其中面向航空领域的VxWorks-653平台是为复杂、高安全性要求的航电系统开发的符合ARINC-653标准的实时操作系统, 取得了美国国家安全局(National Security Agency, NSA)的EAL 6级认证, 目前已被200多家客户, 在超过75架飞机的350多个项目中使用。INTEGRITY 178B由美国Green Hills Software公司开发, 是符合ARINC-653[2]标准的高可靠性实时操作系统, 目前已通过RTCA Do-178B认证, 获得NSA的EAL 6+认证, 被用于B-2、F-16、F-22、F-35和空客A380等飞机的航电系统。
然而, 国内现有的嵌入式实时操作系统产品在安全可靠性方面还有所不足。随着近年来计算机硬件、集成开发环境、虚拟机与软件验证等技术的迅速发展, 代码开源计划与开源社区的成熟, 亟需实现高效、可靠的自主研发安全关键嵌入式实时操作系统。
本文基于ARINC-653标准实现了一种面向安全关键应用领域的嵌入式实时操作系统AgOS, 根据ARINC-653标准规定的分时分区实时操作系统, 提出软硬件分区混合的分区保护技术、基于Manifest描述的任务与分区方式、基于CACHE锁的CACHE策略、基于任务好感度的分区分配策略。在PowerPC平台上实现该嵌入式实时操作系统内核原型, 并给出操作系统内核原型的功能与性能测试结果。
1 相关工作国内外对于操作系统的安全性及可靠性有大量研究[3-4], 综合来看, 目前操作系统领域主要依靠以下机制保证操作系统的安全可靠:
1) 安全编程语言[5], Java、C#等安全编程语言可在编程语言层面保证操作系统不会出现类型安全问题与缓冲区溢出问题, 但安全编程语言本身依赖的虚拟机或者运行时框架由C语言实现, 仍然存在缓冲区溢出的安全隐患。
2) 微内核设计[4-6], 微内核设计的操作系统内核一般只提供必要的任务调度、任务通信与内存管理等服务, 而外设驱动等服务在用户模式下运行。外设驱动的失效不会干扰到内核的运行。
3) 故障隔离与恢复机制[3-4], 操作系统提供一套安全有效的内存隔离与保护机制来限制故障的蔓延。现有的内存隔离与保护机制使用硬件MMU或者MPU进行内存保护, 或者SFI软件隔离任务, 当程序发生故障时, 故障不会蔓延影响到其他程序的运行。该机制的缺点是启用硬件MMU或使用软件隔离会增加访存延时。此外, 还需要专门的监测程序负责监测程序运行状态, 当程序发生故障时, 故障处理程序接管故障程序运行, 恢复故障的程序或设备。该机制增加了运行开销, 影响操作系统性能。
4) 软件静态验证[5-7], 包括操作系统源代码层面的形式化设计与验证技术、源代码与编译器层面的软件静态分析验证技术、编译器层面的验证等, 从不同层面保证操作系统的安全可靠。
本文操作系统借鉴了相关研究的成果, 在ARINC-653规定的分区隔离、安全检测的基础上, 融入微内核、用户态驱动设计, 采用软件静态分析验证技术实现内核编程的类型安全。
2 安全关键嵌入式实时操作系统设计与传统嵌入式实时操作系统相比, 安全关键领域的软件开发有许多规范与标准约束, 如汽车领域的OSEK/VDX标准, 航空航天领域的DO-178B/C机载软件适航标准、ARINC-653安全关键实时操作系统设计标准等。这些标准界定了安全关键嵌入式实时操作系统开发过程中的规范以及必须实现的功能集合。
2.1 ARINC-653标准ARINC-653标准最初于1996年10月发布。1997年1月发布标准的补充ARINC-653-1, 引入APEX接口与时间、空间分区的概念。
ARINC-653标准的核心思想是时空隔离, 即一个分区内软件的性能与行为不会受到另一个分区内软件的影响。在该思想的指导下, ARINC-653-1标准要求操作系统必须实现时间分区与空间分区。时间分区必须确保某分区中的软件从共享资源中获得的服务不会被其他分区的软件所干扰, 这包括资源性能、速率、延迟、抖动与访问共享资源的时长。空间分区必须确保某分区中的软件既不能改变其他分区软件或私有数据(无论是在内存中还是在数据转移中), 也不能控制其他分区的私有设备[4]。
2.2 操作系统内核总体架构本文设计并实现的嵌入式实时操作系统AgOS架构如图 1所示, AgOS是基于ARINC-653标准的分区操作系统, 采用微内核架构。操作系统内核只提供最基本的系统服务, 如时钟管理、中断管理、分区管理、任务管理等。其他如通信机制、健康监测、虚拟化设备与中断作为可裁剪的模块, 此外, 串口驱动、网络支持等作为可裁剪的系统服务, 需按照需求加载到操作系统中。
|
Download:
|
| 图 1 安全关键嵌入式实时操作系统架构 | |
操作系统共分成3层, 应用层、内核层以及硬件层。应用层是安全关键应用, 通过调用APEX接口获得系统服务。内核层是操作系统核心部分, 采用微内核、模块化、层次化设计, 向下通过硬件抽象层(Hardware Abstraction Layer, HAL)管理处理器与其他硬件, 向上通过系统调用的方式向应用程序提供APEX接口。硬件层包括体系结构支持、板级支持包等与平台相关的代码。
AgOS操作系统大部分功能采用C语言实现, 但是C语言并非一种安全的编程语言, 例如C语言在编写过程中可能会将一种类型错误地当成另一种类型(如将字符指针作为字符数组使用), 然而依然可以通过编译。C字符串处理strcpy()等函数以及基于字符串处理的sprintf()等函数在实现上并未对字符数组边界执行检查, 有缓冲区溢出的风险。这些C程序编写过程中常出现的类型安全与缓冲区溢出问题, 在操作系统编写过程中同样会出现。为避免这些安全问题, AgOS在实现过程中不使用动态内存分配, 全部采用静态空间配置, 不使用有可能导致缓冲区溢出的C库函数, 如strcpy等相关函数, 通过软件静态分析验证工具Frama-C阻止类型不安全的使用。
2.3 软硬件混合的空间分区空间分区有硬件分区和软件分区2种实现方式[3]。硬件隔离分区是指通过硬件MMU机制确保分区内的软件不会访问到其他分区。一旦分区尝试访问MMU指定可访问以外的内存, 非法访问行为会被MMU所阻止, 且CPU会产生相应的中断以便进行错误处理与恢复。
硬件隔离是最常用的空间隔离方式, 具有高安全性的优势, 但开启MMU会产生访存延迟, 同时分区切换也会产生额外开销, 对操作系统性能与实时性会有一定影响。
与硬件隔离对应的软件隔离概念早在1994年就已提出。文献[8]通过修改编译器对访存指令及跳转指令进行封装, 实现了基本的软件隔离。文献[9]将修改编译器的软件隔离方法应用于现有的ARM与X86 CPU体系结构。
在软件隔离实际应用研究方面, 文献[10]在SingularityOS上实现一种软件隔离进程(Software Isolated Process, SIP)的空间隔离方式。该空间隔离方式不依赖硬件MMU, 而是依赖软件静态验证与运行时检测, 保证应用程序中不会存在非法访存的代码。文献[10]软件隔离方式的优点在于消除了MMU造成的访存延迟和MMU切换的开销, 提升了操作系统访存性能与实时性, 但也存在鲁棒性不足的缺点。在安全关键的军事、航空航天领域, 嵌入式硬件通常运行在极端恶劣的气候、复杂电磁环境或高辐照环境中, 恶劣的硬件工作环境极有可能诱发硬件存储器比特位翻转, 导致非法访存的发生, 这是软件隔离分区所无法应对的故障。
本文在硬隔离分区和软隔离分区的基础上, 综合其优缺点, 提出一种软硬件分区混合的分区实现方式, 可在某些不支持MMU的硬件平台上实现分区功能, 同时兼具性能与鲁棒性。AgOS将分区分为安全关键分区(存在关键等级A~D的任务)与非安全关键分区(存在关键等级为E的任务), 如图 2所示。安全关键分区与安全关键分区、安全关键分区与非安全关键分区之间使用硬件隔离保证鲁棒性, 非安全关键分区与非安全关键分区之间通过软件隔离提升访存性能。
|
Download:
|
| 图 2 软硬件混合隔离方式 | |
同时, 对于硬件隔离的安全关键分区, 为避免分区内栈溢出造成分区内错误无法被发现, 本文实现的操作系统采取栈区、代码与只读数据区、数据区与BSS区依次布置的分区布局, 如图 3所示。采用该布局方式后, 无论栈指针向上向下溢出都会被硬件MMU所阻止, 进入对应的健康监测处理过程。
|
Download:
|
| 图 3 分区内部空间布局 | |
AgOS时间分区的调度由操作系统管理, 在时间上具有严格的确定性。分区按照固定周期的时间序列进行CPU资源分配, 每个分区按照主时间框架分配的分区窗口被时钟中断触发。
分区调度的基本单元是分区, 不存在优先级, 分区调度算法是固定时间片轮转调度, 按照主时间框架重复执行, 主时间框架被分成定长的Tick组成的序列, 每隔固定时间产生一次Tick时钟中断, 触发调度程序。如图 4所示。主时间框架的长度以及时间窗口的分配由分区、任务的Manifest所生成的配置表决定。
|
Download:
|
| 图 4 时间分区示意图 | |
AgOS采用ARINC-653标准规定的通道-端口式的分区间通信机制, 如图 5所示。标准规定2种标准的分区间通信方式:采样端口与队列端口。采样端口只保存最新消息, 后写入的消息会被之前写入的消息所覆盖; 队列端口不允许覆盖, 消息以FIFO顺序写入-读出。
|
Download:
|
| 图 5 ARINC-653通信示意图 | |
如图 6所示, 采样端口每次写入数据都会从通道缓存的起始位置0开始, 逐步向右推进, 直到缓存写满或者写入完成。同样采样端口每次读取数据也从通道缓存起始位置开始读。在该通信方式中, 前一次写入的数据会被后一次写入的数据覆盖, 正在被写入的采样端口不能被读取。队列端口则采用循环数组实现的队列结构, 由2个索引分别表示读与写。每次端口写入数据, 写索引右移; 每次端口读数据, 读索引右移。当读索引追上写索引时, 队列端口为空; 当写索引追上读索引时, 队列端口为满。队列端口读出的数据以FIFO顺序输出。
|
Download:
|
| 图 6 ARINC-653通道缓存示意图 | |
ARINC-653标准明确规定操作系统不同分区之间的运行不能互相影响, 但CACHE的会导致共享CACHE的分区内任务执行时间相互影响, 因此需要谨慎使用多个分区共享CACHE。
目前, 国内外均开展了有关CACHE分区技术[11]的研究, 但在大多数不支持硬件CACHE分区的硬件平台上, 禁用CACHE又会造成硬件资源的浪费。因此, 本文在不破坏确定性、保证分区间非干扰性的前提下, 提出一种CACHE策略。该策略基于ARINC-653操作系统运行的确定性, 运用静态分析与测试结合的方式, 得到操作系统和应用访存行为的统计结果。操作系统利用硬件CACHE锁机制, 将CACHE作为固定的高速SRAM使用, 在操作系统引导初始化时读取用户配置, 根据用户设定, 将操作系统最频繁读写的内存地址, 如任务控制块、分区控制块、任务栈中保存的执行现场等依次锁入数据CACHE, 将使用频率最多的中断服务程序与系统函数依次锁入指令CACHE。
中断响应、任务切换时会花费大量时间执行取指、保存执行现场、恢复执行现场等访存操作。应用该CACHE策略后, 由于中断响应程序以及执行现场都在CACHE中, 因此从CACHE中的取指令与保存-恢复执行现场的速度远快于从内存中执行对应操作, 并且CACHE在装入指定地址后是锁定的, 操作系统执行过程中不存在CACHE替换, 因此能保证分区间互不干扰的前提下, 利用CACHE优化实时性, 提升系统性能。
2.7 基于Manifest的任务与分区管理Manifest是用于描述程序的文件, 一般包含程序的名称、版本、依赖、权限等信息。Manifest在操作系统、编程中应用广泛。谷歌Andriod系统中利用Manifest文件描述应用程序的Java包名、组件、服务、权限乃至依赖的API、库等。微软.NET框架中利用Manifest文件描述应用程序项目构建的信息, 如类名、调用的DLL文件名及版本号与校验码等。Manifest的引入一方面可帮助程序员更方便地编写和管理应用程序, 改善程序兼容性, 另一方面也便于操作系统验证应用程序的可靠性, 提高系统安全性。
AgOS提出了基于Manifest描述的分区与任务。在编译AgOS应用程序的过程中, 每个合法分区都必须对应一个描述分区的Manifest文件。分区Manifest文件以XML格式表示, 包含分区名、分区空间配置、分区时间配置、分区关键等级、使用的外部设备、分区健康监测表入口等信息。相似地, 每个合法的任务也必须对应一个描述任务的Manifest文件, 该文件包含任务名、任务所在的分区、任务的时间-空间配置、任务的通信对象、所占用的通道、端口等。
在分区与任务的Manifest通过检查后, Manifest文件中包含的信息将被XML数据软总线传给代码生成器生成对应的源码与链接脚本。在进入到编译环节前, XML数据软总线将信息传送给软件静态分析器, 软件静态分析器根据分区信息分析分区内任务代码是否会访问分区外内存, 若存在非法访存则停止编译并报错。在通过编译后, 链接器再根据生成的链接脚本, 将应用程序链接到指定地址, 如图 7所示。
|
Download:
|
| 图 7 操作系统、配置信息及应用程序的编译链接流程 | |
在当前应用情形下, 分区数量和任务数量较少, 通常只有几个分区与任务, 一般由程序员在配置表中手动将任务分配到指定分区。但随着计算机硬件性能的提升与安全关键应用的不断发展, 例如综合航电系统的代码不断复杂化、分区的分布式实现, 可以预见未来安全关键嵌入式实时操作系统的任务数和分区数会逐渐增加, 且分区与分区之间的隔离程度也会提升。由程序员指定分配数量庞大的任务与分区不仅会耗费大量时间与精力, 还极有可能会产生分配错误, 这些错误轻则导致任务执行效率低下, 重则会导致生命、财产的损失。因此, 如何设计一个可靠的策略将数量庞大的任务分配到有限个分区中是一个值得研究的问题。
针对上述问题, 本文提出一种基于任务好感度的任务分区分配策略。在任务对应的Manifest文件中定义任务与其他任务的好感度, 例如在App1的Manifest中定义<suki task=“app2” value=“+1”/>, 表示App1对App2的好感度为+1。由相应的分区生成算法生成对应的分区, 好感度为正的任务之间倾向于分配在同一分区, 好感度为负的任务之间倾向于分配在不同分区, 好感度为0的任务不在意彼此之间是否在同一分区。任务有自我好感度的设定, 自我好感度为正的任务倾向于独自占有分区, 自我好感度为负的任务倾向于与其他任务处于同一分区。
在程序员配置分区时, 无需考虑整个操作系统有多少个分区以及分区中应用之间的关系, 只需考虑所编写的任务与其他任务的关系。这将极大减少程序员负担, 降低人为出错的概率。程序员可以通过修改任务好感度, 快速简便地调整任务所在分区, 提升任务执行性能。例如, 编写子系统A的程序员需要将计算任务A1与系统控制任务B1加入到综合航电系统中。他不关注其他子系统所占用的分区, 只希望计算任务A1与采集任务A2处于同一分区, 因为这有助于计算任务A1通过分区内高效的任务间通信机制快速获取采集任务A2的信息, 并且不希望控制任务B1与计算任务A1处于同一分区, 因为这不能隔离两者的故障。那么程序员只需将计算任务A1设定为“喜欢”采集任务A2, 控制任务B1设定为“厌恶”计算任务A1, 即计算任务A1对采集任务A2的好感度为“+1”且控制任务B1对计算任务A1的好感度为“-1”即可。这样在应用程序编译后自动生成的分区配置表中, 采集任务A2与计算任务A1处于同一分区, 而计算任务A1与控制任务B1处于不同分区, 如图 8所示。
|
Download:
|
| 图 8 基于任务好感度的任务分区 | |
AgOS内核在Freescale MPC 8xxx平台上编写实现。MPC 8xxx平台的硬件环境为:PowerPC e300核, 32 bit PowerPC RISC指令集, 主频666 MHz; 有8路组相联32 KB的ICACHE与DCACHE, 同时支持灵活的段页式MMU与高速的块MMU 2种MMU机制; 内存为256 MB DDR2 RAM, 工作频率333 MHz。
AgOS开发环境为基于Eclipse的专用集成开发环境。该开发环境集成了XML数据软总线插件, 提供静态验证工具以及AgOS对应的任务、分区、通道-端口配置环境。
3.1 原型系统软件隔离功能测试本文中操作系统的软件分区是由软件静态分析器保证, 使用Frama-C的访存分析阻止分区内的程序对分区外地址的非法访问。App1非法访存代码具体为:
1.int App1()
2.{ //app1所属分区1地址为0x00190000~0x001A0000
3.unsigned int a;
4.unsigned int *inPartitionMem=0x00194400;//分区//内地址
5.unsigned int *outPartitionMem=0xADEADBEE; //分区//外非法地址
6.*inPartitionMem=0xFFEEDDCC; //分区内合法写数据
7.*outPartitionMem=0xCCCCCCCC; //分区外非法写//数据
8.…//其他代码
9. }
当XML数据软总线将分区空间属性与C源码信息传给Frama-C, Frama-C对分区内写数据的合法代码予以通过, 对分区外非法写数据的代码报出错误:
App1.c:7 out of bounds write.assert\valid(outPartitionMem)
只有通过软件静态分析器的访存分析, 分区内的代码才能进入编译阶段。
3.2 操作系统基本功能验证AgOS操作系统基本的硬件隔离分区保护、任务调度、通信等功能的测试采用的测试任务集如表 1所示。主时间框架为序列{任务1, 任务2, 任务3}顺序执行。
|
下载CSV 表 1 基本功能测试任务 |
任务运行情况下的输出如图 9所示。串口循环输出并打印任务名及任务相关信息, 任务1的非法访问尝试被MMU阻止并跳转到任务1对应的健康监测函数内, 说明分区MMU保护功能有效。任务2成功打印来自任务3的消息, 即上一个主时间框架执行完后变量a的值, 说明跨分区间采样端口通信机制有效。
|
Download:
|
| 图 9 操作系统基本功能运行演示的串口输出 | |
驱动故障以串口速率不同步为例, 目标机端除去表 1中原本3个测例, 另外新增的驱动故障测例如表 2所示。宿主机不断向目标机发送‘+’号, 目标机端读取宿主机端发送的字符, 如果接收到‘+’号, 则表示正常; 否则错误次数累加。错误次数累加到1 900次后, 通过健康监测模块的APEX接口向操作系统发送错误代码, 操作系统跳转到分区健康检测入口, 执行对应的故障恢复程序。
|
下载CSV 表 2 驱动故障 |
测试结果如图 10所示, 目标机在执行任务4时由于串口故障, 输出的变量c的值是乱码, 且不能正确读取来自宿主机的‘+’号消息, 任务4不断累积错误次数。当错误次数累积到1 900次时, 操作系统调用APEX健康监测接口向操作系统发送错误代码, 操作系统跳转到分区健康监测入口, 执行对应的串口恢复函数, 即重新初始化串口。串口重新初始化成功, 打印出分区串口错误与健康监测恢复完成的信息, 继续执行变量c的累加并输出正常的字符。
|
Download:
|
| 图 10 串口驱动故障及恢复测试结果 | |
操作系统栈溢出通常发生在函数压栈或中断循环嵌套中, 本文采用无穷递归的测试方式, 模拟不断函数调用压栈导致分区栈溢出的情况。
栈溢出测例程序作为App4加入到测试任务集中, App4位于分区4, 分区内栈区域为0x001B000~0x001B4000。
程序运行结果如图 11所示, 无穷递归函数不断递归压栈, 当深度达到0x0001992时, 栈指针从0x001B4000不断增长到分区边界0x001B0000, 从而触发MMU保护。MMU中断产生后, 操作系统跳转到健康监测表中对应的栈溢出恢复程序。分区栈溢出恢复程序由用户定义, 本文的栈恢复程序重置分区相关属性, 并将该分区下所有任务设置成STATUS_RESET状态, 等待操作系统下次调度时重置该分区下的任务。
|
Download:
|
| 图 11 分区栈区MMU保护测试结果 | |
ARINC-653标准规定的内存隔离仅限于分区级, 分区内的每个任务的任务栈不能采用MMU中断触发健康监测的方式, 只能采用执行时检测的方式, 开销较大。该测试的测例同上, 测试结果如图 12、图 13所示。图 12说明当开启任务栈执行时检测功能, 任务调度器会在任务调度时动态检测当前任务栈占用率, 如果任务栈占用率异常, 则向任务健康监测模块报告错误, 将任务状态设置为重置状态, 待下次调度时重启任务。图 13说明任务完成重启, 重新开始执行。
|
Download:
|
| 图 12 任务栈溢出检测 | |
|
Download:
|
| 图 13 任务栈溢出恢复 | |
分时分区嵌入式实时操作系统的性能评价除了中断响应时间与上下文切换时间[12]外, 还有一项比较重要的性能指标:分区切换时间。本文将AgOS与其他嵌入式操作系统[13-15]进行对比, 如表 3所示。可以看出, AgOS在不使用CACHE策略的情况下, 中断响应时间略有不足, 使用CACHE策略优化后, 所有性能指标均优于比较系统。
|
下载CSV 表 3 AgOS与其他嵌入式操作系统的性能对比 |
本文在ARINC-653标准的基础上, 设计并实现了一种安全关键嵌入式实时操作系统内核, 并提出软硬件混合隔离分区方式、分区CACHE策略、基于Manifest的分区与任务管理策略、基于任务好感度的分区分配策略, 从而提高系统可靠性, 优化操作系统性能, 改善用户体验。原型操作系统的功能与性能测试结果表明, 该操作系统在安全性、可靠性等方面满足相关需求, 并且优于同类操作系统。下一步将研究虚拟化技术与ARINC-653分区的结合, 实现Hypervisor虚拟化分区。
| [1] |
LUTZ R R.Analyzing software requirements errors in safety-critical, embedded systems[C]//Proceedings of IEEE International Symposium on Requirements Engineering.Washington D.C., USA: IEEE Press, 2002: 126-133. https://wenku.baidu.com/view/e28b1048cf84b9d528ea7a93.html
(  0)
|
| [2] |
SAI global.Avionics application software standard interface: ARINC-653[S].AEEC, 1996: 1-29.
( 0)
|
| [3] |
RUSHBY J.Partitioning in avionics architectures: require-ments, mechanisms, and assurance: NASA/CR-1999-209347[R].Menlo Park, USA: SRI International, 1999: 34. https://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19990052867.pdf
( 0)
|
| [4] |
HERDER J, HERBERT B. MINIX 3:a highly reliable, self-repairing operating system[J]. ACM SIGOPS Operating Systems Review, 2006, 40(3): 80-89. DOI:10.1145/1151374 ( 0)
|
| [5] |
HUNT G, LARUS J. Singularity:rethinking the software stack[J]. ACM SIGOPS Operating Systems Review, 2007, 41(2): 37-49. DOI:10.1145/1243418 ( 0)
|
| [6] |
KLEIN G, ELPHINSTONE K, HEISER G, et al.SeL4: formal verification of an OS kernel[C]//Proceedings of ACM Symposium on Operating Systems Principles.New York, USA: ACM Press, 2009: 207-220. http://www.sigops.org/s/conferences/sosp/2009/papers/klein-sosp09.pdf
( 0)
|
| [7] |
GU Ronghui, SHAO Zhong, CHEN Hao.CertiKOS: an extensible architecture for building certified concurrent OS kernels[C]//Proceedings of the 12th USENIX Symposium on Operation Systems Design and Imple-mentation.Savannah, USA: [s.n.], 2016: 653-669. https://www.usenix.org/conference/osdi16/technical-sessions/presentation/gu
( 0)
|
| [8] |
WAHBE R, LUCCO S.Efficient software-based fault isolation[C]//Proceedings of Symposium on Operating Systems Principles.New York, USA: ACM Press, 1994: 87-94. https://wenku.baidu.com/view/efdb3a2b4b73f242336c5fac.html
( 0)
|
| [9] |
SEHR D, MUTH R.Adapting software fault isolation to contemporary CPU architectures[C]//Proceedings of the 19th USENIX Conference on Security.Berkeley, USA: USENIX Association, 2010: 1-12. https://www.usenix.org/legacy/events/sec10/tech/full_papers/Sehr.pdf
( 0)
|
| [10] |
AIKEN M, FÄHNDRICH M.Decontructing process isolation[C]//Proceedings of 2006 Workshop on Memory System Performance and Correctness.New York, USA: ACM Press, 2006: 1-10. http://research.cs.wisc.edu/areas/os/Seminar/schedules/papers/Deconstructing_Process_Isolation_final.pdf
( 0)
|
| [11] |
SOLER M, CRESPO A, MASMANO M, et al.Cache management techniques for time isolation in partitioned systems[C]//Proceedings of DASIA'12.Washington D.C., USA: IEEE Press, 2012: 14-16. http://adsabs.harvard.edu/abs/2012ESASP.701E..14S
( 0)
|
| [12] |
于东, 秦承刚, 吴文江, 等.一种实时操作系统的性能评估方法: CN201010580325.3[P].2010-12-09.
( 0)
|
| [13] |
林鹤, 李均, 朱怡安.基于μC/OS-Ⅱ的高可靠嵌入式操作系统的设计与实现[D].西安: 西北工业大学, 2016.
( 0)
|
| [14] |
朱怡安, 魏润之, 苏世游. 一种基于μC/OS-Ⅱ符合OSEK标准的实时系统内核设计[J]. 计算机科学, 2016, 43(4): 173-176. ( 0)
|
| [15] |
郭景, 陈贤富. 一种符合OSEK标准的操作系统微内核设计[J]. 微电子学与计算机, 2017(11): 16-22. ( 0)
|