自适应AUTOSAR系统安全评估（四）：在Linux中实现软件安全机制

专栏作者 2023-09-25

内容提要：此文为该连载系列的“第四”篇章，在之前的“连载（三）”中已经详细评估了GNU/Linux作为ISO 26262背景下安全关键环境中自适应平台操作系统的适用性。那么，在本连载（四）中，我们将具体在Linux中实现软件安全机制。

《功能安全环境下自适应AUTOSAR系统的评估》专题连载共分为“五个”篇章。此文为该连载系列的“第四”篇章，在之前的“连载（三）”中已经详细评估了GNU/Linux作为ISO 26262背景下安全关键环境中自适应平台操作系统的适用性。那么，在本连载（四）中，我们将具体在Linux中实现软件安全机制。

5.实施

本章的目的是在Linux中实现软件安全机制，以控制不同关键系统之间的操作系统资源访问，特别是计算时间和内存使用，从而实现不受干扰。为此，AUTOSAR自适应平台演示系统应用程序被视为安全关键应用程序，旨在保护其所需资源免受非关键任务的影响。

本章首先描述了AUTOSAR自适应平台演示系统的应用程序，包括其软件架构、功能描述和开发环境Yocto，然后说明了实现的软件划分机制。

5.1 AUTOSAR自适应平台演示系统

AUTOSAR自适应平台演示系统用于通过真实的用例评估AUTOSAR自适应系统，通过该用例可以演示和测试真实的应用程序，使其超越简单的Hello World应用程序。如下图所示，演示系统由一个在主机系统上执行的测试应用程序和一个在自适应AUTOSAR BSW上运行的自适应高级驾驶辅助系统（ADAS）应用程序组成——所有这些都在MinnowBoard Turbot（第5.1.5节）硬件平台上实现。自适应ADAS应用通过“紧急制动系统”进行了演示，该系统在如何利用计算、内存和通信资源方面为硬件和软件平台产生了现实的工作量。测试应用程序分别将应用程序的传感器和执行器模拟为单声道摄像机记录的视频流输入，并将制动信号模拟为执行器的可视化输出。测试应用程序由ITK开发，为AUTOSAR自适应平台演示系统提供图形前端用户界面。

图15：自适应平台演示系统概述

5.1.1系统功能描述

这个基本的ADAS应用程序实现了基于检测对象的车辆检测和紧急制动功能。每辆车的速度和位置是根据估计的未来位置计算的。单个摄像头的输入用于检测车辆并计算其随时间变化的速度和位置，并相应地使用当前速度来设置紧急制动的阈值。该系统假设车辆可以获得完美的里程表数据，一旦触发紧急制动，应用程序就会启动完全制动，直到完全停止。

5.1.2软件组件描述

演示的“紧急制动系统”由四个组件组成，这些组件集成在MinnowBoard涡轮板上运行的自适应AUTOSAR BSW的顶部。每个组件都按照流水线处理模式同时运行自己的应用程序进程，其中每个组件的输出都作为下一个组件的输入进行处理。然而，当每个组件在不同的阶段处理数据时，每个时隙都会生成最终输出。

5.1.2.1视频适配器

视频适配器通过基于TCP/IP以太网的连接建立与测试应用程序的连接。它在成功订阅后接收视频帧，并通过SOME/IP将其作为原始数据移交给下一个组件。

5.1.2.2预处理

预处理组件通过Harris-Stephens算法检测图像中的边缘来实现图像处理和特征检测功能。然后，它将检测到的边缘发送到计算机视觉组件，以识别感兴趣的点。

5.1.2.3 计算机视觉

计算机视觉组件负责车辆检测，方法是根据旧帧中保存的位置数据和近似轨迹计算车辆的位置和碰撞前的时间。然后，它将每个检测到的车辆的轨迹和计算出的碰撞时间发送给EBA。

5.1.2.4 EBA

EBA组件基于简单的决策树系统评估检测到的车辆/物体的威胁（例如前方、离得太近…）。如果假设评估需要制动，它将发出紧急制动信号，由测试应用程序发送和呈现。

5.1.2.5 试验应用

测试应用程序组件通过与视频适配器和EBA组件建立连接，通过前端用户界面模拟传感器和执行器节点。测试应用程序在Linux主机上运行，通过该主机通过TCP/IP建立与MinnowBoard的连接。视频流被发送到视频适配器，制动信号通过SOME/IP从EBA组件接收，如图15所示。此外，它还显示“制动信号”的状态、车辆的当前速度以及发送到视频适配器的帧，如图16所示。

图16：APD测试应用

5.1.3 系统动态行为

正如连载（一）的第2章所讨论的，自适应平台的通信基于面向服务的体系架构（SOA）方法，其中组件之间的通信是通过SOM/IP协议建立的。这允许在启动和运行时启动通信路径，支持平台的自适应方法。类似地，ADAS应用程序的软件组件通过SOME/IP进行通信。（组件之间的）通信路径是在每个组件通过特定的服务ID成功订阅其所需服务后建立的。循环定时器每50ms触发一次每个函数获取其所需服务的过程，同时，它们每50ms向要订阅的其他组件提供服务。这使得所有组件之间的数据交换在50ms的事件基础上进行，并有助于实现前面描述的并发性。如果像计算机视觉这样的功能需要更多的时间来处理数据，则将工作分为两个线程，目的是在周期计时器触发事件时，每50ms提供一次数据。

5.1.4 系统环境

自适应AUTOSAR BSW是由Yocto项目开发环境生成的嵌入式Linux映像，应用程序正在其上运行。Yocto项目是一个开源项目，它提供了可互操作的工具、元数据和流程，可以创建快速定制的基于Linux的操作系统。该项目是与OpenEmbedded的共同努力，后者提供构建系统“Poky”来构建创建的图像。

Linux映像是使用元数据描述的，元数据由专门的配置组成，这些配置以配置文件（.conf）、处方（.bb）和类（.bbclass）的形式出现。这些元数据以层和所谓的元层的形式组织，元层是告诉编译器该做什么和如何做的主要输入。构建系统Bitbake解析所有处方，从外部存储库获取所有需要的源，配置软件，并编译源以生成Linux映像。处方在这个过程中起着核心作用，因为它们将整个图像描述为更小的库，当它们放在一起时，就会形成整个图像。

5.1.5 MinnowBoard Turbot

MinnowBoard Turbot用于运行AUTOSAR自适应平台演示程序作为其硬件平台。它是一个紧凑且价格合理的开源开发板，带有64位Intel Atom™ E38xx系列片上系统（SoC），集成Intel HD Graphics与Linux操作系统的开源硬件加速驱动程序和2GB DDR3 RAM。尽管体积很小，但它提供了广泛的功能，包括运行Linux和Windows等操作系统的台式电脑版本。

图17：MinnowBoard Turbot

此外，创建的Linux映像可以通过可引导的USB拇指驱动器或microSD卡执行，从而实现快速开发和原型设计。如图15所示，MinnowBoard Turbot通过TCP/IP连接到主机，视频适配器通过TCP/IP接收视频流，由应用程序进行处理，EBA组件发回制动信号。

5.2 分区机制方法

可以通过创建处方并将其集成到图像构建中来定制生成的图像，因为每个处方对应于形成生成图像的构建块的一块软件。一些处方对于表示操作系统核心功能的构建系统是强制性的，而其他处方则满足定制的预期功能的特定要求。

因此，目的在于将所需的特征作为处方集成到生成的图像中。内核功能控制组（称为Cgroup）被集成到生成的映像中，目的是通过将任务分组到具有与CPU资源相关的特定配置行为的层次树中来提供一种分区任务的机制。可以根据配置允许或拒绝某些任务组使用资源（例如CPU时间、系统内存、网络带宽，甚至这些资源的组合）。此外，重新配置可以在运行时动态发生，甚至子进程也继承属于某个组的父进程的属性。例如，Cgroup1可以被授予20%的CPU和25%的内存，而Cgroup2被授予30%的CPU和仅5%的内存，如下图18所示。因此，允许监视和控制特定群体的资源访问（消耗）取决于他们的需求及其对系统安全角度的重要性。

图18：Cgroup控制的资源

内存子集允许动态内存分配限制，其中静态内存分配是由GNU/Linux的内存管理单元（MMU）实现的，它已经虚拟化了每个任务的地址空间。

其目的是将Cgroup包含在生成的映像中，目的是在自适应平台演示系统应用程序关键任务上实施分组方法，以保护其所需的资源。这将保证自适应平台演示应用程序任务与可能危及应用程序所需资源可用性的非安全关键任务共存。因此，会影响应用程序的预期功能并危及系统的整体安全。

5.2.1 控制组的配置

Cgroup处方已经存在，并由GPLv25授权，作为其元虚拟化层的一部分，可以通过Openembedded以“group-lite 1.1”的形式获得。因此，这里的要求是将处方集成到生成的Linux映像中。这是通过首先在层之间构建所需的依赖关系，并克隆处方所属的正确分支来完成的。然后通知Bitbake新的依赖项，以便成功安装处方。

Cgroup配方如下：

图19：Cgroup-light 处方

为了使用所需的处方为正确的目标生成图像，必须在开始构建过程之前执行一些配置。这是通过以下方式完成的：

1）包括系统构建和更新元数据所需的层

2)编辑Bitbake的conf/bblayers.conf以在所包含的层之间构建正确的依赖关系：

3)更新conf/local.conf文件以将软件包与目标平台一起安装

4）最后，准备构建并开始编译

构建完成后（根据笔记本电脑的性能，可能需要长达2-3小时），输出文件可在“tmp/deploy”文件夹中找到，其中安装了Cgroup功能，并准备好在运行的目标硬件上刷新定制的嵌入式Linux映像。无需重新启动构建即可安装更多功能，因为构建过程是增量的；这意味着它可以识别更改并且不需要重新运行未更改的文件。以同样的方式，通过使用 IMAGE_INSTALL_append = “htop”编辑conf/local.conf来安装“htop”，稍后将使用它来评估系统性能及其资源使用情况，作为验证过程的一部分。

在下一子章节中，介绍Cgroup的激活，目的是为自适应平台演示器的软件组件及其安全关键任务提供对CPU资源的特权访问，同时将其他被视为非关键任务的任务包装在对CPU资源访问有限甚至没有访问权的组中。

5.3 分区机制的实现

本子章节的目的是实现Cgroup分组机制，使自适应平台演示系统所需的资源可用，并免受其他可能消耗应用程序所需资源的非安全关键任务的影响。进而导致应用程序无法按规定执行，导致失效并危及整个系统的安全。分组机制的实现重点是限制CPU时间和内存使用量（以字节为单位），作为一种软件安全机制来管理安全和非安全关键任务之间的资源安全消耗。

为了测试每个实现的机制，开发了一个代码，该代码在执行时简单地创建巨大的CPU负载并消耗所有可用内存，模拟旨在占有可用资源的非安全关键任务。然而，在执行这些任务之前，每次系统启动时都需要从文件系统挂载受控的CPU子集。因此，准备了以下设置，以便在系统启动时准备好带有创建的组的子集。

5.3.1 控制组的设置

在创建组并向其分配任务之前，每个CPU子集必须首先安装到根文件系统，组附加到该根文件系统以形成层次结构树。

开发以下代码是为了执行CPU和内存子集的安装，之后可以创建和附加组。

准备好CPU和内存子集的挂载后，将创建两组并将其附加到CPU子集，其中一组是通过将cpu.shares值设置为100来仅允许10% CPU时间的受限组。创建代表特权组，称为无限制组，在需要时通过将其cpu.shares值设置为1024（100% cpu.shares的默认值）来授予100%的CPU时间。cpu.shares的值指定不同组之间CPU时间的相对份额，其中与cpu.shares值设置为100的有限组中的任务相比，cpu.share值设置为1024的无限组中的一个任务将获得10倍的cpu时间余量。

CPU子集根据CPU参数的分配值和操作系统支持的调度机制，来调度CPU对Cgroup中任务的访问。CPU子集允许配置两个调度程序：完全公平调度程序(CFS)和实时调度程序(RT)。CFS是比例份额调度程序，它根据每个组分配的份额值在每个组的任务之间按比例分配CPU时间。另一方面，实时调度程序提供了一种指定实时任务可以消耗的CPU时间量的方法。但是，由于Yocto项目提供的MinnowBoard功能及其支持包，生成的图像不支持实时调度程序。

因此，由于CFS的性质，cpu.share属性的配置不会导致准确的cpu时间限制，其中即使一个组被允许仅使用10%的cpu时间，但存在空闲的未使用cpu（空闲）时间，受限制的组仍然可以借用该cpu空闲时间。这是因为CFS只通过其属性cpu.share来限制比例使用。此外，cpu时间的份额分布在多核系统上的所有cpu核心上，即使一个C组在多核上被限制为cpu的100%以下，它也可以使用每个单独cpu核心的100%。因此，为了避免这种情况并验证该机制，实现的重点是创建尽可能多的任务，以避免任何CPU空闲时间。这一点在后续连载的评估一章中有更详细的阐述，讨论一章中介绍了这种实施的进一步限制。

在同样的基础上，在名为limited memory的内存子集中创建了一个组，通过将memory.limit_in_bytes的值设置为53886080字节，分配给该组的所有任务都将被限制为仅允许使用大约50 MB的内存。因此，可以控制特定cgroup的内存使用，以免影响对系统安全具有更高关键性的其他任务的内存使用。

然而，重要的是，每次启动系统时都要准备好此设置，以便预先配置组，以便在启动时可以直接将任务分配给相应的C组。因此，之前的脚本已经包含在/etc/cgconfig.d中，以便在系统启动时执行该脚本。

5.3.2 CPU时间

创建组并将其安装到各自的子集后，目标是开发一种可以根据用户输入动态执行分组和任务分配的代码。想法很简单，程序首先询问要创建的任务数量；注意到创建的任务越多，任务之间建立的并发就越多，争夺可用资源。虽然这仅用于演示，但它仍然有助于实现分组机制的有效性，以保护演示应用程序任务免受可能危及资源可用性的其他任务的影响。创建的任务只是在CPU上产生非常高的负载，试图通过命令“yes > /dev/null &”消耗所有可用的CPU计算时间。这些任务只是为了给CPU带来最大的压力，没有特定的功能，因此被命名为虚拟任务。创建虚拟任务时，它会利用单核100%的CPU计算时间。因此，目的是创建更多任务以建立更多并发，并避免CPU任何可能的空闲时间，从而更好地评估所实现的机制。如以下示例所示（如下图20所示），创建了三个组，cpu.shares设置为100、512和1024，每个组包含多个虚拟任务。最受限制的组（包含4个任务）只能使用10%的CPU时间，而cpu.shares设置为1024的特权组则被授予几乎100%的可用CPU时间；即使所有任务执行相同的任务。

图20：根据cpu.shares对任务进行分组

在此基础上，开发了附录A中的代码：CPU时间限制代码，并通过图21中的数据流图进行了演示。该程序首先询问要创建的N个虚拟任务，然后询问是否应该创建它们。分配到有限组或不分组而继续运行。如果要实现Cgroup，则程序会获取演示系统PID，并将演示系统任务分配给无限组，从而授予应用程序所有所需的CPU时间。同时，创建的N个虚拟任务被分配给使用其PID的有限组，并且只允许消耗10%的CPU时间。如果不进行分组，则创建N个虚拟任务，并将其与消耗所有可用资源的演示应用程序一起运行。在这两种情况下，用户都会收到当前执行场景的通知，这允许根据用户输入动态测试和验证已实现的分组机制。

图21：CPU时间限制机制的数据流程图

后续连载（五）将回顾所实施机制的结果和评估，其中通过显示CPU时间利用率来仔细检查自适应平台演示系统任务。此外，还进行了进一步的评估，以检查所实施的分组机制对自适应平台演示系统应用程序的正确执行时间的影响。

5.3.3 内存使用

内存控制程序与CPU时间没有区别，在程序开始时，用户会被询问非关键任务的创建，这也只是为了模拟使用影响安全关键应用程序的所有可用内存的愿望。

与强调CPU负载的dummy-task类似，eat-memory任务通过eat-memory函数分配大部分可用内存。这只需评估一个巨大数组的值即可完成，该数组的索引随着for循环的迭代而增加，从而在两分钟内分配约550MB。同样，这里的目的是评估限制模拟非特权任务使用的内存量的实现机制。附录B：内存使用限制代码包含实现的代码。

图22中的数据流图显示了实现的代码，其中要求用户执行eat内存任务，以及是否应将其分配给有限的内存组。因此，eat-memory.sh会根据用户输入使用正确的属性进行调用。如果要实现分组机制，则程序将eat内存脚本分配限制为仅50MB。如果用户没有实现分组机制，演示系统应用程序将面临无法分配所需内存的风险。此外，该程序能够使用memory.usage_in_bytes属性显示当前定位的内存量，这允许对所实现的机制进行评估和测试。这已被用作通知方法，以通知用户已达到配置的限制。

此外，memory.max_usage_in_bytes可以为开发人员提供进一步的监控功能，显示所有任务达到的最大内存使用量的记录。尽管，这还没有在实现中使用——由于演示系统应用程序不使用大量内存，因此它被认为在交换更多数据的应用程序中非常有用。