面向功能安全应用的汽车开源操作系统解决方案

在SAE 2024国际汽车安全大会上，Elektrobit的Linux专家王红燕在操作系统与芯片技术的分论坛上为大家带来了“面向功能安全应用的汽车开源操作系统解决方案”主题演讲。

为了便于大家能够有进一步了解，我们将此次演讲内容进行了提炼整理，内容如下：

挑战与汽车行业需求

首先来了解下汽车行业和开源软件的现状，我们一般来说是不会频繁地去申请软件的版本，申请时主要是修复有bug的部分。那开源软件的现状是什么？

第一个产品生命周期非常短，如果大家关注过Linux Kernel的开源社区就会发现基本上两周、三周就会有一个完整的更新。

第二个是它的好处，就是创新非常快，基本上最新的一些技术都会体现在Linux操作系统上。

第三个是Linux的漏洞是通过不断的升级版本来进行更新的。比如说在6.1上发现了一个bug，那一般是不会在6.1上修复的，通常会修复到6.2或者更高的版本上去，这样子其实不符合我们汽车行业的要求。

我们再来看下汽车行业的要求，为什么去选Linux，其实原因有很多。

第一个就是它的功能众多而且非常强大，刚刚可以看到Linux提供了很多安全的手段。

第二个是开发人员就是比较易招，基本上学计算机或者是一些息息相关的专业，Linux都是必修的。

还有一个最大的优势，是无厂商锁定，它是不绑定license的，不属于任何一个公司，所以我们不会因为因为某些原因导致被某些公司锁定而得不到软件。

还有一个创新快，这是开源软件最大的一个优点，因为全球有数亿开发者在贡献Linux开源社区。

最后一个是广泛的硬件支持和源代码透明易于调试，这个大家应该都比较清楚。

合规性挑战

第一个组建非常复杂且集成比较麻烦，因为现在特别是在A核上面的应用会越来越多，那我们APP的供应商也会越来越多，对我们Tier 1或者是OEM去集成这些APP的时候，当所有的APP都集成到一个Linux操作系统上，定位问题就会非常麻烦。

第二个就是需要适应一些新的标准，不管是新的欧盟，包括美国以及我们国家的一些安全标准也很快都会出来。

第三个就是功能安全，Linux拥有比如开源、没有厂商锁定这些好处，但是它缺了一点，就是我们汽车某些域它有一些功能安全的要求。

第四点就是开发方法非常多，这个是我们从开源社区截的两张图，左边这张图就是我们关注Linux安全的可能经常会查阅的一个网站，就是NVD。在这个NVD的网站上，它会列出来全世界各地发现的Linux的bug，然后这个就可以看到，bug其实是随着时间的增长开始一个直线型的增长。然后右边这张图是Linux开源社区的更新，大家可以看到更新的非常频繁。

弥合差距

那Elektrobit是怎么做的呢? 首先第一个针对我们有很多个APP供应商这样的一个问题，就是集成面的问题，我们引入了一个容器的概念，Elektrobit的Linux它是一个基于容器的操作系统，那么这个容器带来的好处有以下几点：

首先，它会给APP创造这么一个隔离的环境，把APP和整个系统然后隔离开，第二个就是安全上面的使用，比如说它会在各个层面上去做严格的一个定义，RAM, CPU, disk, network，包括刚刚我们上一个演讲者所提到的比如说compatibility，还有一些dm-verity这些，然后在这个Container里面配置的时候，它的DAC，包括你的UID、GID这些都要配好，然后你的compatibility，Cgroup, Namespace这些都要配置上去，所以说它是一个对APP安全性提高非常大的一个特性（feature）。

然后第二个就是对于集成带来的好处，因为它会把比如说每一个APP的供应商它可能用到的库的版本，其实我们今天是用同一个库，但是大家版本不一样，如果集成的时候，我们熟悉Linux的可能都知道，我们一般像二进制应用都会放到/usr/bin下面，库放到/usr/bin下面，如果有很多个APP，大家用到的版本都不一样，这样子的话，你就在这个库下面有很多个版本，所以如果我们每一个APP供应商，大家都把自己所需要的配置文件都打包在一个Linux的一个Container镜像当中，那我们最终集成调试地也会比较方便，因为谁的容器没有启起来，那就是谁的问题。

这个容器的方案，其实我们在市场上应该也会看到很多，比如说像OCI，Podman, Docker，我想应该有很多已经尝试过不同的方案了，那Docker, Podman的问题就是太大了，那我们汽车的硬件，比如EMS、包括内存都是有限的，而且成本比较高，Elektrobit的Container，是一个轻量级的解决方案。

还有一个问题就是，刚才我们有一个Temper proof，就是防窜改。防窜改我们就引入了dm-verity这个feature，所以在每一次你启动Container这个镜像(image)的时候，我们都会去做integrity check，大家不用担心说Container的image被第三方进行篡改，这是Elektrobit的一个Container。

另外，因为Container其实就是一个image，所以它可以非常方便地去做到SOTA，而不是说每次升级的时候，我要整个系统去进行升级。

最后一点就是Elektrobit的Container是跟我们业内通用的OCI标准是兼容的，那我们Container是怎么放的呢？就是你相同的一些应用，比如说你功能相近，还有一些比如说交互非常频繁的应用，我们都建议放在一个容器内部，因为一个容器可以放一个APP，也可以放多个APP。又比如像我们经常使用中间件，Adaptive AUTOSAR, 一般来说Elektrobit提供的集成方案——就是我们的Adaptive AUTOSAR是一个容器镜像，然后给客户的时候就是一个镜像给到客户，然后客户放上去就运行起来，没有任何集成的代价，这对于Tier 1或者OEM来说就会非常方便。

尤其Container的接口，我觉得是Linux做得比较好的，它的向后兼容性都做得非常好。

刚刚我们也说了，Linux开源设计上，它的更新非常频繁，对于我们汽车操作系统来说，特别量产之后，我们是不大可能频繁的去升级我们的Kernel版本的，那对于Elektrobit的维护方案是怎样的呢，就是每两年，我们会选取一个Kernel版本，每一个Kernel版本我们会维护10年到15年（包括产品和安全）这样的一个维护周期。

比如我们Elektrobit第一款量产的Linux操作系统是在大众ID.系列上面，当时的那个Kernel版本还是4.19，我们现在还在维护。现在当下的话，我们的Kernel版本已经到5.15，它是一个固定版本的一个Kernel版本维护。

为构建下一代汽车操作系统，我们联合了一个强有力的合作伙伴，就是Canonical，双方共同推出了基于Ubuntu的EB corbos Linux开源解决方案。Elektrobit的EB corbos Linux是一个单独的发行包，我们的一些Kernel部分就是由我们的合作伙伴Canonical进行维护， Elektrobit作为一个专业的汽车软件公司，我们的关注点就是在功能安全(Functional Safety)上面，所以我们提供的面向功能安全应用的EB corbos Linux for Safety Applications解决方案，目前是达到ASIL-B的，该解决方案弥补了开源操作系统对于功能安全的一个需求。

然后是关于信息安全（Security）的一些标准，我们的解决方案可以满足主流的信息安全法律法规，包括：14028，ISO/SAE 21434，还有欧盟的UNR 155，VDA, 这些我们都可以满足，包括我们已经量产的产品里面，比如说像刚刚介绍的Container的一项compatibility，Cgroup，Namespace，dm-verity，以及我们在三层、四层的iptables, netfilter这些都是EB corbos Linux for Safety Applications满足这些安全都必须的组件。

工作原理

刚刚我们也说了Elektrobit的EB corbos Linux for Safety Applications目前可以做到功能安全等级到ASIL-B，那我们的功能安全概念是怎样的？

这是我们EB corbos Linux for Safety Applications的Safety Concept，底层是有一个EB corbos Hyperviser，这是Elektrobit的一个虚拟化解决方案，它是有ASIL-B/D等级的，上面是一个EB corbos Linux for Safety Applications的Kernel（看右边部分），左边部分是带Container的QM Linux，右边的话是我们Safety的一个partition（分区），在上面是我们的Safety的一个中间件，然后再上面是Safety的APP，在Hyperviser和Kernel之间有一层隔离，这一层隔离所有的读、写、执行、包括一些访问，通通都是被MMU和Hyperviser来进行监控和控制，在我们的操作系统和APP之间也是有它的所有的读、写、操作、访问控制，都是由我们的safety monitor这个模块，这个safety monitor不是一个物理的模块，它是一个逻辑上的模块，就是有统称的这个safety monitor以及我们的MMU和Exception Level（EL, 异常级别）来控制，然后Safety和APP之间也是有MMU来进行保护的，这样子的话就是中间还有个Safety的中间件。

对AUTOSAR CP里面Safety架构比较清楚的同仁知道，在Safety里面我们除了有Safety OS, 还有一些Safety模块，例如Safety E2E, Safety RTE等，那对于我们A核同样也是一个系统级别的Safety方案，我们除了有一个Hyperviser加EB corbos Linux for Safety Applications这样的一个满足功能安全的OS之外，我们同时还需要有一个Safety的中间件来整个达成我们A核这边对功能安全的需求。

接下来就是我们基于Arm的三层对于Exception Level的一个处理，我们Safe Application需要用Supervisor Core，Supervisor Core中间这一些的调用的话，它所有的读、写、访问控制、执行权限都由Safety monitor和MMU来进行控制, EL1和EL2，Hyperviser Core这一层的话由Safety monitor和MMU来控制和监控。整个Exception Level这个Kernel的部分，因为我们如果把一个Kernel几件事情裁到最小的话，理论上也是可行的，就是你把一个Kernel去做到Safety，但是经济上它是不可行的，因为Linux Kernel更新太快了，你可能一个Kernel做到Safety，然而也许它已经更新到很多版本了。所以我们的方案是一个系统化的解决方案，就是Hyperviser是一个带ASIL的模块，我们OS safety monitor也是一个带ASIL的模块，包括上层的Safety application，也是一个带ASIL的模块，这三个模块和我们中间QM的Kernel之间都是做到了一个隔离和监控，这样子的话，整个来达到一个Safety。

路线图

最后看一下我们的路线图，第一就是关于Safety Concept这一部分，我们已经拿到了TUV的技术凭资的认证，首先我们的Safety Concept是没有问题的。

第二就是关于如何通过技术手段，来实现这些Safety Concept，这一部分我们也已经通过了认证，我们在今年的CES展上展示过demo，包括今年我们在北京车展上也已经全球首发发布了这款产品和解决方案。

第三，我们目前计划是在2025年可以实现结合客户的具体项目，具体应用需求，比如说ADAS，或者是需要功能安全的项目，来实现整个系统、项目的ASIL-B的量产。