现代操作系统在其技术复杂度、软件规模、机电部件不断增加的同时，也引入了额外的系统性失效和硬件随机失效风险。有什么理论和方法能够将软件失效及其导致的风险控制在可接受的范围内呢？兰州大学OpenHarmony技术俱乐部主任周庆国教授在第一届OpenHarmony技术峰会上分享了几点思路。

01►

安全与安全关键

“安全”对应的英文释义有Safety和Security，两者存在很大的区别。Safety-IEC 61508 Part 2 中将Safety定义为：将能够造成人员伤亡或财产损失以及严重破坏环境的危险降低到可以接受范围；Security-IEC17799 Part 1 中将Security定义为：保护外来伤害的能力，适用于脆弱和有价值的资产，如人、组织、住房、国家等。Safety的关键因素在于：（1）可预测性（Predictability）：系统中可能会出现的风险情况应该均可以被考虑到；（2）确定性（Certainty）：系统的行为可以被预测，且风险均在可控范围内；（3）确信度（Degree of certainty）：系统提供方对目标系统的可预测性和功能确定性是有效的，并提供相关证明。

部分安全关键行业

功能安全也称为安全关键，关注的是系统发生故障之后的行为，通常应用于系统失效会对人和财产及环境造成重大伤害和损失的场景，如核电站、航天航空、军工、医疗等领域，乃至当下热度极高的自动驾驶领域。在国际电工委员会发布的IEC61508功能安全标准中，以安全完整性 （Safety integrity）来评估安全相关系统成功实现所要求的安全功能的概率，并规定了四个安全完整性等级，第四级(SIL4)表示最高的完整性程度，第一级(SIL1)表示最低，不同的等级由每小时发生的危险失效概率决定。

安全标准-IEC61508与安全完整性等级划分

在IEC61508中定义了Type-A和Type-B两种类型的系统，其中Type-A系统的判定标准为：（1）所有组件的故障模式都已定义；（2）可以确定故障条件下的组件的行为模式；（3）对于系统声称的故障率有足够可靠的故障数据。只要满足以上任意一点的就是Type-A系统；而Type-B系统则正好与之相反。

在传统的安全系统设计中，人们更多处理的是Type-A系统，因为传统的系统大都是低复杂度的系统，人们对其的理解至少符合上述三种标准之一，因而可以处理系统中潜在的风险所导致的系统失效。而自动驾驶为例的安全关键系统在要求系统高安全高可靠的同时，还对系统的功能丰富度以及系统性能方面有较高的要求，因此在系统中将大量使用高度复杂的Type-B类型组件(如Linux内核、人工智能模型等)。对于这类高度复杂的组件，传统的安全分析与验证无法对其失效模式与失效行为进行有效管理与缓解，为系统的安全关键验证带来巨大的挑战。

02►

Linux在安全关键领域应用

Linux作为一个性能稳定的多用户网络操作系统，拥有几大比较突出的优点：（1）迭代频率高：拥有千万行级别代码和百万行级别文档；每个版本提交频率达数百次/天；开发人员众多，社区活跃；Linux已经是现存最大、最活跃的开源开放软件生态之一。（2）开发质量高：Linux内核采取开源社区开发，开发过程高度透明，且具有严格的项目管理流程；它的开发过程使用规范的设计、测试和版本维护方法；每天都会有大量的修改提交以保证Linux内核版本的稳定。

Linux开源项目

然而，目前并没有一套明确的方法对Linux进行安全验证，Linux作为一个高度复杂、有着超两千万行代码量的庞然大物，其验证的工作量更是巨大。一个面向安全关键场景的系统需要采取一些方法提供足够的证据来验证系统是安全的、符合安全标准规范的，还需要满足一系列的功能安全要求来提供当系统遇到操作失误、系统内部故障时的应对策略。Linux并没有贯彻IEC 61508标准中要求的安全开发生命周期。目前，基于Linux的安全关键系统的安全认证工作中，最大的挑战在于缺乏完善的文档和工具来证明基于Linux的Safety-critical系统的安全性。

2015年由宝马、西门子以及德国开源软件实验室OSADL等出资合作的SIL2LinuxMP项目，旨在为工业界提供一套验证基于Linux Kernel的Safety-critical系统安全性的方法。项目基于IEC61508标准的要求，提出对Linux内核验证的关键是利用系统开发的上下文将庞大的Linux内核限制在一个相对小的验证范围，并尝试利用Linux内核的复杂性与不确定性进行系统的安全加固。

2019年Linux基金会启动了ELISA开源项目，该项目在SIL2LinuxMP项目的研究基础上进行。其目的是为了协助相关公司对基于Linux的Safety-critical系统实现一系列工具，以避免其系统运行失败造成的人身伤害，重大财产损失或环境污染。该项目定义和维护一组用于Linux安全关键验证工作的通用的元素、流程和工具，为期望将Linux应用于安全关键系统的企业和机构提供支持。

03►

SIL2LinuxMP项目

SIL2LinuxMP项目选择内核元素与非内核元素作为预先存在的组件，提出对Linux开发过程持续的监测，并通过相关工具的认证、预先存在组件的认证等一系列协同认证等方法对Linux内核评估认证以满足系统安全规范的要求，在这一过程中，Linux内核的认证数据和认证方案为认证评估提供重要依据。

SIL2LinuxMP项目总览

在SIL2LinuxMP项目研究过程中发现，Linux内核的容器技术提供了足够的隔离能力，避免了虚拟机监控程序带来的运行开销和验证成本以及对硬件虚拟化的依赖，因此基于Linux内核容器技术提出了分区隔离架构：SIL2LinuxMP Architecture，简称SIL2Arch。SIL2Arch组合了Linux内核原生提供的Namespace、Cgroup和Seccomp等容器技术，将系统资源以容器的形式进行分区与隔离，可以用于对Linux内核中不同安全完整性等级的任务进行分区隔离。

SIL2Arch的实现

目前，SIL2LinuxMP项目的研究缺少对动态执行路径不确定性的原理讨论，而且分区隔离架构的部署也可能会对动态执行路径造成影响。针对该情况，周庆国教授所在团队研究了以下3部分内容：（1）部署对照实验环境，并设计开发了自动化执行路径采集工具SIL2Trace；（2）构建执行路径调用关系的有向图，分析Linux内核动态执行路径不确定性的原理；（3）采用自相关检验和泊松回归模型，评估容器分区隔离架构对于执行路径种类数量的影响。具体如下：

动态执行路径测试范围选择：Linux内核是一个庞大且复杂的软件，进行全面的测试覆盖难度较大，可以选择在固定输入参数下，特定用户应用程序所主动请求系统调用执行的Linux内核执行路径作为主要测试范围。

自动化采集工具SIL2Trace设计：为了记录实验中目标测试程序的内核函数执行路径，基于Ftrace内核函数跟踪框架设计实现了自动化采集工具SIL2Trace。SIL2Trace分为客户端程序和服务端程序，客户端程序将多次重复触发执行目标测试程序，借助Ftrace进行执行路径采集，并将数据通过网络传输给服务端程序。由于Ftrace所采集的数据中会包含一些无关的执行路径， 因此服务端程序将对执行路径中的无关路径进行过滤处理。

无关路径过滤

动态执行路径不确定性原理分析：导致路径不确定性的主要原因是在执行主干之外的函数调用时产生的调用分支。这些分支是由于与输入参数无关的全局状态变量引起的，它们会影响Linux内核的全局运行状态，从而导致动态执行路径的不确定性。

动态执行路径种类数量估计：首先需要验证执行路径之间的相关性，若执行路径之间存在相关性，将影响对动态执行路径种类数量的估计。利用统计学中的自相关检验方法计算路径之间的自相关系数，检验结果显示执行路径之间具有独立性。

04►

OpenHarmony与安全

OpenHarmony目前在活跃开发之中，厂商开发的产品不仅可能引入经典的开源项目，还可能包含具有OpenHarmony特色的组件，这对厂商的软件供应链安全管理能力提出了更高的要求。

开源软件供应链

以安全漏洞为抓手，实现函数级跨架构漏洞检测驱动的软件成分分析，从而有效帮助社区中的企业构建低成本的软件供应链安全管理方案。目前，周庆国教授所在团队已经为基于Linux的物联网设备设计了高精度的跨架构函数级漏洞检测技术方案。在实验室场景下，平均检测准确率已经超过 99%，可以有效地为不具备精细三方件管理能力的中小型开发者提供面向最终产品的软件供应链漏洞检测。

函数级漏洞检测技术方案

此外，OpenHarmony在安全关键领域还有以下等方向可以进一步讨论和研究：

• 根据功能安全标准对OpenHarmony开发过程中的开发流程、技术文档、风险管理、安全分析等方面进分析与扩展。

• 对OpenHarmony的开发生命周期进行系统的和持续的研究，试图建立度量开源软件系统的稳定性或发展趋势的指标体系。

• 尝试应用数学模型结合统计测试对OpenHarmony可靠性等进行研究，试图建立相关本质特征反应的可应用评测体系。

• 针对风险空间中严重性等问题进行深入研究，结合Machine Learning/Deep Learning等技术对其进行分类，试图结合具体功能安全标准进行风险分段及风险缓解。

• 基于新型图表示和图学习技术，研究面向OpenHarmony的跨架构函数级漏洞检测技术，试图为社区提供新型软件供应链安全管理方案。

目前，兰州大学OpenHarmony技术俱乐部已经正式成立。后续，俱乐部将结合操作系统与软件安全等研究内容开展相关工作，欢迎大家的持续关注和监督，也希望大家能够共同为OpenHarmony技术生态的繁荣贡献力量。