Armv8-R Cortex-R52+软件集成的最佳实践

汽车安全 7个月前 admin

49 0 0

点击上方蓝字谈思实验室

获取更多汽车网络安全资讯

‍‍‍‍‍

Armv8-R Cortex-R52+软件集成的最佳实践

汽车电气/电子（E/E）架构正在向计算资源的集中方向发展。这最初发生在域控制器中，然后转向区域和集中式方法。随着多个实时功能被合并为区域控制器，对处理器性能的需求就会提高，操作系统和软件的复杂性也会增加。该行业正越来越多地转向基于Armv8-R的解决方案，如Cortex-R52和Cortex-R52+cpu（在论文中总结为Cortex-R52+），以实现这种软件集成的愿景。一些汽车芯片制造商已经将这些处理器纳入到区域平台和安全岛的高性能微控制器设计中。与此同时，汽车软件供应商已经建立了与Armv8-R集成的解决方案，在这个处理器家族中使用的Arm架构。这篇文章总结了这一行业趋势的最先进的概述。

新系统的硬件和软件必须同时满足设备上承载的每个单独工作负载的要求。这些内容包括：

—满足工作负载的软件依赖性，包括库、操作系统调用（包括对输入/输出的访问）和应用程序二进制接口（ABI）。可能需要这些版本的特定版本。当单个操作系统不能同时满足所有依赖项时，系统软件可以包括多个操作系统。

—性能，包括实时工作负载所需的决定论，可能有不同的硬实时响应时间要求，从几微秒以上。如果未能满足困难的实时需求，将导致工作负载的操作不正确。有些工作负载可能有更精简的实时需求，因为无法满足这些需求会导致性能下降。其他工作负载没有专门的实时需求，因此这些软件制品是在最好的基础上执行的。

—对于功能安全的工作负载，满足工作负载对正确执行环境的假设以及提供任何假定的外部安全机制是最基本的。执行环境和安全机制的汽车安全完整性级别（ASIL）必须高于或高于分配给工作量的级别。

—对于安全性相关性较低的工作负载，最好不仅仅因为设备上存在其他更高的ASIL工作负载而增加工作负载的ASIL

—通过确保其他工作负载无法访问敏感数据，满足安全要求，如机密性、完整性、隐私性和真实性

—能够更新单个工作负载，包括无线固件（FOTA）。这还包括一系列其他主题，如工作负载的身份验证、安全引导和系统级更新。管理程序的FOTA是一个大话题，在本白皮书中也不能讨论。

—对于从已有的（遗留）应用程序派生的工作负载，理想的选择是以最小的适应性集成工作负载。在集成为独立系统硬件设计的工作负载时，软件必须防止任何具有影响系统中其他应用程序的副作用的行为。—对于与规范应用程序相关的工作负载，可能需要获得认证（例如，在与车载诊断（OBD）相关的应用程序中）。为了避免在每次其他工作负载更改时都需要重新认证，必须证明其他工作负载不会干扰已认证的工作负载。

通过承载多个工作负载，系统硬件和软件必须在工作负载之间提供适当的隔离，以确保一个工作负载不会导致另一个工作负载无法满足其要求。如果需要多个操作系统，则每个操作系统之间都存在类似的隔离要求。为了功能安全，这种类型的隔离被称为免干扰（FFI），它需要一种机制来确保与一个工作负载相关的故障不会导致提供给另一个工作负载的执行环境和系统安全机制的故障。在工作负载之间提供这种级别的隔离的系统还带来了一个优势，即允许与其他工作负载隔离地开发（和调试）每个工作负载。如果工作负载来自不同的供应商，那么这一点尤其重要。

系统硬件和软件提供了以下隔离机制：

—逻辑隔离。使用特权模型和内存保护机制隔离属于不同工作负载的状态。

—定时隔离。调度私有资源和共享资源，分区和监视共享资源，以及管理监视器计时器以检测计时违规。

Cortex-R

ARM有一个CPU处理器组合，设计用于解决广泛的计算，从最小，最低功率的微控制器到超高性能的服务器类计算。Cortex-R处理器已经开发使应用程序需要实时处理和适用于一系列不同的用例，尤其是在汽车应用程序，系统必须响应短和确定的时间框架成功地满足系统的要求。在许多情况下，这些应用程序还包括功能安全（和安全性）需求，这些需求增加了系统集成商和开发人员所面临的挑战。Cortex-R处理器，如Cortex-R52+，可以用于独立的微控制器（mcu），也可以作为SoC（芯片系统）设计的额外核心，例如作为一个安全岛。

第一个Cortex-R处理器，如Cortex-R5，是建立在Armv7-R架构上的。然而，从那时起，架构已经发展，Arm的Cortex-R52和Cortex-R52+处理器实现了Armv8-R架构，这有助于解决汽车实时软件日益复杂的问题，以及从离散专用控制器到功能集中和组合的控制器的过渡。Armv8-R体系结构增加了支持，使其能够在单个处理器中更好地控制软件，提供代码的隔离，并支持可重复和可理解的行为，包括在实时处理器中的虚拟化。

Cortex-R52和Cortex-R52+处理器是高度可配置的，可以被定义以满足实现者的应用程序要求。表1描述了一些可配置性。

Armv8-R Cortex-R52+软件集成的最佳实践

作为Armv8-R体系结构的一部分，这些处理器为用户空间异常级别0（EL0）和操作系统空间异常级别1（EL1）提供了额外的异常级别。这个新的异常级别2（EL2）可以用于帮助管理管理程序/分离内核来帮助管理处理器上的软件，这简化了合作伙伴如何控制软件对共享资源及其交互的访问。这可用于维护在同一操作系统上运行的单个处理器上或跨多个操作系统上的任务之间的隔离。

与新的异常级别一起，还增加了一个两阶段内存保护单元（MPU），它能够强制执行处理器对不同资源的访问。操作系统能够在EL1上控制MPU的资源，但是处理器可以实现添加MPU的第二阶段，这只能从EL2进行配置，管理程序可以从EL2运行。

对资源的访问可以通过运行在新的更高异常级别2上的软件进行管理。应用程序任务可以通过该软件请求访问所需的资源，这将强制使用两级内存保护单元（MPU）进行访问。这种方法并不局限于两个不同的临界级别，而且还可以支持许多具有不同保护功能的不同上下文。与内存管理单元（MMU）不同的是，MPU的可用性可以提供从Cortex-R处理器到系统资源的访问管理，而无需引入额外的、潜在的调度中断、延迟搜索时间和从内存中加载页面表。这些项目很难管理，也难以评估和保证其及时完成。

Armv8-R Cortex-R52+软件集成的最佳实践

MPU的两个级别是：

—EL1MPU，它由操作系统管理，以强制操作系统与应用任务/isr分离，以及应用任务/isr彼此分离。EL1 MPU可以通过运行在EL2或EL1处的代码进行编程。

—EL2 MPU，它只能通过运行在EL2上的代码进行编程，并由一个系统管理程序用来提供额外的分离。

Cortex-R52+提供了核心之外的信息，以使系统能够基于正在运行的软件来建立和维护对访问的控制。这是通过为设备事务传播虚拟机ID（VMID）来实现的，以使系统能够管理对这些资源的访问。在Cortex-R52+的情况下，这通过支持缓冲区和内存事务和请求得到进一步扩展，这些事务和请求直接由EL2上的管理程序生成。

这些Cortex-R处理器集成了自己的通用中断控制器（GIC），集群内所有cpu共享，以从系统提供低延迟中断。这可以灵活地将共享外设中断（SPI）分配和优先级分配给集群中的任何核心。GIC支持同时对物理中断和虚拟中断发出信号的能力，并可以捕获对EL2的中断访问，以虚拟化中断。

这些处理器具有紧密耦合的存储器，以实现高度确定性、低延迟的核心访问代码和数据。它们有多个到外部资源的接口，包括SRAM、主内存和设备。接口访问的资源是根据其地址位置进行分配的，实现者能够灵活地分配他们所使用的内存映射中的空间，并管理要私人分配给虚拟机的资源的分配。

软件集成机制

虚拟化和虚拟机

随着车辆中软件数量的增加，越来越多的应用程序被集成到一个微控制器上。这可以看到特别在域/区域控制器提供之间的桥梁非常强大的中央车辆计算机。

使用Cortex-R52+的管理程序和虚拟机微控制器可以支持集成应用程序与必要的分离的系统。每个应用程序都在其自己独立的实例中运行——通常称为分区或虚拟机（VM）

虚拟机通常由以下部分组成：

一些物理或虚拟处理器核心

—一些内存

—一些物理或虚拟外设

—一些物理或虚拟配置寄存器

管理虚拟机的软件通常称为系统监控程序、分离内核或VM管理器，在Cortex-R处理器上，在异常级别2（EL2）特权级别运行。在或多或少的程度上，系统监控程序会给在虚拟机内部运行的客户软件产生一种错觉，即它运行在自己的微控制器上，而不会与其他虚拟机中的其他客户软件共享微控制器设备。一个物理处理器核心可以通过在虚拟核心之间进行上下文切换来托管多个虚拟核心，就像操作系统的上下文在进程之间进行切换一样。虚拟核心的上下文是通用寄存器、浮点寄存器、一些系统配置寄存器和EL1 MPU的配置的值。在遗留软件运行在VM内部的地方，我们希望虚拟机看起来尽可能地像一个真正的微控制器，以避免需要更改遗留软件，而不是通过重新链接，以便在每个VM中运行的客户软件使用单独的内存。

使用SMPU和外围保护机制

SMPU的主要作用是控制哪些总线管理器（例如DMA控制器）可以访问哪些内存地址。Cortex-R处理器核心和其他微控制器组件，如Cortex-M内核和一些外设，可以作为总线管理器。通常，一个SMPU将有一个区域的集合。每个区域都有一个可配置的起始地址、一个大小，并被分配给一个或多个总线管理器(或在更高级的设计中，使用存储在Cortex-R52+的VSCTLR中的虚拟机标识符分配给一个或多个虚拟机。VMID寄存器)。总线管理器（或VM)只能访问分配给它的区域中的内存。微控制器还可以包括外围设保护机制，以允许将外围设分配给总线管理器（或vm）。在这里，一个外设被分配给一个或多个总线管理器（或VM），然后外设保护机制禁止任何其他总线管理器（或VM）访问外设的寄存器。

通过使用smpu和外围设备保护机制，我们可以实现集群级的分离。也就是说，一个微控制器的内存和外设，可以在多个虚拟机之间进行分区，其中一个虚拟机包含一个Cortex-R核心集群中的所有核心。如果虚拟机有不同的安全级别（例如，不同的ISO 26262 ASIL级别），那么仅仅依赖上述机制将不允许我们在同一集群中拥有多个虚拟机。每个集群都有一个通用中断控制器（GIC），用于将中断路由到集群中的核心。每个核心都有一个单独的GIC重新分配器来处理软件生成的中断（SGI）和私有外围中断（PPI），但是用于处理SPI中断的GIC分配器对集群中的所有核心都是通用的。如果我们允许同一Cortex-R52核心集群中的多个虚拟机写入内存映射的GIC分发器寄存器，一个VM可能会通过（意外或恶意地）改变其他虚拟机的中断配置来干扰另一个虚拟机。

Armv8-R Cortex-R52+软件集成的最佳实践

使用EL2进行Para-virtualization

除了像smpu这样的保护机制和由微控制器提供的外围保护外，Cortex-R52+本身还包括支持虚拟化的功能。其中一个特性是EL2特权级别。EL2比操作系统使用的EL1（监视器）级别和应用程序代码使用的EL0（用户）级别更有特权。一个虚拟机管理程序在EL2上运行，并且代码在客户软件VM中运行，在EL1或EL0上运行。

HVC（EL1调用）指令可以使用HVC向管理程序发出请求，就像应用软件可以使用SVC（HVC调用）指令向操作系统发出请求一样。当运行在EL1上的软件执行一个HVC指令时，Cortex-R52+核心会切换到EL2，并接受一个超模式的输入异常。管理程序处理此异常，然后返回到EL1上的guest os.HVC指令允许对虚拟化。guest os知道它在虚拟机中运行，并且管理程序提供了API(使用HVC指令），guest os用来请求管理程序、插入到管理程序的设备驱动程序（EL2设备驱动程序），或请求在其他虚拟机中运行的设备驱动程序。

Armv8-R Cortex-R52+软件集成的最佳实践

作为一个例子，考虑如何使用对虚拟化允许多个虚拟机存在于同一集群中，尽管共享GIC分发程序。SMPU（或核心MPU）被配置为使虚拟机无法访问GIC的内存映射寄存器。当来宾软件想要更改其中断配置时，它会向管理程序发出API请求。管理程序在首先检查了所请求的更改是否不会干扰其他VM后，执行必要的GIC配置。对虚拟化还可以用于允许外设共享和创建虚拟外设。外设备，如以太网控制器，可以以与GIC相同的方式共享。还可以创建完全虚拟的外设。例如，可以创建一个虚拟以太网控制器，用于运行在同一微控制器上的虚拟机之间的通信。在这两种情况下，管理程序都将包含一个EL2设备驱动程序，该驱动程序要么管理了对共享外设的访问，要么实现了虚拟外设。这类似于操作系统使用设备驱动程序来管理对由多个进程或任务共享的外设的访问的方式。对虚拟化可以用作不支持或不完全支持硬件虚拟化的外设的解决方案。理想情况下，外围设备将支持“实时系统的设备虚拟化原则”中所描述的虚拟化，以避免对准虚拟化的需要——至少在数据平面上是这样。与设备传递（外围设直接由客户软件驱动）相比，对虚拟化（以及陷阱和模拟）总是会添加一些额外的周期。

中断虚拟化

中断虚拟化EL2单独不允许我们共享或虚拟化中断驱动的外设。Armv8-R体系结构定义了通常当发生中断时，它会中断当前特权级别的当前运行的代码。例如，如果代码在EL1运行时发生IRQ，则中断将使用EL1向量表中的IRQ条目在EL1处进行，但如果代码在EL2运行时发生IRQ，则中断将在EL2向量表中的IRQ条目在EL2处进行。为了解决这个问题，Cortex-R52+支持中断虚拟化。当中断虚拟化启用（通过设置HCR寄存器的IMO和FMO标志和设置ICH_HCR寄存器），FIQ或IRQ中断（例外）总是导致Cortex-R52+切换到EL2和使用EL2向量表FIQ或IRQ中断。然后，管理程序可以处理中断，或者使用Cortex-R52+核心的特性来虚拟化中断（通过使用列表寄存器），这样当来宾软件在EL1/EL0处运行时，它使用EL1向量表在EL1处接受虚拟中断。对于客户软件，虚拟中断是独立的。

Armv8-R Cortex-R52+软件集成的最佳实践

由于所有中断最初都由管理程序处理，管理程序可以决定中断应该由管理程序本身、由EL2设备驱动程序处理，还是应该虚拟化并注入VM。这允许处理中断驱动的共享/虚拟外设。如果需要，EL2设备驱动程序还可以向虚拟机中注入虚拟中断。中断虚拟化还允许“远程控制”虚拟机。例如，运行在一个物理核心上的特权管理VM或EL2设备驱动程序可以在第二个物理核心中生成中断，以请求管理程序在第二个核心上做一些事情，例如关闭或重新启动在第二个核心上运行的VM。

当然，没有什么是免费的，而且中断虚拟化增加了处理中断所需的总时间。确切的开销取决于许多因素，包括中断的到达模式和使用了多少个不同的GIC中断。与中断虚拟化相关的问题有两个时间问题：

1。在EL2处虚拟化中断的处理会消耗处理器时间。

2.由于虚拟中断的优先级独立于实际中断的优先级，客户软件可能会看到时间异常。

虚拟处理器核心

我们还可以利用中断虚拟化来支持虚拟处理器核心。例如，计时器中断可以由系统管理程序处理，并用于驱动虚拟核心调度器，该调度器决定何时在虚拟核心之间进行上下文切换。由于来宾软件无法阻止在EL2处发生的中断，因此损坏或恶意的来宾软件无法拒绝对其他来宾软件的处理器时间。当前未运行的虚拟核心的中断可以被虚拟化，在软件中排队，并在下次运行时注入虚拟核心中。在虚拟核之间的切换通常需要重新编程EL2 MPU。还必须注意协同处理器14和15配置寄存器（这些寄存器用于配置处理器的各个方面，如环境性，是否启用缓存以及是否启用EL1MPU）。其中一些寄存器对物理核心的影响可能会影响物理核心和虚拟机管理程序上的所有虚拟核心。其他寄存器的影响可能是特定于虚拟核心的，如EL1 MPU区域寄存器。后一类中的寄存器需要是虚拟寄存器的一部分

Armv8-R Cortex-R52+软件集成的最佳实践

如果多个虚拟核由单个物理核托管，那么必须考虑如何安排虚拟核。最简单的方法是使用静态TDMA（时分多址）算法。TDMA算法具有非常低的运行时开销，易于理解，并且容易计算虚拟核心何时在墙时钟时间内运行。纯静态算法的缺点是，在处理异步事件（例如，中断）时，它可能会导致较长时间的延迟。通过仔细构建静态VM调度，可以避免长时间的延迟，以确保在处理中断的VM运行之前不必等待太久。然而，这可能需要详细了解中断在最坏情况下的执行时间。系统处理具有短延迟的异步事件的另一种方法是使用动态调度算法。动态调度算法的一个例子是基于保留的调度，每个虚拟核心都是一个可延迟的服务器。这种算法已经在一些版本的ETAS RTA-HVR管理程序中使用过。这在处理异步时提供了更短的延迟。

使用虚拟处理器内核为系统设计者提供了灵活性：—可以创建一个虚拟机，它包含的内核比仅使用物理内核时可用的内核要多。额外的核心可能会使软件的结构化变得更容易——就像在操作系统中使用线程一样。—多个虚拟机可以由单个物理核心托管。然而，虚拟核之间的上下文切换有不少开销，因为管理程序需要保存一个虚拟核的通用寄存器、浮点寄存器、相关配置寄存器和EL1 MPU设置，然后为另一个虚拟核重新加载这些寄存器。虚拟核心上下文开关类似于操作系统中的进程上下文开关。使用虚拟核心会影响中断延迟。使用静态调度算法，到达当前未运行的虚拟核心的中断在虚拟核心下次运行之前不会被处理。通过一个自动切换到处理中断的虚拟核心的动态调度算法，虚拟核心上下文切换时间将被添加到中断延迟中。系统设计人员需要评估哪些应用程序。

软件集成的建议

决定是否需要管理程序类型的分离还是os级分离更好？

上面描述的机制允许一个管理程序创建一种认为客户软件有自己的微控制器的错觉，并强制执行运行客户软件的虚拟机之间的分离。如果要集成的应用程序是紧密耦合的（紧密耦合意味着应用程序相互调用同步函数或依赖于由同一调度器调度的所有应用程序中的活动），那么使用操作系统容器的集成可能更合适。AUTOSAR操作系统允许将任务和isr分组到被称为“操作系统应用程序”的容器中，mpu可以用来分离这些不同的容器。操作系统级别的集成意味着使用一个调度器来调度所有任务，并且更好地支持紧密耦合的通信。像自动存储系统Flex-CP这样的新举措正在开发中，以支持更动态的应用程序集成到经典的自动存储系统系统中。

使用核心本地资源和集群-本地资源

最好使用内存和“接近”使用它们的核心的外设等资源。每个Cortex-R核心都有比其他类型的RAM更快地访问的tcm。通常微控制器有集群本地Flash和RAM，并且在某些情况下，外设（例如，CAN和LIN控制器）可以被分配给一个集群。除了使用通常更快之外，使用集群本地资源通常会导致更少的内存总线争用，因为访问集群本地资源的核心可能不必与其他集群中的核心竞争访问内存总线。请注意，使用接近核心的资源可能会在运行时限制物理处理器内核之间的虚拟处理器内核的任何迁移（如果支持这样做的话）。例如，如果一个虚拟核心连接到本地flex-r核心集群0，如果迁移到集群1，虚拟核心的运行速度会更慢

考虑中断延迟和实时需求

下表总结了适用于具有不同中断延迟和实时需求的应用程序的技术摘要。

Armv8-R Cortex-R52+软件集成的最佳实践

对未来微控制器的建议

为虚拟机提供细粒度的外设分配

如果外围设可以以细粒度分配给虚拟机，那么就可以减少对EL2设备驱动程序的需求。例如，能够将单个控制器区域网络（CAN）通道，甚至单个通用输入/输出（GPIO）引脚分配给虚拟机是很有用的。这减少了对准虚拟化或陷阱和模拟的需求，从而提高了性能。虽然完全的外围设备虚拟化是理想的（见下文），但一个折衷方案是使用对虚拟化/陷阱和模拟来执行外设的初始化和配置，但允许直接访问数据平面。

支持外设的虚拟化

甚至比细粒度的虚拟机分配更好的是外设的完全虚拟化。在这里，一个外设将由一个管理程序配置，以向多个虚拟机呈现一个单独的“视图”。然后，每个虚拟机都可以使用外围设备，就好像它已经被分配了一个外围设备的唯一实例一样。

确保DMA是虚拟化意识的

当VM使用DMA传输或使用DMA传输的外设时，DMA传输不能允许VM从SMPU或核心MPU通常禁止的内存地址读写。理想的情况是，DMA模块/通道将自动继承配置DMA模块/通道的VM的标识，或配置使用DMA模块/通道的外设的VM的标识。然后，DMA传输上的SMPU将至少检查VM标识符，如果VM无权读取或写DMA传输中涉及的内存，则DMA传输将被阻止。为了支持这种行为，Armv8-R VMID应该分发给外设和DMA控制器。如果不可能自动继承虚拟机身份，那么应该可以通过特权软件实体以编程方式将DMA模块/标识符分配给虚拟机，以便可以完成对DMA传输的SMPU控制。当单个物理核心可能运行多个VM时，由VM控制DMA，而不仅仅是总线管理器，则很重要。

采用可用的虚拟化标准来简化软件的可移动性

对于通常用于运行经典autosar系统的微控制器来说，虚拟化是一个相对较新的话题，自然地，微控制器制造商正在添加一些功能，以使他们自己相对于竞争对手具有优势。然而，这些微控制器的用户希望开发软件，如果有必要，他们可以将软件转移到不同的微控制器上。因此，微控制器和系统管理程序的结合需要为微控制器的用户提供一套相当标准的特性和特性使用方法。为此目的，在有行业标准的地方，就应该采用这些标准。在Armv8-R架构方面已经做了一些工作，在Arm的“实时系统的设备虚拟化原则”的论文中可以找到一个很好的例子。

总结

电子电子架构的发展，包括区域控制器，需要进一步的实时软件集成解决方案。经典的自动存储器是汽车实时软件世界中事实上的一个标准，但进一步的集成选项，如遗留软件，是必须向前推进的。带有EL2分离选项的Armv8-R体系结构是启用智能集成选项的一个很好的选项。不过，如何使用此集成选项高度依赖于应用程序，而专用的应用程序需求将定义哪种集成方式最适合。本文介绍了各种不同的技术，可用于支持不同类型的应用程序的集成。这将有助于系统设计师理解如何最好地使用Cortex-R52+内核来支持应用程序集成。

来源：功能安全开发