1、组件化多模式内核设计与实践石磊泉城实验室安全操作系统联合创新中心2024.3.30纲要 组件化内核开源项目的发展概况-目标特点-构成方式-当前状态 组件化支持模式内核的设计实践-面临问题-解决思路-下步想法组件化内核开源项目ArceOSrcore-os/arceos:An experimental modular OS written in Rust.()ArceOS是清华大学陈渝教授和他的学生贾越凯博士发起的一个开源的组件化OS项目，最初目标是研究和实践基于Rust语言开发组件化的安全操作系统的理论和方法。目前开源项目团队已经具备一定规模，参与者来自高校(清华大学)、研究机构(泉城实验室)、

2、企业(乾云、国汽智联等)，也包括对操作系统感兴趣的很多个人。希望通过开源协作的方式联合产学研各类型机构的力量和各自优势，探索OS生态建立的方式，向实用化逐步迈进。组件化内核的意义通过对现有的典型OS内核的分析和我们对多种模式内核的实践，发现：即使不同模式的OS内核乃至它们的具体实现之间，也存在很多共性的部分；但是在实际OS开发实践过程中，往往进行重复劳动，即使想到去复用其它实践已经形成的成果，也要付出较大的代价。抽取功能形成组件抽取共性功能并封装为独立组件，进而形成组件仓库，以此为基础，形成另外一种的内核开发形式：可以选择适当的组件，采取适合的组合方式，来构建各种模式的内核。这种方式将在内核开

3、发的效率、内核产品可靠性等方面都带来显著的提升，并且有利于内核开发者之间基于组件的协作。最简单OS架构1.单特权级2.单地址空间组件仓库约束范围建立初始组件集合1.语言级安全支持 类型/内存/并发安全2.组件=crate,接口=trait3.dependencies+features 选择与组合组件安全支持组件支持ArceOS开源项目组件化设计多模式支持基于Rust语言从Unikernel起步组合方式Unikernel模式设计目标和特点宏内核模式Hypervisor模式宏内核Hypervisor扩展组件扩展组件ArceOS组件化系统构成整体到局部按组件类型面向场景与应用内核构建源于场景需求，场

4、景组件为根，以此起点，按依赖关系逐级关联组件，形成单向依赖的近似树形的组件集合；并寻求满足应用运行需求的最小组件集合。ArceOS整体子系统组件模块模块组件模块模块子系统组件模块模块组件模块模块系统构成主干组件主干组件主干组件功能组件功能组件互备功能组件场景组件组件组件组件组件主干组件:承上启下逐级启动，负责组织当前阶段的功能组件进行初始化。功能组件:对应OS功能。有些功能包含多个备选，根据配置进行选择。主干启动过程最后一步进入应用入口。组件是基本元素，通过接口访问。组件按照功能相关形成子系统，进而子系统构成ArceOS组件库。组件内部由一系列模块构成，模块接口仅服务于内部，不公开。系统构成-

5、主要子系统和组件公开接口基础框架modules算法/策略cratesaxtask内存管理任务调度spawnyieldaxMod/api.rsallocatorsched_fifosched_rrsched_cfstlsfbuddyslabbyte_allocaxallocpage_allocschedulerexit设备管理axdriverinit_driversDriverProbemmio/pci/driver_pcidriver_virtio块设备驱动文件系统网卡驱动ramdiskvirtio-blkdriver_blockbcm2835sdhciBlockDriverOpsixgbev

6、irtio-netdriver_netdriver_virtioNetDriverOpsaxnet网络协议栈axsyncsmoltcptcp socketudp socketaxfsaxfs_vfsaxfs_ramfsaxfs_devfsfile_opsdir_ops核心组件仓库Hypervisor虚拟化Unikernel 组合方式宏内核 组合方式Hypervisor 组合方式ArceOS UnikernelOS相关OS无关LinuxRust for Linux组件组件复用扩展组件仓库ArceOS宏内核unikernel多进程组件linux syscall多地址空间特权级扩展组件仓库进程底层组

7、件:访问硬件中层组件:获取服务上层组件:操作接口当前发展状态合并合并X86_64riscv64aach64loongarchsched_cfssched_rrsched_fifofatfsramfsextfsramfsvirtiopcie1000bcm2835重点：兼容Linux Syscall面向试点场景应用提供支持Type1.5 虚拟化跨域调用PythonJaveZLM组件化内核实践-面临关键问题组件的可复用性1.组件的功能划分与粒度2.组件接口的规格化(标准化)组件化内核参考模型问题1-组件的功能划分与粒度-原因分析组件要有合理的功能划分与合理粒度，这个直接影响组件间的耦合性，当然影响复

8、用。是否合理取决于解决的问题的背景。axfsmountfsfile/dir解决循环依赖的技术方法有很多，关键问题不在这，关键是循环依赖关系本身破坏组件设计的独立性，增加了耦合性，进而增加复用的难度。axsyncmutexaxtasktaskUnikernel模式axfsmountfsfile/diraxsyncmutexaxtasktask宏内核 模式fdtable结构定义struct关联方法new/get/set新增关联方法(涉及A)组件B结构定义struct关联方法new/get/set组件A成员结构定义struct关联方法new/get/set新增关联方法(涉及A)组件B结构定义stru

9、ct关联方法new/get/set组件A成员组件C问题1-组件的功能划分与粒度-解决思路面向对象角度，资源对象的结构与方法关联到同一组件中。但是随着内核功能的增强，新增的关联方法不仅针对相关结构，还有可能涉及其它基本结构及其方法。例如组件B的新增方法牵扯组件A。对于跨资源对象的操作方法，独立为单独组件，例如组件C。这样就提出一种一般方法：此类情况下，组件分两层，下层组件仅包含资源对象的基本结构与单纯方法，跨资源结构的操作放到上层。针对问题1-调整后的参考模型示例形成一个多层的组件分布设计，各层组件具有自上而下的单向依赖关系。工具型组件：典型OS无关基础的资源组件层：仅包含结构的定义和最基本单纯

10、的关联方法；并且内部也存在上下层关系。操作型组件层：跨资源操作，主要支持syscall的实现。组织组件，决定：1.选择哪些组件2.采取的组合方式Leader与组织组件联合代表一种特定的内核模式与具体实现。它们是OS相关，其余都归入OS无关的高复用性组件。Leader组件：塔顶位置，引领特定模式与实现。syscall框架：固定复用问题2-组件接口的规格化(制定和统一接口标准)ArceOS组件化项目在最初的实践过程中，就引入接口规格化以实现兼容接口的多个互备组件。内存分配接口任务调度接口cfsrrfifoslabbuddytlfsHALx86_64aarch64riscv64组件接口规格化的必要性

11、：1.提供接口兼容的可以相互替换的组件集合：采用不同算法的性能权衡、各种安全策略的考虑，生产状态与预备上线组件在切换期间的互备存在。2.从团队协作方式：一方面，统一的组件接口规格，让来自不同内核实践、不同开发者的组件可以协同工作；另一方面，不必一定要接受现有组件的实现，或必须在现有组件上修改，可以自己实现新的兼容组件，通过接口测试即可，降低新组件进入组件库的门槛。Task组件的接口规格分析以宏内核的Task为基准，Unikernel的Task是简化的特例，Hypervisor是特权级切换的变种。功能组件：支持syscall的实现。各个组件的功能单一，因此接口也相对简洁单纯。它们有时需要涉及对多

12、个资源的操作。syscall组件：接口转发，保持工作逻辑简单任务组件：中继支持功能组件，三步调用：1.取得当前任务指针2.取得目标资源指针3.操作目标资源资源组件：仅提供核心结构的get/set方法，跨越资源的操作都上调到功能组件，因此多数接口保持相对简单。基础设施组件：1.与体系结构无关的工具组件，接口易统一2.与体系结构相关组件，基于HAL接口提供服务，接口简单但是琐碎、数量多组件化内核参考模型-组件仓库-开发实践组件化参考模型：来自于对各个内核开发的实践的对比分析，提取出共性的功能组件和并进行接口标准化，形成一个建议模型。组件仓库：包括跨模式的通用组件和各领域的组件，首要重点是基础的通用组件。内核开发实践：基于组件仓库，构造各模式的内核或Hypervisor。欢迎参与本项目的研发与讨论！https:/