在安全关键系统的设计里，把不同任务分到不同的目录下面，并不等于就实现了真正的分区隔离。分区要做的事情，是把安全等级、实时性要求、内存使用、设备访问和通信关系这几样东西全都隔离开来，让它们互相之间不会产生不必要的影响。在Green Hills INTEGRITY这个实时操作系统中，划分好分区以及检查每个分区的资源限制，是两项很关键的工作，而且应该先想清楚哪些功能必须互不干扰，再给每个分区分配好固定的资源额度。

　　一、Green Hills INTEGRITY分区应当怎样进行划分

　　给系统做分区划分，最好在架构设计阶段就着手进行，不要等到全部代码都写完了，再反过来硬拆。一般来说，可以按照安全等级、功能之间的边界，以及故障一旦发生以后会波及到的范围，来把不同的功能放到不同的分区里去。

　　1、对照安全等级来划分分区

　　那些跟安全功能直接相关的关键控制逻辑，和只负责普通监控任务的逻辑，还有诊断服务、通信网关这类辅助功能，不应该随便混在同一个分区里面。安全等级越高的那些功能模块，越要尽可能地减少跟低安全等级功能之间的直接共享，避免因为低安全模块的异常而牵连到自己。

　　2、从故障隔离的角度划分分区

　　当系统中某个应用程序发生了崩溃、出现了内存越界访问，或者占用了过多的CPU时间时，不能让这些意外事件把其他关键任务也一起拖垮。INTEGRITY-178 tuMP这个版本就重点强调了通过时间、空间和资源的分区，来尽量减小各个应用之间非预期的相互影响，所以容易出故障的功能，和绝对不能受影响的功能，应该分别放进独立的分区里面。

　　3、按照通信关系来划分分区

　　分区跟分区之间，只应该开放那些确实有必要保留的通信通道，而不是把所有的接口全都打通。像共享内存、消息队列、直接访问其他分区的设备，还有对系统服务的调用，都需要在系统配置文件里面一项一项地明确下来，不能图省事就临时把所有接口都放开，否则分区之间本该有的隔离边界就会形同虚设。

　　4、结合设备资源来划分分区

　　对于那些只能被一个分区独占使用的设备，尽量就只分配给那一个分区去管理；而必须要被多个分区共同使用的共享设备，则要通过受控的服务或者专门的驱动程序来统一管起来。比如说通信控制器、存储设备、传感器接口，还有调试用的通道，都要在配置的时候规定清楚各个分区分别拥有什么样的访问权限，谁可以碰，谁不能碰，都得有明确的说法。

　　二、Green Hills INTEGRITY分区资源限制应该怎么进行检查

　　要想检查每个分区的资源限制是不是落实到位了，不能光看系统能不能正常启动，还要去查看静态配置文件、运行时的日志，以及实际的负载情况。必须确认好CPU时间、内存用量、设备占用和通信资源这几个方面，都没有超出当初给它们划定的范围。

　　1、检查静态配置文件中的资源分配

　　根据INTEGRITY-178相关的安全目标资料，系统架构师会提前创建一份静态的配置文件，在这份文件里面把各个分区、任务集合、内存对象、链接关系、连接通道、时钟，还有分区的调度机制，全都一项一项地定义好。所以做检查的时候，第一步就可以拿着这份配置文件，去看看每一个分区到底被分配到了哪些资源，有没有遗漏或者冲突的地方。

　　2、检查内存边界是否被突破

　　需要逐一核对每一个分区的代码区、数据区、堆区、栈区，还有共享内存的范围，看它们是不是全部落在预先分配好的空间里面。如果在运行的时候报了内存访问异常，那通常就要去查一下，是不是有某个任务访问了它没有权限去碰的地址，或者当初划分给它的栈空间、堆空间，在配置时设得太小了，已经不够它正常运行使用了。

　　3、检查CPU时间预算有没有被超支

　　实时任务需要有清楚的时间窗口和明确的优先级安排。Green Hills的相关资料里也提到过，INTEGRITY能够给每个进程分配一笔固定的CPU时间预算和内存预算，从而防止某个进程占着CPU一直不释放，超出当初分配给它的时间窗口。要是发现有任务执行超时了，就应该去检查一下它的运行周期、实际执行所需的时间，以及调度器分给它的时间预算是不是设置得偏小了。

　　三、Green Hills INTEGRITY分区配置完成之后应该怎样进行复核

　　当分区的各项配置都做好了以后，还需要通过实际的测试，去验证隔离效果是不是真的达到预期了，而不仅仅是靠代码评审或者文档检查就认为万事大吉。只有用测试的手段来确认，才能更有把握地说分区的设计是靠得住的。

　　1、用越界访问测试来验证内存隔离

　　可以考虑在一个非关键的分区里，故意构造一次非法的内存访问操作，看看系统能不能够及时把这次错误给拦截下来，并且确认这个故障并不会扩散到其他关键分区里去，关键分区的功能依然能够不受干扰地继续运行。如果连这点都做不到，那就说明内存隔离这一道防线还存在漏洞。

　　2、用CPU抢占测试来检查时间隔离

　　试着让一个普通分区去执行一些高负载、非常占用CPU资源的任务，同时去观察那些安全关键分区，是不是仍然能够按照事先设计好的周期准时调度运行。要是发现关键分区里面的任务抖动变得很厉害，执行时间明显被拖慢了，那就要重新去检查一下当初分配给它们的时间预算，以及多核环境下共享资源所带来的干扰是不是没有得到合理的控制。

　　3、检查通信白名单是不是真正起效了

　　把各个分区之间允许进行的通信，逐条去验证一遍，确保那些在配置里放开了的通信确实能够正常工作；同时也要验证，那些没有在配置里放开的通信请求，会被系统正确地拒绝掉。通过这样正反两个方向的测试，就能确认当前的通信配置并没有被悄悄弄成“全放开”的状态，分区之间仍然保持住了应有的通信隔离。

　　4、妥善保留配置基线

　　分区划分的表单、内存分配的方案、调度时间窗口、设备授权的清单，还有分区间通信关系的描述，这些内容都应该形成固定下来的版本记录，而且每次新增功能或者修改现有任务的时候，都要重新做一遍资源层面的影响分析。只有这样，才不会因为一次不经意的改动，就把原本设计好的隔离边界给悄然打破。

　　总结

　　在Green Hills INTEGRITY中划分分区和检查分区资源限制，总体的思路是先从安全等级、故障隔离、通信关系以及设备资源这几个维度，把系统划分出清晰的边界；检查的时候，把重点放在静态配置的内容、内存范围、CPU时间预算和共享资源的限制上；等到配置完成以后，再通过越界访问测试、CPU抢占测试和通信白名单验证这些手段，实际确认一下隔离的效果到底有没有真正到位。经过这样从设计到验证的完整流程，分区方案才能算是真正可靠。