基于RT-Linux防危保障机制的实验模型

摘要：随着嵌入式实时系统在安全关键系统中日益广泛的应用，其软件不但要保护嵌放式实时系统的功能性和时间限制，对其安全性、稳定性和可靠性的要求也大大提高。软件错误的比例大大高于硬件错误，软件错误可能引起硬件误操作，进而直接威胁系统安全。使用防危核可有效防止关键设备误操作。本文以RT-Linux实时操作系统为平台，对十字路口交通灯控制建立安全实验模型，硬件防危核实现技术，为防危保障探索新的实现途径。 关键词：防危核 安全核 实时系统 防危策略 早在19世纪70年代，为保证系统中的敏感信息不被非法用户恶意破坏和非法访问，Roger Schell和Mitre等人提出了安全核（security kernel）的概念。安全核将系统中的软件隔离为可信的和不可信的两部分，由可信赖信号负责对不可信部分进行审核，以保证不可信部分不会对敏感数据进行非法和错误的访问。安全核的技术在信息安全领域中取得了成功并得到广泛的应用。在安全核基础上，Rushby等人又进一步提出了防危核（safety kernel）的概念，用于防止软件对安全关键设备的非法访问，从而保障系统安全。防危核由一组防危策略和隔离组成，因此，防危策略的完备性和低开销是防隐核可靠和高效的关键。现在，对防危核的研究还处于初级阶段，本文介绍我们基于RT-Linux实现的队危核。实验结果表明了该方案的有效性和可行性。 1 防危核技术 防危核关心的是如何保护设备不被非法访问， 以避免因对设备的误操作引起的重大生命财产损失和环境破坏。防危核把受保护设备与系统中的其它部分隔离，通过实施防危策略（safety policy）对这些设备的访问进行特殊控制。凡是对受保护设备的访问，都必须经过危核的审查，合法者予以支持；反之，则采取相应的出错处理措施，维护系统的防危特性，这样就能很好地避免软件故障造成的灾难后果。从应用软件的角度来看，防危核的原理如图1所示。在工程应用中，要保证危核的有效性，必须遵循下列3项规则。 （1）短小精练 为了不影响系统的性能，防危核应尽可能小，为此系统所有的防危核策略均由防危核为实施是不现实的。采用将防危策略放在防危核外部的防危策略库中的方法，缩小防危核的大小主，防危核在防危处理时访问防危策略库，以获取相应防危策略。 （2）完备性 完备性要求，不通过防危核主体就不能对客体进行任何访问操作。它表明对设备的任何访问请求都必须通过防危核的验证。如果系统中存在其它组件可以绕开防危核访问设备，显然安全将无法得到保障。所以采用了防危核技术的系统必须要保证防危核对设备的专一控制。 （3）通用性 通用性指防危核模块的基本结构不依赖于任何特定的操作系统和设备，只需要操作系统和设备满足防危核的接口要求，并修改策略库，就可以将防危核软件应用到任何操作系统和设备中。 2 开发平台RT-Linux OS构架与特征 通常，安全关键系统对实时性有严格要求，我们选择RT-Linux操作系统为安全实验模型的开发平台。 RT-Linux是美国NMT大学对标准Linux的一个实时扩展版本，其结构如图2所示。它实际上是给原Linux内核打了实时补丁，打了补丁的Linux内核由两部分组成：RT-Linux和Linux。在RT-Linux内核实时应用（任务）则是一种可加载的内核模块，具有高的优先级。另外，所有的中断都先由RT-Linux来处理，之后才由标准的内核来处理。非实时任务通过RT-Linux提供的FIFO（一种透明的管道）与实时任务通信。 RT-Linux可以提供应用程序的硬实时保证。所谓“硬实时”是区别“软实时”而言的。硬实时对满足时限的要求比软实时严格，通常硬实时的系统响应时间在ms或μs级，而软实时对其响应时间的要求没有那么严格。硬实时工作通常指超过时限要求就会造成严重损害的工作，而软实时即使超过时限也不会带来严重后果。以核能电厂和看VCD为例，用在核能电厂的实时操作系统，如果超出时限可能会导致严重的损害，然而VCD播放器超出时限只不过让使用者感觉不舒服而已。所以前者是硬实时，后者是软实时。 这样一种Linux实时化方案，对原Linux改动最小，又能充分利用标准Linux的全部特性，从而能满足实时系统防危核控制模型研究的诸多要求，因此，NMT RT-Linux是本安全模型研究的最佳实验平台。 3 Linux平台的其它使用资源 通常，基于RT-Linux的应用程序由两部分组成：一部分运行在Real-Time下，另一部分运行在标准的Linux下。运行在Real-Time下的任务是实时任务，它作为Linux的内核模块（Module）被加载到Linux内核中，也就是它运行于Linux内核态，因此需要使用Linux内核态资源。本控制模型系统中的防危核正是作为实时任务运行于Linux内核态，而十字路口交通灯控制设备运行于标准Linux下。控制设备任务采用Linux的TCL/TK图形编程语言编程，以友好、形象、直观的界面模拟防危核对十字路口交通灯的控制。下面将分别介绍上述资源。 3.1 内核模块加载机制 Linux提供的可加载内核模块（Module）是Linux内核支持的动态可加载模块，它们是核心的一部分；但是并没有编译到核心里面去，只是一个目标文件，可根据需要在系统启动后动态地加载或卸载，Linux中大多数设备驱动程序或文件系统都做成这样的模块。超级用户可以通过insmod和rmmod命令分别载入和卸载模块。核心也可在需要时，请求守护进程（kerneld）载入和卸载模块。这种方式可以减小核心代码的规模，使核心配置更为灵活，并且用户不必每次修改后都重新编译核心代码和启动系统。 一旦Linux模块载入核心后，就成为核心代码的一部分。它与其它核心代码的地位是相同的。当模块载入系统核心时，系统修改核心中的符号表，将新裁入模块提供的资源和符号加载核心符号表中，新载入的模块可以访问已载入的模块提供的资源为自己服务。 3.2 TCL/TK图形编程语言 本系统中的图形用户界面采用TCL/TK图形编程语言，使界面友好、形象、直观。TCL是Tool Control Language（工具控制语言）的缩写。TK是TCL“图形工具箱”的扩展，它提供各种标准的GUL接口，以利于迅速进行高级应用程序开发。 TCL/TK是一种解释执行的脚本语言，应用中通常将嵌入到C程序中。“小巧、易学、高效、跨平台执行”是TCL语言特点的集中体现。实际上，TCL不仅仅在开发小的应用程序上有其快速、可维护性强等优势，在大型应用系统方面，如操作系统及网络管理、测试系统、自控、仿真、可视化应用及计算机辅助设计等方面都有丰富的应用成果。 4 防危核实验原型的设计与实现 图3为以交通灯控制为模型的防危核系统体系结构。 由图3可以看出，整个系统由四个部分组成：防危核、模拟设备、设备控制器、命令文件。防危核作为RT-Linux的实时任务，与模拟设备、设备控制器间的通信采用RT-Linux提供的实时FIFO；而模拟设备和设备控制器间的通信使用Linux提供的非实时命名管道。下面仔细分析各模拟所提供的功能。2⑤⑥⑦sΔδΛΔωω%26;#183;αγ∈βθθθ→→→→ττ 防危核模块的设计和实现 系统在运行时先通过命令insmod将防危核动态加载到Linux内核中，于是它便一直运行内核态。当不需要时再用命令rmmod手动卸载。这种方式下会对操作系统内核的基本功能产生任何影响，同时又可以保证demo系统的实时性。 防危核分为主模块和命令检测模块。主模块负责接收设备控制器传来的设备命令和模拟设备发送的设备状态，然后根据命令参数的不同情况进行相应的处理。如果用户要求命令不需要通过防危核验证，则直接将命令发送到模拟设备；如果用户要求命令通过防危核验证，则主模块将调用命令检测模块进行命令的合法性检测，命令检测模块以函数形式存在并且按照交通灯的防危策略而设计。函数名为int SafetyDetect（DevState CurrentState,SourceCmdNewCom），函数返回值为命令判断结果。如果验证设备命令合法，则主模块将设备命令及返回值一起发送到模拟设备，模拟设备据此改变设备状态；如果验证设备操作命令非法，则主模块向设备控制器返回命令检测模块的返回值，设备当前的状态不改变。 为使防危核尽可能小并具有通用性和扩展性，将含有防危策略的命令检测模块以函数的形式存在于防危策略库中，当防危核需要防危处理时，便到访问策略库中调用此相关函数。若设备改变，则只需向策略库中添加或修改相应设备的防危策略。另外，防危核作为内核模块，采用内核模块的编写方式编写，模块中只能使用系统调用函数。 下面定义以交通灯为模型的防危系统的防危策略。 返回值=0； /*表明经防危核验证为正确命令*/ 返回值=1； /*命令经防危核直接传送到模拟设备而未经过安全检测模块验证，模拟设备状态根据此值改变*/ 返回值=2； /*当前设备状态验证失败，失败原因不明。 措施：模拟设备保持当前状态不变*/ 返回值=3； /*同一个方向有多个信号灯同时开启。 措施：所有交通灯都关闭，然后在收到新的命令前设备执行缺省命令序列，此处由模拟设备接到“3”时直接处理*/ 返回值=4； /*四个方向同时为黄灯或绿灯。 措施：系统恢复到初始状态。在收到新的命令前设备执行缺省状态*/ 反回值=5； /*命令验证失败，失败原因不明， 措施：模拟设备保持当前状态不变*/ 返回值=6； /*信号灯保持当前状态的时间短于最短时间（<2s）， 措施：模拟设备自动延迟（Sleep(Time)）显示此命令*/ 返回值=7； /*使同一个方向有多个信号灯同时开启的信号灯命令错误。 措施：不执行此命令，保持当前信号灯状态*/ 返回值=8； /*命令的执行将会使信号灯变化的顺序不正确。 措施：不执行此命令，保持当前信号灯状态*/ 返回值=9； /*四个方面同时为黄灯或绿灯的命令。 措施：不执行此命令，保持不前信号灯状态*/ 4.2 模拟设备模块 防危核系统中以十字路口交通灯模拟外部设备。当经防危验证设备命令合法时，此模拟接受防危核传入的真实设备命令int RealCmd（），并向防危核返回设备当前最新状态。用图形方式形象、直观地显示设备本身的实时状态（交通灯颜色的变化）、模拟设备当前接收的命令和命令验证结果（合法或非法命令，对非法命令显示出错原因）。 该进程中设有三个线程，其中第一个线程专门用于读管道FIFO6（实时管道）获取防危核发送的控制命令，第二个线程读管道myfifo（非实时管道）获取命令控制器发送的设备控制命令，第三个线程用TCL/TK脚本语言实现模拟设备形象、美观的图形显示功能。当模拟设备启动后，自动进行初始化并调用缺省的交通灯控制命令序列完成基本操作，直以有来自设备控制和防危核的设备控制命令为止。若交通灯的显示时间超过一定时间，则强制设备执行缺省的设备状态。 4.3 设备控制器模块 模拟设备控制器作为一个进程独立运行，控制器先从命令文件中获取命令参数，然后根据命令的防危等级分别向模拟设备和防危核发送设备操作命令（包括正常的和不正常的操作命令）。命令中设置了时间控制参数，控制器按此时间间隔值发送设备命令。 4.4 设备命令文件 设备命令文件中存放了各种对交通灯的操作命令，包括正常和不正确命令。命令执行有三种防危等级可供选择：第一种，不通过防危核的命令，操作命令直接由设备控制器发送到模拟设备；第二种，通过防危核并验证其正确性的命令，此时防危核将调用防危策略库的相应防危策略验证命令，然后将验证结果发送到模拟设备；第三种，通过防危核但不验证设备操作的命令，命令被防危核直接送到模拟设备。设计三种等级命令的目的在于，比较是否使用防危核或是否进行命令验证在系统性能和防危性上的差异。 设备的命令格式为：char SourceCmd="Cmd east-light,Cmd north-light,Cmd west-light,Cmd south-light,int Time,bool Verifiedl,bool Verfied2"。操作命令要对十字路口的12盏交通灯进行操作控制。参数Time指本命令相对于前一条命令延迟多长时间发送。参数Verified1=0表示不经过防危核验证直接传送到设备的命令；Verified1=1表示要经过防危核验证。Verified2=0表示该命令直接发送到模拟设备不经过防危核的任何处理；Verified2=1表示该命令要通过防危核。 Struct Cmd { char first-light-color; char second-light-color; char third-light-color; } first-light-color,second-light-color,third-light-color表示每个方向三盏灯的颜色插入相应的颜色的图片。整个图形界面形象、美观。 5 实验系统的测试评价 根据防危核设计要求，从防危核的大小、对系统实时性的影响以及完备性三方面对本实验系统进行测试。 ①防危核大小：防危核所编译后的目标文件为5KB，相对于RT-Linux内核源码是非常小的。 ②时间开销：将防危核对控制命令验证所需时间进行了200次测试，得出其平均时间仅10μs左右，说明防危核对系统实时性影响非常小。 ③完备性：将防危核对第二种控制命令各种情况的防危处理结果表明，防危核的验证结果完全正确。说明满足防危核完备性要求。 以上对防危核的测试结果表明，本控制模型完全满足防危核设计要求，防危核机制完全可以在实时操作系统中使用。 结语 根据防危核等相关理论并结合RT-Linux操作系统本身的特色，本文先从理论上分析了在RT-Linux中实现防危核的可行性，然后通过实际例子实现了基于RT-Linux的防危核，为防危核探索了一种新的实现途径。最后，通过对实验系统的测试进一步证明防危保障机制在实时操作系统中完全可行