开放算力·云启未来.pdf

封面页（此页面将由下图全覆盖，此为编辑稿中的示意，将在终稿 PDF 版中做更新）卷首语 我们相信操作系统将成为数字产业支柱算力来源，龙蜥社区是近两年业界发展最为强劲的一大操作系统开源社区，因为做对了这两件事：一、“开放算力”，龙蜥社区短期目标是开发龙蜥操作系统作为 CentOS 替代，助力广大用户无缝迁移。基于阿里云、统信软件等社区多年来的技术沉淀，面向广大用户进一步释放底层算力。二、“云启未来”，龙蜥社区的长期使命是与生态合作伙伴联手，共同打造一个面向云时代的操作系统，协同产业上下游能力和诉求，建立统一的开源操作系统生态。2022 年是龙蜥社区在产业落地的一年，为让大家看到龙蜥社区每一年扎扎实实的突破，我们在 2022 云栖大会上举办了阵容强大的龙蜥峰会。本次峰会在浙江省软件协会指导下，由龙蜥社区主办，阿里云、统信软件、Arm 等 21 家企业单位共同协办，围绕“开放算力 云启未来”的主题，打造了操作系统产业主论坛、eBPF&Linux 稳定性专场、RISC-V 专场、云原生专场共 4 个会场，聚焦社区演进、技术实践、生态发展和开发者培养四大维度，呈现一个繁荣的开源社区全貌。奋进谋发展，笃行创新业。截至目前，龙蜥操作系统下载量已经达到 230 万，装机量超过 300 万。龙蜥社区当前有 21 家理事单位和超 250 家生态合作伙伴，近50 个 SIG 组，上百位 Maintainer，上千名开发者。龙蜥社区在短时间内实现的跨越式发展，与社区坚持的平等、开放、协作、创新的准则息息相关。基于此，龙蜥将贯彻建设面向云时代的操作系统的长期使命，打造“集产业之大成”的下一代操作系统 Anolis OS 23。Anolis OS 23 是通过分层分类理论指导来打造的。操作系统如何在云场景下做好多样化支持的同时，还能向上给应用开发者一个一致性的体验，这是龙蜥操作系统未来 3-5 年奋斗的目标。在未来技术趋势方面，社区主要是围绕着下一代数据中心的技术趋势、下一代的云原生软件栈的需求、以及软硬协同的技术发展趋势展开。我们坚信，未来十年，操作系统的大发展一定势不可挡。欢迎所有有志于参与操作系统研发的同仁一起加入龙蜥社区，打造面向未来的下一代操作系统。目录 eBPF 技术&Linux 稳定性专场.6 SYSOM 在系统可靠性与安全上实践.6 手机内核稳定性的治理与实践.17 系统运维利器，百万服务器运维实战总结！一文了解最新版 SysAK.26 eBPF 技术发展及挑战.33 Coolbpf 的应用实践.41 eBPF 安全特性解析.49 基于 eBPF 的程序摄像头构想.54 eunomia-bpf eBPF 轻量级开发框架.61 RISC-V 专场.66 平头哥在 RISC-V 软件生态的探索和实践.67 开源高性能 RISC-V 处理器敏捷开发实践.74 RISC-V 边缘 AI 芯片的开源生态和应用落地.83 快速发展的 RISC-V 软件生态.92 蜥峰会 RISC-V 专场圆桌对话.102 云原生专场.108 龙蜥云原生社区发展思考&Kata Containers 社区共建.109 中国移动算力网络云原生虚拟化技术.113 基于 kata 的 Serverless 产品体系建设.118 基于龙蜥与 Koordinator 的在离线混部的实践.122 ContainerOS 在云原生中的应用.130 如何在云原生时代下管理微服务应用.136 Serverless Computing 技术架构.144 机密容器崛起和发展.152 龙蜥云原生社区未来展望.158 eBPF技术&Linux稳定性专场eBPF技术和Linux稳定性在龙蜥社区的实践 SYSOM 在系统可靠性与安全上实践 6 SYSOM 在系统可靠性与安全上实践 作者：魏东，统信软件高级系统研发工程师 1.系统可靠性 SRE 是判断系统是否可靠、可用、有效重要标准，它包括：服务水平指标 SLI：衡量服务使用情况量化指标。比如 IO 读写速率、网络延迟。通常量化指标会转换为比率、平均值或百分 比。服务水平目标 SLO：一段时间、区间内的目标。SLO 的表达式通常为：SLI=target 或 lowerboundSLIupper bound。比如 SLO 可以为每个请求的平均延迟rodata 变量。_load()：初始化，加载和校验 BPF 应用部分。Coolbpf 的应用实践 43 _attach()：附加所有可以自动附加的 BPF 程序。有事件和网络运行报文到达时，会触发运行 bpf 程序。_destroy()：分离所有的 BPF 程序并使用其使用的所有资源。eBPF 的主要开发方式有三种，各有优缺点。原生 Libbpf 无 CORE：该方式没有任何基于第三方的开源项目，而是直接调用Libbpf 里的代码，资源占用量低。但缺点为需要自己完全重新搭建工程，效率较低，且版本兼容性较差。BPF CORE：该方式不依赖在环境中部署 Clang/LLVM，资源占用少。但是需要搭建编译工程，部分代码相对固定，无法动态配置。BCC：该方式是应用最广的开源项目，开发效率较高。但是每一次运行都要执行 Clang/LLVM 编译，存在内存、CPU 等资源的争抢。目标环境依赖头文件，需要单独下载头文件。2.Coolbpf 的功能和架构 Coolbpf 提供了远程编译（云编译）。其中远程编译指运行程序的目标机器与编译程序不在同一个机器上，能够解决资源占用问题；提供了本地编译和基础库封装，方便用户的理解与适用；提供了低版本内核的支持；提供了 BTF 的自动生成和发布，用 户 无 需 手 动 适 配，下 载 即 可 直 接 使 用；提 供 了 自 动 化 测 试 以 及 支 持python/go/rust 等高级语言进行应用开发。Coolbpf 的应用实践 44 Coolbpf 天然支持 BPF 的 CORE 能力，它解决了编译和资源消耗的问题，同时，前面介绍的复杂的 libbpf 开发步骤完全被简化了。用户只需要专注自己的功能开发，不用关注环境搭建和冗余代码开发。Coolbpf 提供了标准化的 bbf 编译服务。将 bpf.c 提交到远程编译服务器时，会根据的内核版本针对不同的语言返回点 bpf.so 或 bpf.o 为高级的应用程序提供服务。因此高级语言中，只需加载 bpf.so 即可运行程序，无需再手动触发 Libbpf 的加载、open、attach 等函数，而是由高级语言程序的 initial 操作自动完成，可以快速搭建和部署工程，用户只需专注于数据输出之后的处理。Coolbpf 的应用实践 45 Coolbpf 提供了标准化的 bpf 编译服务。首先将 bpf.c 提交到远程编译服务器时，服务器会根据的内核版本针对不同的语言返回点bpf.so或bpf.o为高级的应用程序提供服务。因此在你的高级语言代码中，只需加载 bpf.so 即可运行程序，无需再手动触发 Libbpf 的 open()、load()、attach()等函数，而是由高级语言程序的 init()自动完成，这样用户可以快速搭建和部署工程，只需专注于数据输出之后的处理。Coolbpf 还支持在没有 eBPF 特性的低内核版本上，通过我们提供的 eBPF 驱动，帮助它安全的在低版本上运行。我们将高版本上 eBPFverifier 校验部分实现在一个驱动里，它会进行各种安全校验，保证 eBPF 对比于内核模块的安全性。另外，我们把原来基于 libbpf 的调用都转换为 IOCTL 的系统调用。原先支持的 helper 函数、创建 map、加载 program 都会转化成低版本上的 kprobe或 tracepoint 的实现，另外还支持 perfevent 和 jit。这样就使得同一个用户程序，加载这样一个驱动，就能不修改 eBPF 程序代码而安全的运行在低版本内核上。Coolbpf 的应用实践 46 3.Coolbpf 的网络应用实践 Raptor 是基于 Coolbpf 的系统可观测工具，能够运行在低版本内核如 alios、centos3.10 等。它可以作为一个 SDK，提供给第三方使用，进行数据采集。在这个网络应用观测中，通过监控系统调用中的数据交互、请求和回复等信息，来确定交互的数据内容和五元组等信息，通过 map 的交互方式发送给用户态，做到了无侵入的方式做观测，最终呈现比如流量统计、请求时延等观测结果。Coolbpf 的应用实践 47 我们来看一个具体的问题，了解 Coolbpf 是如何发现收包阶段的网络抖动问题，我们知道网络收包分为两个阶段：阶段 1：OS 通过软中断将数据包送到应用的收包队列并通知进程，完成协议栈的收包工作。阶段 2：应用得到通知后从收包队列取数据。我们在 Coolbpf 里写一段 BPF 程序，只需监控两个 tracepoint：tcp_probe，tcp_rcv_space_adjust 就能查询到阶段 2 的延迟问题。在这个案例中，某业务应用收包慢，发现内核侧已经收到了 tcp 包，但是应用侧将近 1s 后才收到。Coolbpf 的应用实践 48 观测方法：部署 eBPFagent，发现阶段 2“收包延迟时间”将近 1 秒。确定原因：每次发生延迟时间都在某时刻的大致 42 秒处，怀疑跟业务某定时任务相关造成应用自身延时，最终排查到业务有某个任务会定时收集 jvm 的参数，对该业务有 stop 的操作。解决方法：停掉该任务后，消除了抖动问题。eBPF 安全特性解析 49 eBPF 安全特性解析 作者：许庆伟，深信服创新研究院 安全是 eBPF 应用中较为重要的一个特性。比如操作系统、软件安、网络、容器等场景都会应用到 eBPF 的安全特性。可观测性存在冰山现象，安全也是。普通开发者或用户，平时接触的多为主机安全、PC 端的安全等。PC 端或大型集群服务器的业务场景非常广泛，包括异常的攻击行为、异常漏洞等，其对应的检测范围也较大。主机端实现安全防护或检测，一般通过构建病毒库，然后不断地根据受到的攻击将新的病毒更新到病毒库，达到一定的阻断和防御目的。但该手段无法应对近年出现的新型病毒，因此我们需要利用 eBPF 的能力，比如用 eBPF 做一个容器或云原生场景的白名单，该白名单之外的所有异常行为都会被阻断。eBPF 安全特性解析 50 安全是指一种状态，在这种状态下，某种对象或对象的某种属性不受威胁。eBPF 具有以下几个安全特性：程序沙箱化：内核源代码受到保护并保持不变，eBPF 程序的验证步骤会确保资源不会程序阻塞。侵入性低：无需修改内核代码，也无需停下现有程序来验证效果。透明化：数据都从内核中透明地收集，应用无需检测监控的状态，符合安全用例。eBPF 安全特性解析 51 可配置：自定义乃至自动化配置策略，修改检测、阻断规则文件更快速，更新灵活性高、过滤条件丰富（进程、网络、文件等）。一般而言，检测到异常后，如果直接阻断，可能会对业务产生影响。因此，会先进行告警，然后根据严重程度决定是否阻断。快速检测：在内核直接处理各种事件，使得检测异常情况更方便和快速，从性能和开销上也能获得更大的收益。eBPF 程序会被 LLVM 编译为 eBPF 字节码，eBPF 字节码需要通过 eBPF Verifier 的（静态）验证，再通过比如 JIT 解析成符合要求的机器码，方能真正地运行。因此，边界检查是 eBPF Verifier 的重点工作，经过验证步骤后，能够确保 eBPF 程序可以安全运行。内核的稳定性大多与内存相关，因此 eBPF 验证器的主要工作也与其有一定的关联，也就需要确保以下几点：第一，需要拥有加载 eBPF 流程所需的特权，对指令集、指令数等都有一定要求。从安全角度来说，即使赋予程序一定的非 root 权限，部分功能可能也并没有效果。第二，不要出现 crash 或其他异常导致系统异常或内核崩溃的情况。因为 eBPF 本身的工作内容即沙箱化、无侵入、不对内核造成大的影响。第三，程序可以正常结束，无死循环。从静态分析的角度将程序完全地运行一遍，确保无死循环。eBPF 安全特性解析 52 第四，检查内存越界。如果存在内存越界，则可能导致验证不通过，流程无法往下进行。第五，检查寄存器溢出。如果存在寄存器溢出，则会导致验证流程中断。随着云网边端的急速发展，人们的目光越发聚焦在目前最火热的云原生场景上。Falco、Tracee、Tetragon、Datadog-agent、KubeArmor 是现阶段云原生场景下比较流行的几款运行时防护方案。这些方案主要基于 eBPF 挂载内核函数并编写过滤策略，在内核层出现异常攻击时触发预置的策略，在内核层对异常攻击进行记录并发出告警，无需再返回用户层，可以直接发出告警甚至阻断。以上方案多为应用层的运行时防御方案，以进程为粒度，而阻断进程会导致业务运行受到影响。因此，我们正在推进内核侧的 eBPF 与 LSM 结合的方案，期望能够解决上述问题。该方案能够从函数调用的粒度进行阻断，在白名单内记录正常的调用路径，一旦发现白名单之外的调用行为，即可阻断此次函数调用，而不会影响正常的业务运行。但此类方案目前尚存在较多的限制，比如需要较高的内核版本。此前，人们对安全的关注点大多集中于应用层规则的编写或安全策略的实施。而伴随着云原生的发展，我们会越来越注重于内核端，结合内核和 eBPF 的安全特性，进行防御和阻断。安全策略可以通过 Kubernetes（CRD）、JSON API 或 Open Policy Agent（OPA）等系统注入。eBPF 安全特性解析 53 以 CNCF 为例，上层收集到的数据后，通过 agent 到达内核端，进行一系列的收集、检测。每一个 POD 会制定规则，触发了规则之后会给予相应的措施，比如告警或阻断。基于 eBPF 的程序摄像头构想 54 基于 eBPF 的程序摄像头构想 作者：苌程，开源 eBPF 可观测项目 kindling 创始人 1.云原生可观测性挑战 云原生可观测性的核心价值在于快速排障。在日常工作中，很多时候即使使用了 Log、Trace 和 Metrics 三种手段，依然无法标准化定位问题的根因，极度依赖排障人员的个人经验，所以说当前可观测领域面临的最大挑战在于节点异常根因的定位。基于 eBPF 的程序摄像头构想 55 程序执行过程对于开发者而言是个比较复杂的黑盒子。开发者所写的代码，是运行在常用的一些依赖库之上的，而这些依赖库有运行在 JVM 或者 Go 虚拟机之上，虚拟机又运行在 glibc 之上，最后调用到内核提供的系统调用接口。每一层都可能有bug。日志与 Trace 能够部分发现用户代码层面的问题，metric 可以覆盖从用户代码到系统调用库的问题，但都不具有针对性，是一种统计结果。在黑盒情况下，我们通过技术看到的只是程序执行过程的留痕，查找问题根因时需要人为想象还原程序的执行过程，推演出可能存在的问题，再去验证。当前也有一些白盒化的方式，比如类 jstack 的线程剖析能够部分发现用户代码与类库代码现场。如果发现的是排障人员熟悉的代码，则可以在一定程度上解决问题，但是很多时候恰巧发现的是依赖库或者不熟悉的代码，则需要完整理解代码执行过程，才能进行排障。另外，如果只能看到代码层面的堆栈，当面对生产环境突发问题，某个程序正常运行后突然执行变慢或者出错，特别是多实例场景，同样的代码理应执行过程一直，那又如何解释某一个实例有问题，而其他实例没有问题。2.老刑侦的破案经验与光学摄像头 从刑侦学的知识和运用中我们可以总结出一个道理：从学会知识到到会用知识，需要经过不断练习。因此，程序员能够通过问题的表征想象出程序的运行方式也需要积累非常多的经验。基于 eBPF 的程序摄像头构想 56 几年前中国推广光学摄像头之后，全国各地的破案率达到历史最高水平。这正是因为光学摄像头极大降低了破案门槛，即便没有受过刑侦训练的普通人都可以通过生活常识结合光学摄像头就能够理解罪犯犯罪过程。3.基于 eBPF 的光学摄像头构想 我们从光学摄像头上收到了启发，开发了程序摄像头。程序摄像头将应用层的代码首先转换成内核的Tracingpoint和kprobe等基础信息，再转换成操作系统的资源消耗情况，方便用户直观地理解。我们希望开发者能够通过程序摄像头，理解程序每一秒甚至每一个毫秒的执行情况。基于 eBPF 的程序摄像头构想 57 上图左侧为 CPU 的火焰图，代表程序进程在 CPU 上消耗的时间。但在对于常规在线业务，我们认为更重要的是 OffCPU 的火焰图，它体现了程序由于何种调用堆栈引发程序暂停执行。另外，不管是 OnCPU 与 OffCPU，仅查看进程级别的数据，尚无法很好地解决可观测性问题，因为一个进程节点对外提供多个业务接口服务，我们更希望能够按照业务接口粒度去排查问题，这就需要到达线程级别的 OnCPU 与OffCPU 数据。我们需要按照程序执行过程对齐 OnCPU 和 OffCPU 到线程粒度。比如线程执行程序时在 CPU 上执行了什么代码，比如由于什么原因导致其离开了 CPU 最后恢复到 CPU上继续执行。基于 eBPF 的程序摄像头构想 58 然后在线程粒度上将 OnCPU/OffCPU 与主流的 Trace 技术按照时间轴做对齐，加上线程输出的日志，即可将执行过程完整地还原。上图为通过程序摄像头观察 ES 执行 Bulk 插入的执行情况。图中紫色段为 Bulk 从开始执行到结束的过程。可以发现其执行了三个并发进程：epoll 线程做网络的读写，显示多为空闲状态；而另外两个线程几乎将全部的时间用于 IO 读写，且被读写的文件一秒钟的增长量仅 3M/s。因此可以得出结论：机器的IO 达到了瓶颈，瓶颈为 3M/s。使用程序摄像头之前，我们一直无法确认问题根因，因为我们认为 3M/s 并不是瓶颈，它属于正常范围。基于 eBPF 的程序摄像头构想 59 通常来说，tracing 与 loging 天然地能够进行关联，因其均为代码维度。而 tracing与 metrics 难以关联，因为 metrics 是资源维度，代表程序执行完后的结论，而且metrics 维度的数据量非常庞大，一一排查太消耗时间。而 Kindling 的解法为：通过 eBPF 将线程代码过程转换为资源消耗的过程，然后每个环节在该时间段内关联相关 metric，如果是 CPU 的时间段则关联 CPU 的指标，如果是网络则关联网络的指标，能够极大地减少无关指标的干扰。我们参考 Continuous Profiling，实现了 Trace Profiling。Continuous Profiling 大多针对进程，但我们认为，用户在排障时更需要针对业务请求来进行，大多情况下只 基于 eBPF 的程序摄像头构想 60 是其中的某些业务请求出现问题；当进程出现问题时，通过 metrics 很容易识别这类问题。Trace Profiling 能够将所有线程执行的情况进行记录并重放，可以将执行的某 trace线程标记为高亮，帮助用户理解请求时每一毫秒的具体执行内容，以便确认程序根因。并且能够有针对性地关联指标，比如 CPU 密集型则关联 CPU 相关指标。4.程序摄像头构想的预期效果 总结来看，我们期望未来程序摄像头能够解决可观测领域越来越多的问题，包括但不限于以下几种场景：程序执行过程中锁占比时间较长。并发过高，线程池不够用：程序摄像头能够发现请求线程池满，请求过多导致线程池不够用，进程卡住。程序由于 Java GC 导致执行时间较长：程序摄像头可以很明确地坐实两个不同的线程之间的相互影响。程序自身执行了 CPU 开销非常大的代码。程序自身文件 IO 的读写时间较长。网络执行慢。eunomia-bpf eBPF 轻量级开发框架 61 eunomia-bpf eBPF 轻量级开发框架 作者：郑昱笙，浙江大学 1.概要 当前，eunomia-bpf 想要解决的问题或 eBPF 程序当前的开发和分发过程中存的痛点主要有以下两个：第一，对于新手而言，搭建和开发 eBPF 程序的门槛较高，必须同时关注内核态和用户态两方面的交互和信息处理，还需要编写复杂或者重复性较高的用户态加载代码。第二，在不同架构的不同内核版本上无法方便快捷地打包、分发、发布各种 eBPF 程序。eBPF 很多小工具由不同的语言开发，存在不同的接口，无法轻易集成到大型的可观测系统。当前也没有很好的插件方案，对于一个大型的 eBPF 应用，很多时候必须重新编译整个可观测的框架，再重新部署上线，才能更新 eBPF 探针或数据处理模块。另外，如果引入未经审查和测试的第三方的用户态数据处理代码，代码崩溃也可能导致整个程序崩溃。因此，我们提出了三种解决思路：eunomia-bpf eBPF 轻量级开发框架 62 第一，针对初学者，只需要编写内核态代码即可自动采样、自动获取内核态导出的数据，编译后即可进行分发、加载和运行，极大地降低了 eBPF 的学习成本，提高了开发效率。第二，基于 libbpf 一次编译处处运行的特性，将用户态和内核态的编译和运行的完全分离，通过标准 JSON 或 WASM 模块的方式进行分发，无需进行重新编译，应用启动占用资源少，时间短，甚至容器启动更短。WebAssembly（缩写 Wasm）是一种基于堆栈虚拟机的二进制格式，Wasm 是为了可移植的目标而设计。可作为 C/C+/RUST 等高级语言的编译目标，使客户端和服务器应用程序能够在 Web 上部署。到现在为止，WASM 已经发展成为一个轻量级、高性能、跨平台和多语种的软件沙盒环境，被运用于云原生软件组件，可以在非浏览器环境下运行。WASM 的设计思路和 eBPF 也有不少相似之处。第三，只编写内核态代码的时候，使用 JSON 即可完成分发、加载、打包的过程，对于完整的、需要用户态和内核态进行交互的 eBPF 应用或工具，可以在 WASM 中编写复杂的用户态处理程序进行控制和处理，并且将编译好的 eBPF 字节码嵌入在WASM 模块中一同分发，在目标机器上动态加载运行。和 WASM 生态项结合可以给 eBPF 程序带来许多特性，同时和 eBPF 程序原本的设计思路也不谋而合，比如可移植、隔离性、安全性，它也是一个跨语言、轻量级的运行环境等等；同时也可以借助 WASM 的相关工具完成 eBPF 程序的 OCI镜像的存储和分发，最近 docker 官方也推出了一个基于 WASM 的分发和运行工具。以上三部分就是 eunomia-bpf 的核心特性。接着我们和大家一起来看一些示例。2.示例 Eunomia 并不是一个完整的系统，而是类似于开发库和开发框架，可以很轻松地嵌入 coolbpf 这样的大型工具链里，或作为运行时库嵌入到任何需要使用 eBPF 作为插件的的地方。eunomia-bpf eBPF 轻量级开发框架 63 可以通过一行命令从网页端直接下载预编译好的 eBPF 程序运行。使用WebAssembly 模块或 JSON 配置文件的方式进行分发，部署时无需重新编译，启动速度相比 BCC 能提升一到二个数量级。图中使用 URL 启动 eBPF 程序的形式，也可以换成 OCI 镜像或 Docker 镜像，可以存储在 Docker 仓库或 Github Package 中，使用方式与 Docker 基本一致，只需简单地执行 pull、run 即可运行，也可以将编译好的程序包 push 下去直接使用。相比于传统的 Docker 镜像，使用 WASM 作为轻量级容器的启动速度更快，同时也保留了 eBPF 很重要的特性，可以轻松嵌入到其他程序作为子模块或插件使用，并且和具体内核版本、架构完全无关。eunomia-bpf eBPF 轻量级开发框架 64 通过 eunomia-bpf，只需编写内核态代码即可正确运行，能够最大程度减少新手的上手障碍，不需要编写 libbpf 的用户态的加载框架编写，就能够自动导出内核态perf event 或 ring buffer 事件。另外，它与和原生 libbpf 完全兼容，可以获取 libbpf tools 的内核态代码，无需修改任何代码，可直接运行。可以额外添加 tracepoint，也可以通过注释的形式添加其他内容。使用容器打包编译工具链，无需担心环境配置问题，一行命令生成项目模板、一行命令编译。这里演示的是一个简单的 wasm 模块，它可以获取当前系统的进程间的 signal 信号传递的事件。它可以接受一些命令行参数，并且对上报的信息进行处理。目前来看，我们已经可以基本上不用进行代码修改，就可以直接把 BCC/libbpf-tools里面的程序编译为 wasm 模块。对开发体验来说，也可以做到和使用 C 语言开发libbpf 的 eBPF 程序完全相同，之后也可以引入其他的语言开发 SDK。把 wasm 和 ebpf 结合起来主要的困难在于，WASM 的内存布局和 eBPF 程序并不一样，C 语言的结构体并不能直接映射，所以传递结构体必须要经过序列化操作；同时，WASM 对于访问系统资源，例如文件、网络等等，也有不少限制，很多标准库是缺失的，所以我们需要在 wasm 模块中进行一些特殊的处理和移植。3.系统架构 架构底层依赖的是内核态和用户态的基础设施，比如 libbpf 库和 Kernel 中的 eBPF虚拟机。在内核的基础设施这之上，我们会提供相关的编译工具链，和对应的运行 eunomia-bpf eBPF 轻量级开发框架 65 时加载器，帮助生成 JSON 或打包成 WASM 的模块，工具链本身使用了比如Clang/LLVM、bpftool 等工具。动态加载库可以独立使用，与 WASM 无关，也可以借助动态加载 JSON 配置信息即可热插拔、热更新 eBPF 程序的形式，通过 API 接口轻松实现 kernel function as a service（内核函数即服务）。我们还实现了 WASM 抽象层，包含 API 规范，比如用于扩展 WASM 的虚拟机 WSAI系统占用的访问形式或与eBPF交互的访问形式。还有基于WASM定制的libbpf库、移植的辅助态程序以及序列化库等，用于在 WASM 模块加载基于 libbpf 的 eBPF 程序。运行时库可以轻松进行替换，比如替换成 WSI 的 WASM 运行时。除此之外，上层还实现了 LMP、命令行工具、可观测性工具等。目前，eunomia-bpf 项目已在龙蜥社区开源，欢迎各位开发者体验，也欢迎大家提出建议和反馈，一起来做大做强。eunomia-bpf 项目龙蜥社区开源仓库：https:/ RISC-V专场龙蜥社区共建RISC-V软硬件全栈生态 平头哥在 RISC-V 软件生态的探索和实践 67 平头哥在 RISC-V 软件生态的探索和实践 作者：熊健，平头哥资深技术专家 平头哥 RISC-V 软件生态 在 RISC-V 专场，来自平头哥 IoT 研发 OS 平台团队的负责人，资深技术专家熊健介绍了平头哥在 RISC-V 软件生态的探索。从底层软件的适配，语音、视频、安全等子系统的构建，各个操作系统的应用框架的搭建和支持，到上层应用方案设计，平头哥不断深耕 RISC-V 技术和生态，端云一体的丰富生态正在形成。平头哥团队过去一年在开源社区的贡献 平头哥在 RISC-V 软件生态的探索和实践 68 平头哥持续在开源社区贡献代码，在 Linux-5.19 中发布的 106 个 RISC-V patch 中，有 43 个与玄铁 CPU 相关，并贡献了 RV32 COMPAT 和 Svpbmt 两个重要功能。通过上图看到，其中 Compat 模式能够支持 32 位应用程序在 64 位 RISC-V 的 Linux上运行，一方面可以保证 32 位应用程序的兼容性，同时也能有效降低系统内存和应用内存的占用。Svpbmt 是 MMU 页面管理的重要属性，能进一步加强 RISC-V 对于 Linux 内存管理机制的支持。Crash 是非常强大的调试工具，用于调试内核问题，长期以来 Crash 社区一直未能支持 RISC-V 架构，严重影响了 RISC-V 平台的内核调试。平头哥为 Crash社区贡献了 RV64 架构的支持方案，解决了多年来离线调试的短板，为 RISC-V 的开发带来重要意义。我们坚信，安全是未来云端一体的重要基础技术。平头哥从硬件安全到软件安全提供了全套安全体系方案，研发了全球首个支持兼容 GP 标准的 RISC-V 芯片/平台，并因此获得了全球首个基于 RISC-V 架构的 GP TEE 安全评估认证。安全的重要特点是从处理器硬件到软件具备完整、全套的安全体系，我们实现了OPTEE 全栈的技术能力，可以帮助 RISC-V 架构实现对现有安全软件生态的兼容。该安全系统能够支持 RTOS、Linux 和 Android 等多个主流操作系统，可以弹性地支持各种不同领域的安全终端产品，提供了标准的用户开发界面，保证安全应用的快 平头哥在 RISC-V 软件生态的探索和实践 69 速迁移。该安全框架已经实现了部分阿里的安全应用，可以无缝快速接入阿里巴巴生态，最大化有效复用现有的安全认证资源，减少安全认证的周期，加速产品上市速度。YOC（Yun on Chip）是一个 RISC-V 软硬融合多元体的开源 AIoT 软件平台。通过高效的芯片对接、丰富的系统组件、简洁的应用框架，能够助力芯片到终端产品的快速落地。针对不同的应用场景，YOC 可以提供接入语音、图形、视频视觉等各种系统的能力，帮助开发者在各个领域快速构建自己的应用解决方案。YOC 的最新版本 v7.6 已于近期同时在 github 和 gitee 上做了开源发布。通过支持更多 RISC-V 芯片，提供了更多通用示例，进一步提高了开发者的开发效率。YOC 的视频视觉子系统为需要低成本、高实时的 camera 场景提供了竞争力。它通过几个重要组件比如 Media Entity、内存子系统、bind 子系统、profiling 子系统提供多媒体场景需要的功能。同时能够提供硬件加速和软件处理的能力，支持 Linux和 RTOS 两个系统，可以实现跨系统的平滑迁移。未来平头哥会持续在 YoC 上深耕，进一步提高开发者的开发效率，为市场带来更多有竞争力的产品。平头哥在 RISC-V 软件生态的探索和实践 70 在端侧，平头哥引领 RISC-V 架构首次进入安卓开源生态体系，推动 RISC-V 正式与全球主流移动操作系统生态接轨。2021 年 10 月，平头哥首次在玄铁处理器上成功运行了 Android 系统，并且运行了Chrome 浏览器等大型应用，实现了业内首次 RISC-V 芯片上对 Android 的支持。今年 4 月份，我们进一步在 Android 系统上成功运行 Tensorflow Light，首次实现了RISC-V 架构对 Android AI 场景的支持。平头哥持续推进 RISC-V 在 Android 系统的工作。截止到目前，平头哥已经在 Android 相关代码仓库做了 100 多处改动，修改或提交了 2000 多个文件，改动代码超过 12 万行。为 RISC-V 支持 Android 的生态作出了重要贡献，同时也为未来 RISC-V 支撑高性能软件栈的应用打下了基础。近期，阿里巴巴平头哥提供的 RISC-V 兼容 Android 的代码补丁正式被谷歌 Android的 AOSP 社区收录进系统源代码，这是全球首批 RISC-V 兼容 Android 的正式补丁。意味着谷歌 Android 正式开启了对 RISC-V 架构官方原生的支持，也意味着 RISC-V和 Android 两大阵营的融合驶入了快车道。平头哥在 RISC-V 软件生态的探索和实践 71 Linux 系统平台也可以为开发者提供产品开发、验证以及构建产品的系统能力。Linux系统平台的软件栈自底向上分为五个软件层面，分别是 Linux 内核、设备驱动、基础系统、核心组件和系统软件。Linux 内核层，平头哥开源了平头哥各款玄铁处理器的 ARK 支持，能够为开发者提供最基础的系统支持。设备驱动层面，提供了无剑 600 平台的成熟设备驱动方案，并且提供了一套自动化验证平台。基础系统层提供了 Buildroot 和 Yocto 两种系统构建方式。Buildroot 比较简单，容易上手；Yocto 能够更有效地帮助开发者构建更为复杂的系统，并支持安装包的管理，可以帮助开发者快速构建所需 Linux 发行版。核心组件层提供了可以体现产品核心竞争力的系统组件，包括诊断、图形、视频视觉、语音、安全等各种系统组件。在系统软件层，为了提高终端用户的使用体验，我们支持了涉及到 UI 交互的大型应用，比如 Gnome、多媒体的 Gstreamere、Libra office、Firefox。Linux 的系统平台已开源发布到 Gitee，我们也会通过详尽的软件技术文档以及官网自动化 AI 机器人和客户线上支持来帮助客户和开发者快速上手 Linux 系统平台。平头哥在 RISC-V 软件生态的探索和实践 72 龙蜥 Anolis OS 是龙蜥社区的开源 Linux 发行版，已经较为成熟，支持多种 CPU 架构，但在此之前尚不支持 RISC-V 架构。平头哥在近日的 RISC-V 峰会上发布了无剑600 的高性能 RISC-V 芯片设计平台，并且基于平台提供了 SoC 原型曳影 1520。无剑 600 原生提供了 Buildroot 和 Yocto 等系统构建方式，我们也在探索寻求支持更多优秀的 Linux 发行版。龙蜥社区本次推出了桌面版的开源系统，为 RISC-V 芯片未来在桌面生态的进展奠定了良好的基础。本次平头哥与开源操作系统龙蜥 OS 的合作既是平头哥对于进入桌面领域的重要举措，也是为 RISC-V 提供真正全面从硬件到基础软件到应用层软件的全面开放性能力的体现。无剑 600 是一个软硬一体的全栈平台，不仅有硬件、有平台，也有软件包。基于无剑 600 的第一颗原型样片曳影 1520 与龙蜥社区、中科院软件所的 PLCT 实验室联 平头哥在 RISC-V 软件生态的探索和实践 73 合打造了从底层的RISC-V芯片平台到龙蜥OS再到上层基础应用和桌面应用的全栈能力。中科院 PLCT 实验室有着非常强的应用开发能力，为系统提供了 Libra office、firefox 等大型软件的支持。平头哥提供了无剑 600 的硬件平台，并且协助龙蜥社区做好了系统 bring up。过程中，平头哥向龙蜥的内核提交了 120 多个关于 RISC-V 的 ARK 以及无剑 600 相关驱动的 patch 贡献。同时密切配合龙蜥社区和 PLCT 实验室适配相关软件，也搭建了曳影 1520 云上实验室，并开放了用户体验，用户可以通过远程访问实现真实的体验。通过与龙蜥社区和 PLCT 实验室联合的技术攻关，我们已经成功在曳影 1520 上运行了龙蜥的桌面级操作系统。上图为相关实拍照片以及系统截图。这是 RISC-V 架构第一次运行 Libra office 等大型应用软件，对 RISC-V 进入未来桌面级领域运行大型复杂应用具有重要意义。此外，我们也成功运行了基于 nodeJS 和Java 的应用。未来，我们希望与龙蜥社区一起为 RISC-V 架构运行更多不同种类的软件，也非常期望可以与龙蜥社区保持密切合作，一起取得更好的成绩。开源高性能 RISC-V 处理器敏捷开发实践 74 开源高性能 RISC-V 处理器敏捷开发实践 作者：徐易难，中国科学院计算技术研究所 过去二十年，开源软件对中国产业的发展发挥了革命性作用。很多产业比如云计算、移动互联网、大数据、人工智能、区块链都基于开源软件构建了产业核心技术，使得中国移动互联网产业处于世界领先水平。开源软件成功降低了 App 的开发门槛，吸引和培养了大批人才，帮助企业建立了强大的自主研发能力。开源高性能 RISC-V 处理器敏捷开发实践 7