201806fuchsia.key

Size: px

Start display at page:

Download "201806fuchsia.key"

束舍庄
5 years ago
Views:

1 Fuchsia 简介许中兴

2 Fuchsia 的来历多年年的 Android, ChromeOS 开发经验一方面让 Google 在操作系统方面积累了了足够多的人才和组件, 另一方面也充分认识到了了 Linux kernel 很多的局限性 Fuchsia 是一个全新的操作系统的统称 Google 挑选了了一系列列它认为合适的技术和组件进入这个操作系统, 比如 : 微内核, 基于能力力的访问控制,Vulkan 图形接口,3D 桌面渲染 Scenic,Flutter 应用开发框架目前支持的编程语言是 :C/C++, Go, Rust, Dart Google2016 年年中放出了了所有的代码, 但是没有正式宣布这个项目的目标, 开发社区目前有一个 IRC 频道进行行交流支持的架构是 X86-64 和 ARM 64, 支持的设备从 IoT 到服务器器

3 现代通用开放 OS 需要面对的方面上游硬件厂商下游应用开发者设备友商用户黑客

4 Fuchsia 解决现代 OS 痛点原生进程沙箱, 解决应用安全和分发问题 ( 黑客 ) Linux: namespace, control group, unionfs => docker 稳定的驱动接口, 硬件厂商可独立维护硬件驱动 ( 硬件 ) 系统模块化, 分层, 设备厂商可以灵活定制专有系统 ( 友商 ) 基于 Vulkan 和物理理渲染的纯 3D UI, 全局光照 ( 用户 ) Flutter 应用开发框架 ( 开发者 )

5 关于进程沙箱,Fuchsia 重新思考三个 Unix 的基础抽象机制全局文件系统用户进程的创建

6 全局文件系统在 Unix 里里, 存在一个全局的根文件系统它是每个进程共享的基础资源文件系统涵盖了了非文件资源 :/proc, /sys,.. 网络是例例外在 Fuchsia 里里, 没有全局根文件系统文件和文件系统成为一个局部概念 ( 局限在每个文件系统进程里里 ), 从而在进程内核数据结构里里没有 file 用 namespace 来定义一个进程能够访问的资源每个 name( 路路径 ) 对应一个资源进程 channel 的 handle / -> root vfs service handle, /dev -> dev fs service handle, /net/dns -> DNS service handle

7 User 在 Unix 中,user 本来是用作不不同的用户登录共享服务器器的机制 user 是真正的用户后来主要用作权限控制, 弱化的沙箱机制在 Fuchsia 中, 在底层 (Zircon, Garnet) 没有用户的概念用namespace 来控制进程能够访问的资源 Capability-based access control 从而在进程里里没有 uid

8 进程的创建在 Unix 中, 新的进程由老老的进程 fork 而来新的进程继承父进程的全部资源一种偷懒的设计在 Fuchsia 中, 新进程的创建需要从头开始创建 process, thread 父进程建立初始的 namespace 到资源 channel handle 的映射调用process_start 显式的告诉内核新的进程可以跑了了在 Fuchsia 内核的 process 数据结构里里, 没有 file 和 uid

9 仿佛是专门针对漏漏洞洞利利用作出的设计典型的漏漏洞洞利利用步骤 fork()/exec() 开反向 shell 继承 uid( 或者通过获得 root uid 进行行提权 ) 获得泛在授权访问全局文件系统在 Fuchsia 里里, 以上机制全都不不存在创建进程时显式建立root namespace 没有 user, 从而没有 ambient authority (DAC/MAC) Capability-based access control 能访问的资源是父进程赋予的 namespace 看不不到初始 namespace 之外的任何资源

10 微内核 Linus vs Tanenbaum 的论战 Tanenbaum: Linux 是七十年年代的技术在 1991 年年写宏内核是错误的争论早就结束了了, 微内核已经赢了了我是教授,Minix 只是我的 hobby, 所以别拿 Minix 说事 Linus: Linux 比你写的 Minix 强多了了微内核只是你们学术界的玩具, 我看过所有的关于微内核效率优化的论文, 它们实际上只是在重复宏内核早就用过的技巧 Mach, Hurd Performance overhead Context switching (user space <=> kernel space) Thread scheduling

12 Overhead: single core case Monolithic CPU0 Context switching: 2 Micro CPU0 Context switching: 8 Thread scheduling: 4

13 CPU0 CPU0 CPU1 CPU2 CPU3

14 Overhead: multicore case Monolithic CPU0 Context switching: 2 Micro CPU0 Context switching: 2 CPU1 Context switching: 2 CPU2 Context switching: 2 CPU3 Context switching: 2

15 Fuchsia 架构 Applications Flutter Framework Kernel (process, IPC, mm) devmgr(/dev) appmgr(/hub) fshost(/) sysmgr svchost(/svc) scenic (Vulkan) devhost(/dev/x) devhost devhost devhost(gpu driver) Hardware

16 世界需要新的操作系统 Windows 老老迈龙钟, 历史负担太重, 微软自己的创新 Midori 胎死腹中, 因为无法承受在新的框架中重新实现一遍 Windows 的全部功能, 只能在原地进行行重构 Linux 只关心服务器器的世界, 就像一个专注于在甲板下面锅炉房里里干活的锅炉工, 上不不得桌面 MacOS, ios 封闭在苹果的硬件生态里里 Android 为了了弥补 Linux 的缺点打上了了一个厚厚的中间层, 不不断在做着妥协 GNU Hurd 作为 GNU 项目最后的组件一直未能产品化, 原因是微内核消息传递机制 debug 太困难? Unix 的后继者 Plan 9 于 2002 年年发布了了最后一个版本, 它的余热随着作者融入了了 Go

17 Fuchsia 在各个平台上的可能的优势在服务器器平台上, 原生的进程沙箱机制将带来新的安全特性和容器器机制在桌面平台上, 类似于游戏 3D 引擎 pipeline 的图形栈以及毫无遗产负担的实现将使电子娱乐应用变得更更为高效 ; 无缝兼容庞大的 Android 生态在移动平台上, 系统的模块化方便便第三方设备厂商的全面定制, 驱动框架方便便硬件厂商编写和维护私有驱动

18 Fuchsia 分层 Fuchsia 是一个像 Lego 玩具一样组装起来的操作系统谷歌在设计时已经考虑了了其他厂商可能会深度定制适配自己产品的操作系统, 所以模块化做得比 Android 彻底很多厂商的深度定制可以从以下任意一层开始 Zircon: 微内核, 基础服务进程 ( 设备管理理器器, 核心设备驱动,libc, 进程间通信接口库 fidl) Garnet: 设备层面的系统服务 : 软件安装, 通信, 媒体, 图形, 包管理理, 更更新系统等 Peridot: 用户体验的基础设施层 : 模块, 用户, 存储服务, 等等 Topaz: 系统的基础应用,Web, Dart, Flutter 这些名字来自于 Steven Universe

19 Fuchsia 启动流程设置各种控制寄存器器, 进入 EL1 设置内核页表, 打开虚拟内存之后进入 C 的世界用 psci smc call 启动副 cpu devmgr=> svchost, fshost, devhost, appmgr=> sysmgr userboot 从 bootfs 中加载第一个文件进程 devmgr 构造第一个用户态线程 userboot, 内核线程进入 idle 进行行一系列列初始化, 包括各种设备为当前执行行轨迹初始化为线程结构 Zircon 内核线程比较少, 主要是 dpc thread (deferred procedure call)

20 上面的符号代表虚拟地址 (-4G 之上 ) code_start=-4g, code_end tt_trampoline KERNEL_BASE boot_cpu_kstack boot_cpu_kstack_end 0 64k _start, IMAGE_ELF_ENTRY 64k+80 bss_start _end sp(third) stack_end, sp_el1, sp(first) _bootdata_file_header kernel 下面的符号代表物理理地址 (0 开始 ) _bootdata_kernel_header sp(second) _bootdata_kernel_payload kernel_image

21 第一个用户态进程的创建之前的微内核一般需要实现一个基本的文件系统加载功能在内核里里, 然后加载第一个用户进程文件, 之后就不不再使用内核里里的文件系统功能 Zircon 把第一个用户态进程的 ELF 文件嵌入进内核映像里里, 这样就不不需要从文件系统里里加载了了

22 系统调用 vdso 内核映像还嵌入了了一个 vdso, 包含了了系统调用入口这个 vdso 被映射到每个进程的内存地址空间里里它本身是 ELF shared object 文件格式, 但是又不不是以文件形态存在, 所以叫做 vdso Linux kernel 也用这种方式实现了了一些简单的系统调用, 比如 getdaytime() 但是 Zircon 并不不是为了了避免切换内核态, 而是把系统调用的代码嵌入到了了内核里里

23 内核态功能虚拟内存和物理理内存管理理 vmo: virtual memory object: 包含物理理页进程和线程管理理 Handle 指向内核中的各种对象进程间通信 channel MessagePack signal and wait 中断处理理唤醒等待该中断的用户线程没有 POSIX 支持

24 Zircon 用户态 devmgr, devhost, svchost, fshost appmgr sysmgr Fuchsia 定义了了一套稳定的 DDK 接口, 硬件厂商开发自己的闭源驱动的方便便性大大提高了了因为 Linux kernel 是拒绝提供稳定的内核内部驱动接口的要想被官方维护, 就得放进内核里里, 否则只能自己跟着内核去改接口内核不不提供 POSIX 支持, 用户层可以模拟一部分 POSIX 接口

25 channel channel 是进程间通信的 ( 唯一 ) 机制一个 channel 有 2 个 handle,h1, h2, 从一头写入消息, 从另一头读出消息一个进程在创建时有一些初始 channel handle 要与一个服务 x 建立通信, 进程创建一个 channel, 自己拿 h1, 把 h2 通过已有的 channel(root_svc) 发送给相应的服务, 服务拿到 h2, 将其放到自己的事件监听循环里里示意 api:connecttoservice(root_svc, x, h2) 比如 open(), 在 linux 里里会在进程的内核数据结构里里增加打开的文件描述符, 不不涉及到其他进程 ; 在 fuchsia 里里则是创建一个 channel, 把远端发送给相应的服务, 建立通信通道 channel_write() 把消息写到另一个进程能看到的地方进程间是不不共享内存地址空间的只有内核的地址空间是进程共享的所以 channel_write() 必须是一个系统调用, 切换到内核地址空间里里进行行消息写入一旦切换到内核地址空间里里, 就能看到另一个 handle 了了写到那个 handle 的消息队列列里里, 等另外一个进程切换到内核地址空间里里, 就能看到消息了了

26 channel 的实现 Process A Process B handleindex 1 handleindex 2 handle 1 peer handle msg list Kernel handle 2 peer handle msg list

27 Kernel Address Space Layout Randomization ELF 的加载位置是随机的, 并不不是遵守 ELF program header 里里规定的 v_addr 会在加载时对符号地址进行行修正

28 Fuchsia 目前的运行行环境 Qemu 最方便便的环境, 没有 GUI Intel NUC 目前最好的测试环境, 有 GUI Vim2 dev board 学习 ARM64 架构, 等谷歌开放出 GPU 驱动和 Bootloader

29 Qemu 在 Qemu 中可以直接运行行 booloader 加载到 0x 内核加载到 0x ramdisk 加载到 0x x x 之间是 FDT flattened device tree

30 Intel NUC 开发机启动 paving 服务, 会将整个 Fuchsia 操作系统刷到 NUC 上启动 zircon 到 zedboot 模式, 会直接连接开发机

31 Khadas Vim2 开发板 Amlogic S912 SoC Quad Core A53 Mali-T450MP5 GPU 3G DDR4 64G emmc storage HDMI, USB-C, USB 2.0, TF Card, Ethernet, WiFi, Bluetooth

32 Vim2 的启动 Arm Trusted Firmware: BL1 in ROM Custom u-boot: BL2 + BL30 +BL31 + BL32 + u-boot(bl33) 其中 bl2,bl30,bl31,bl32 都是 amlogic 提供的 binary bl33 从 emmc offset 0x50200 处开始, 加载到内存 16MB 处执行行使用fastboot 协议可以用usb-c 将 zircon kernel 写入boot 分区需要一个适合 zircon 的 bootloader 来启动 zircon, 但是 Google 尚未放出所以还不不能启动 zircon

33 系统软件研发能力力的获得系统软件与应用软件不不同有大量量的缄默知识, 长期积累的 know-how 工具链 :gcc, ld, as, clang, ELF, 微处理理器器 :X86, ARM, 周边设备 :UEFI, ACPI, APIC, PCIE, USB, SATA, AHCI, GPU 知识存在于代码中, 没有系统化的 know-how 文档, 硬件标准文档一般都是页写玩具系统容易易, 产品级的设计非常困难 : 支持海海量量的设备, 应用, 负载要经过以下四个阶段模仿理理解掌握创新

34 总结 Fuchsia 在安全方面具有重要的创新在未来 Fuchsia 会成为一个非常重要的操作系统

35 一些笔记

投影片 1

投影片 1 9 1 9-1 Windows XP Windows Server 2003 Mac OS Linux, 都 (OS, Operating System ) 2 3 , 來, 行 3 理行 4 ,, (UI, User Interface), 滑, 令列 (CLI, Command-Line Interface) (GUI, Graphical User Interface) 2 5 令列,