嵌入式系统安全性对攻击状况和防卫策略

那样，是按照一个固定的进度表来分配系统资源的程序。商业上典型的具体实施方法是在内核模式下运行微调度程序，并且作为主控来控制一个客户操作系统，该OS也在类似的内核模式下进行操作。从安全的角度来说，这意味着客户操作系统一定得是一个"良好的市民"，因为客户完全可能绕过微调度程序。这使得整个空闲的存储器易受攻击。为了消除这个弱点，微调度程序的开发者增加了一个可供选择的安全引擎，以监测和控制硬件的访问。

　　图2 使用微调度器的虚拟化

　　微内核（图3）本质上是一个操作系统，这个系统移去了大量的典型操作系统服务，并代之以可以在用户级别执行服务的机制。从安全的角度来看，它的优点是，用户模式实体访问底层硬件时不具有危险性，因为内核模式指令调用已被移去。其缺点主要是多重处理域的维护，当执行从微核的本地处理区运行到客户操作系统及其应用程序处理区时，这些处理域需要具体实现复杂的进程间通信（IPS）机制和额外的环境转换。

　　图3 基于微内核的虚拟化方法

　　虚拟的另一个途径是产生一个硬件抽象层（HAL），并增加额外的服务，以照顾多重执行环境 （图4）的需求。HAL是一个硬件微薄转换层，它可以使得软件具有更好的可移植性。为增加对多重执行环境的支持，开发者创造了超微内核，尽管这种表述不是很准确。在实践中，这种途径和微核型解决方案的不同之处是，虽然微核在设计时已经考虑到要运行某种客户操作系统，而HAL更趋向于以硬件为中心，而且并不了解操作系统的具体情况。

　　图4 利用HAL或者超微内核性管理程序实现的虚拟化

　　从安全的角度来说，最关键的因素是所有商业管理程序控制对硬件资源（如MMU系统）访问的能力。例如，如果一个客户端应用程序（比如web浏览器）被一个流氓HTML站点所破坏，并试图侵入存储器禁区，那么系统管理程序就会向存储器强加边界，并适当地保护敏感数据。通过使用安全的系统管理员，根据驻留在特定的执行环境中的应用程序的已知边界检查可疑的重填数据，就可以实现由软件填充的TBL不受侵扰，由此保证程序的执行处于"界限内"。在路由器或其他客户端装置中，系统管理程序可以用来提供一定程度的DoS保护，这可以通过使用多重VM来控制对任何特定资源的访问或是要求提供适当的通行证来实现的，这样做可以避免VM使用"界限外"的资源。

　　在虚拟化架构的设计过程中，虚拟计算机之间的默认通信途径要尽可能减少，理想的情况是，如果从VM到VM没有公开昭示的授权的话，最好没有任何通信。

　　由于增加一个VM的开销是很低的，用VM自己已经完成引导的、处于挂起状态的"候补"操作系统来生成"候补"VM是可能的。那么，当一个处理域被DoS所危及时，一直在自己的执行环境中运行的系统健康度监督程序，可以将被危及的VM的执行挂起，将激活的程序转移到候补的VM，并继续执行。这种方法在受到攻击的情况下维持更长的计算机正常运行时间。

　　由于VM一般来说必须从CPU时间和可用内存的角度来公开地界定，VM所需要的资源在DoS面前仅呈现一个很小的"攻击面"，在一些情况下，可以通过限制收到的消息数量来进一步限制弱点的发展，从而避免饱和攻击。

　　将认证机制扩展到虚拟计算机上可以使安全导入机制变得更健全。硬件引导完成后，安全引导机制标记第一个VM。第一个虚拟机可以执行第二个层次的安全引导，通过额外标记和经过验证的VMs来扩展"信任链"，直到系统饱和以及所有物理、虚拟计算机序列导入完成。

　　就所有系统的基础部分而言，需要分析其优点和缺点。系统管理程序提供了一个高水平的安全性和执行环境之间的隔离。但是，当数据必须在环境之间共享时，会发生什么情况呢？很多系统管理程序通过生成通信渠道或是共用执行环境中的存储器区域来处理这个问题。这随之又造成了第二个层次上的弱点，所以应该确定这些通道不会被恶意软件利用来将数据从安全的/可信任的区域转移到不安全/不可信任的区域。在这些种类的环境中，可以运用分层的方法。例如，可以纳入一个激励/响应机制，来实现数据通过共用存储器在各执行环境之间的转移。当这种机制就位时，不可信区域的安全就会到危胁，危险就会侵入共用存储器区域，但它仍不能从可信区获得数据。举对Web浏览器的例子来说，攻击者可能会获得进入存储器共享区的许可，但它们不能侵入激励/响应机制，因此，敏感数据就不会从安全区转移到共用存储器区。

另一个系统级问题会影响虚拟化的运用的地方，是系统管理程序的响应时间。如果响应时间使实时操作系统（RTOS）不能在系统管理程序层