从Google Fuchsia理解“天然无root”

"a dream job is not about dreaming, it's all job all work all reality all blood all sweat no tears. i work a lot and i love it." 

-- TED Talk

近期华为鸿蒙操作系统的发布，“天然无root设计”，“模块化弹性部署”，“微内核”等一些词汇出现在开发者面前，由于鸿蒙尚未开源，这些概念背后的华为设计和实现我们无从考察。但站在2019年去重新思考操作系统的全新设计，现代操作系统应该被设计成怎样？Google Fuchsia是这样一个尝试回答这个问题的开源项目。

Fuchsia is not Linux

Fuchsia /'fjuːʃə/ 是Google开源的一个全新的操作系统项目，最早于2016年八月份被外媒留意到代码仓库并报导。今年5月份的Google I/O中，在介绍Flutter项目（跨平台的移动手机App UI框架）时，Google侧面确认了其正在开发中的Fuchisia操作系统，并于7月份墙外上线了Fuchisia操作系统的开发者网站（fuchsia.dev）。

Google官方对于Fuchsia的介绍，这是一个“模块化的，基于能力模型的操作系统”。网站并没有太多关于Fuchsia操作系统定位的介绍，就其当前开发中的项目代码来看，其将来设备的支持能力包括但不限于个人电脑，平板，手机，汽车，手表等多种智能终端。

Fuchsia采用Flutter作为其上层应用UI开发框架，同时Google也在Android项目的一次代码提交注释（如下图）中表明Fuchsia OS将通过一个特定的ART（Android Runtime）版本支持Android应用的运行。

不同于Google的另外两个操作系统Android和Chrome OS，Fuchsia并非基于Linux内核，而是基于一个新的名为Zircon /'zɜːk(ə)n/ 的微内核架构开发，Zircon Kernel最早由Little Kernel（LK）的一个分支发展而成。

LK是一个适用于嵌入式设备，bootloader等场景的微型操作系统（微内核），提供了线程调度，互斥量和定时器等支持，在嵌入式ARM平台，LK的核心大约15~20KB左右。部分芯片厂商（如高通，MTK）的Android操作系统使用LK作为其bootloader和TEE（Trusted Execution Environment）安全区运行环境。

Zircon 微内核

不同于为微控制器设计的LK（非常有限的RAM，少量的外设及运行任务），Zircon的设计目标是运行在具备更强处理能力的智能手机及个人电脑上。Zircon仅支持64位处理器系统，在LK的基础上增加了进程的概念，添加了用户态，基于能力的安全模型，MMU的支持以及系统调用等。（在LK以及其他面向微控制器设计的系统如FreeRTOS，RTThread等，其假设所有运行的代码均为可信任的，无用户态及内核态区分）

微内核的设计理念是将系统服务的实现与系统的基本操作规则区分开来。相对与Linux的宏内核设计，微内核系统仅在内核中保留最基础的线程调度，内存管理及基本的进程间通讯功能。将文件系统，设备驱动等实现成独立的服务进程运行在用户态。核心功能的模块化，让服务各自独立的设计减少了系统间的耦合度，可以避免单一组件失效导致整个系统崩溃。

基于微内核的Fuchsia OS使用模块化的设计，可抽换或新增某些服务进程使得内核功能更有弹性，适配运行于高低端不同级别设备的需求。

由于服务进程运行在各自的地址空间，相互之间的依赖不能像宏内核一样直接进行函数调用。在微内核架构中需要通过进程间通讯的机制来交换消息调用服务，这相对于简单的函数调用会耗费相对多一点资源和时间，期间通常也会涉及到多次进程上下文切换，内核态和用户态的切换，因此设计一个高效的进程间通讯机制对微内核系统的性能意义重大。

天然无root？

不同于Linux，Fuchsia的设计里并不存在全局的rootfs文件系统。Fuchsia使用命名空间（namespace）来管理资源访问控制。命名空间内包含了一组资源（命名对象：文件，目录，套接字，服务和设备等），由运行环境初始化组件时构建并赋予组件，作为该组件可使用的资源（组件为Fuchsia的可执行软件的基本单位）。组件可以通过Launcher服务运行其他组件，并可为其他组件赋予自己命名空间内的资源。这个设计隐含的一些意义：

• 不存在全局的root命名空间；
  

• 不存在chroot的概念，因为每个组件自己的命名空间里的资源相当于一个private root；
  

• 组件的命名空间都是针对其特定需要构建的；

• 一个命名空间内的对象路径对另一个命名空间无意义；

• 文件访问控制的机制同样适用于命名空间里的其他对象如服务和设备等；

命名空间的设计使得Fuchsia程序间的资源访问相互隔离， 各个程序（组件）只看到自己拥有的命名空间的资源，子进程可以访问的命名空间由父进程赋予。由于命名空间的访问控制与程序绑定而非运行该程序的用户，因此也不存在获得root用户权限运行程序可以有更大权限的说法。

每一个困难的事情都值得被尊重

完整的操作系统包含内核，硬件驱动，文件系统，协议栈，编程语言支持，图形渲染引擎，系统类库，应用开发框架，开发者生态等方方面面。重新从内核开始设计一个操作系统的复杂度和困难比基于Linux内核或基于Android开源版本进行修改高出几个数量级，其中涉及行业硬件厂商，软件开发者等业界各方的大力支持，Fuchsia选择了早期开源路线会是吸引业界各方共同参与项目建设的一个聪明做法。华为的工程师也曾在社区咨询过Fuchsia的Zircon内核如何单独构建的问题，Fuchsia的代码仓库里也出现了华为对麒麟970芯片支持的代码合并。Fuchsia目前对外开放的文档还有不少缺失的章节，作为一个通用的操作系统Fuchsia还有很长的路要走，但在某些特定领域的产品上（比如物联网，智能音箱Google Home Hub）应用，把需求限定在特定领域问题的解决上，Fuchsia未来两年的发展还是非常值得期待。每一个大型项目的兴起都将给行业带来更多的机会和挑战，同样的，未来华为开源的鸿蒙操作系统也非常值得从业人士的期待。

End

更多干货

• 特斯拉智能化路上的左脑+右脑

• 从TDengine的开源说起技术选型

• 那个上传的通讯录有毒！

• 服务网格（Service Mesh）与Kubernetes的服务发现

• 琐言：团队带领者的知识覆盖模型
  

关注我们

公众号：曲奇泡芙

扫码关注不迷路

批评指正点这⬇️