赞
踩
又一波微内核讨论,同时也见到网上太多的言论,甚至把RT-Thread物联网操作系统归类到微内核行列。所以重新把这篇科普文章发下,并做部分澄清。
本篇文章是RT-Thread新加入伙伴,俊小哥 对微内核学习后的科普文章,本文是第一篇;还有第二篇《Fuchsia微内核的性能指标情况》,已有初稿,后续在整理完毕后再分享给大家,会详细给出相同硬件平台下Fuchsia和Linux的应用性能对比指标。
关于微内核的定义,这里有一份简单的描述:内核运行在内核态,只包含基本的多任务调度功能;其他系统服务都运行在用户态,包括文件系统,网络协议栈,甚至内存管理,驱动都是一个个独立的用户态进程,并相互做内存隔离。应用需要使用系统服务时,都通过IPC发送消息来使用其他用户态服务。而宏内核,用户应用是通过系统调用直接来使用系统服务。所以微内核,消息传递是基本形态。基于这样的理解,RT-Thread目前是宏内核,更严谨些应该是Unikernel(内核与应用都运行在内核态)。
对于十分碎片化物联网场景,对其中大部分的海量物联网节点来说,并不适合使用微内核,因为其中Flash、RAM资源非常紧张(例如Cortex-M架构或其他MCU,普遍在数百kB Flash空间,几十kB RAM空间),甚至是按照字节方式节省着使用,已经负担不起内核与应用分离的方式来使用。而微内核中常提及的安全隔离优点,在MCU上也没有硬件来支撑(没有MMU,或者MPU能保护的区段数也非常受限)。这也是RT-Thread对这类资源受限设备,始终都维持这样构架的原因。
——熊大
下面让我们重温俊小哥的微内核科普文章:
微内核设计的基本思想是简化内核功能,在内核之外的用户态尽可能多地实现系统服务,同时加入相互之间的安全保护。内核只提供最基础的服务,比如进程调度,进程通信(IPC)等。其中进程通信是作为连接应用与用户态系统服务的桥梁。
下图是宏内核与微内核的对比示意图
上图左侧表示宏内核的架构,宏内核系统相关的服务基本都是放于内核态内核中,例如文件系统,设备驱动,虚拟内存管理,网络协议栈等;而微内核,则把更多的系统服务(例如文件系统,POSIX服务,网络协议栈,甚至外设驱动)放到用户态应用,形成一个个服务,等待其他应用的请求。
而后来,为了在宏内核与微内核之间扬长避短,也发展出了中间的混合内核的形态,部分服务也会放置于内核中。上图右侧表示即是混合内核的架构。
其实微内核与混合内核,混合内核与宏内核之间并无十分明确的界限,一般情况下把最多只具备IPC(进程通信),进程调度,内存管理功能的内核称为微内核、把包含所有系统服务的内核称为宏内核、有少部分系统服务在用户态或者比微内核多一些系统服务的内核称为混合内核。
微内核这个概念从提出开始就在不断地发展、完善进步之中,到目前为止可以分为三代。
第一代微内核的主要代表是Mach,该系统由卡内基-梅隆大学的Avie Tevanian和Richard Rashid主导开发。在Mach刚刚开始设计时,UNIX的发展正如日中天,所以Mach在设计时的一大目标就是兼容UNIX,但是与UNIX不同的是Mach尝试使用微内核架构去设计。Mach以IPC是作为所有系统服务与内核交换数据的基础机制,充分运用IPC,虚拟内存,多进程等特性将冗余的系统服务移出内核作为进程运行。
1986年,经过两年的开发,第一版的Mach发布后的第二年,Mach就发布了第2版,不过由于时间仓促,加之没有足够的人手与资金,所以此时Mach内核并不提供完全的系统服务。为了支撑系统上层运行,这一版的内核包含了大量4.3版本的BSD系统(UNIX的一个分支)代码提供系统服务,并且BSD系统服务运行在内核状态,这导致Mach内核的代码体积甚至大于常规UNIX内核。第一版和第二版的Mach主要做了如下工作:1. 验证了微内核的可行性;2. 在多处理器计算机上进行移植验证了微内核在多处理器计算机上的运行;3. 最后为了提高IPC的效率,Mach使用共享内存机制来完成IPC。而Mach的共享内存机制是在虚拟内存技术的支持下实现的,只有需要对内存进行写入时才进行复制。这么一处理比每次都复制一遍内存节省了内存使用同时又加快了IPC机制的处理时间,这个改进称为写时复制,并且在如今的通用操作系统如Linux中常常用到。
经过测试,Mach 2.5的效率最多比UNIX少25%,考虑到Mach带来的可靠性,可拓展性,安全性,这个损失尚可以接受。当然此时Mach内核还不算完全的微内核。而考虑到微内核可以更高效地利用多处理器计算机的处理器核心资源,人们期待着等Mach把系统服务都搬到内核之外后可以把运行效率损失降下来。同时Mach在微内核方面小小的尝试迅速吸引了大批公司与组织的注意,开放软件基金会(Open Software Foundation, OSF)宣布下一代系统OSF/1将基于Mach的内核, NeXTSTEP也将使用Mach2.5, 甚至IBM也打算利用Mach构建Workplace OS。苹果公司这个时候也出手了,苹果公司也从此基于Mach2.5打造其操作系统内核XNU,XNU的构成如下图所示,Mach作为内核的内环,外环右侧是苹果的驱动框架(I/O Kit),外环左侧是BSD的系统服务代码提供UNIX兼容的服务层,这三者共同协作向上层提供完整的系统服务。XNU广泛地使用在苹果公司的OSX,IOS等系统中。
这个时候由于UNIX系统广泛使用带来的商业利益,此时BSD系统开发者与UNIX的拥有者AT&T陷入了法律大战,Mach使用的BSD相关代码有了法律风险。提升性能的期望和规避法律风险的需求推动着Mach 3.0的开发,Mach 3.0的开发目标主要是为了替换BSD系统服务,同时尽量多地将系统服务放到内核之外去运行,成为名副其实的微内核设计。经过众多开发者3年的努力,Mach 3.0于1990年发布,但是由于在系统服务之间完全使用IPC通信,而不是向宏内核那样直接进行函数调用,即便是多处理器机器上运行也性能损失惨重,Mach 3.0最多比UNIX损失 67% 运行效率,这导致Mach 3.0以及其所代表的第一代微内核设计被看衰。此后断断续续有在Mach的基础上对性能进行提升的尝试,但是均不太理想,至此Mach成为了微内核第一代先驱者。第二代微内核的主要代表是L3和L4,以及QNX系统使用的Neutrino内核。前面第一代的微内核Mach由于效率问题虽然失败了,但是微内核的理念并没有被放弃,德国的计算机科学家Jochen Liedtke认为Mach的IPC效率低下的原因就是因为IPC部分不够精简,于是他开发了L3和L4微内核,对IPC部分进行了很彻底的精简:1. 内核的IPC机制只是单纯地传递信息,诸如安全权限检查这类的代码都省略掉,省略掉的功能全部由用户进程自己处理。如此一来IPC功能部分的代码执行时间大大缩短;2. IPC不使用内存传递消息,而使用寄存器传递消息,同时限制IPC每次传递的信息长度,这样省去了对内存的访问时间。L4微内核的IPC速度经过测试要比Mach快20倍,这个令人惊讶的优化效果吸引了众多的目光,使微内核的研究重新火热起来。后面L4内核又发展出了很多相关系统,比如Pistachio,L4/MIPS,与Fiasco等等,这些内核组成了L4的大家族。
第二代微内核的代表除了有L4内核,也还有其他微内核比如Exokernel,Rambler,不过商业上最成功的则是目前黑莓公司旗下的QNX系统所使用的Neutrino内核(QNX,1980年时最早以QUICK UNIX诞生;2004年QNX被Harman国际收购;2010年被黑莓收购Harman国际下的QNX资产),QNX主要为高可靠领域提供解决方案,比如交通,能源,医疗,航天航空等。
在前面两代的基础上,第三代微内核蓬勃发展,许许多多微内核都被开发出来,主要代表有:seL4, Fiasco.OC, NOVA等。本来第一代微内核的设计隔离了使内核安全性降低的系统服务,让系统服务漏洞不会影响内核,进而提高了内核安全性,可以说是关上了破坏系统的门, 但是第二代系统却又给攻击者开了个窗户;由于第二代微内核在内核中省去了关于安全性检查等步骤,把所有关于安全检查功能的实现都交给系统服务自己去实现,这导致系统服务的通信接口直接暴露给用户态,任何进程都可能无限制地请求系统服务,系统服务不得不花费额外的代价来区分请求是否合法,容易造成拒绝服务攻击。比如正常的文件服务应该是从虚拟文件系统服务->文件系统服务->磁盘驱动服务这个流程来完成的,但是如果攻击者如果绕过虚拟文件系统服务,直接无限制地请求攻击者本身没有权限访问的文件系统服务,使文件系统服务长期处于满载状态,让其他进程无法通过正常的虚拟文件系统得到文件系统服务。为了增强安全性,且不过分影响性能,人们开始研发第三代微内核。
seL4是在第二代内核L4的基础上发展而来的。seL4不仅仅继承了L4内核家族的高性能特性,还具备基于端点(enndpoint)的IPC机制。这种IPC机制最大的特点是使用了能力空间的概念,进程在使用IPC请求系统服务时必须具备相对应的能力,进程持有不可伪造的令牌来表示拥有请求某种服务的能力。令牌可以被复制,可以被转移,还可以通过IPC进行传输。令牌其实是一个指向存在于内核空间内核对象的指针,所以普通进程并不能修改自身以及其他进程的权限分配,但是内核可以对令牌指定的权限进行控制,从而保证了用户态不能绕过能力空间这个机制对系统服务造成滥用。
seL4还是第一个完全通过形式化验证的内核,通俗说形式化验证就是在数学软件的帮助下使用数学语言自动化地推导检查系统的每一个运行状态。seL4形式化验证相关论文。
Fuchsia是Google开发的一款全新操作系统,试图覆盖手机,平板,甚至笔记本等一系列领域。Google为该系统配备了Vulkan图形接口,3D桌面渲染Scenic,Flutter应用开发框架,还有一个称为zircon的微内核。zircon内核是从高通平台的一个Bootloader项目:Little Kernel发展而来。zircon内核属于微内核设计,只提供IPC,进程管理,地址空间管理功能。zircon区别于以进程或者以文件为核心的设计,zircon是以内存为核心来设计的,内存在zircon中是以对象的方式存在,可以通过channel通信机制传递虚拟内存对象(Virtual memory object)的句柄,进程拿到句柄后可以把这块内存映射到自己的空间。
Minix系统则由荷兰阿姆斯特丹的Vrije大学的Andrew S. Tanenbaum教授所开发。该系统最大的特点是可以故障隔离,自动重启失败的服务。Minix使用分层设计,最底层的微内核提供中断处理,进程管理,进程通信等服务,中间层提供轮回服务(Reincarnation Server),这一层运行在内核态;文件服务,进程管理,X图形服务以及驱动等,这一层运行在用户态;最上层为用户进程。其中轮回服务负责在中间层的服务出现崩溃时重启这些服务,从而保证服务的自我修复。Minix由于其自我修复特性被英特尔管理引擎(ME)所选用,该管理引擎主要负责管理英特尔芯片的内部模块。
系统服务模块化,可移植性高;
内核安全性提高(模块内部的bug不影响内核稳定,将黑客利用软件漏洞造成的破坏限制在单个模块内部);
可以多套系统服务共存,相当于同时运行多种操作系统;
稳定统一的接口(可以独立维护私有驱动以及服务,不需要跟内核源码绑定);
在商业上,微内核可以避免代码受到一些开源协议的影响,比如GPL协议。
内核精简,可以进行形式化验正,利用数学证明内核的安全性;
数学可证明的实时性;
非常适合多处理器系统设计,在多处理器核心计算机上,互相依赖的系统服务可以同时运行;
通过进程通信的方式交换数据或者调用系统服务,而不是使用系统调用,造成额外的操作系统开销。
使用一些频繁使用的系统服务时,比如网络收发数据,造成的进程上下文切换对操作系统来说也是一个负担。
由于系统服务高度模块化,系统服务之间存在大量的内存复制。
对互相之间存在复杂调用关系的系统服务,难以设计通信接口。
系统服务与内核在地址空间上分离,造成代码局部性差,降低了cache命中率。
END
RT-Thread线上活动
1、【RT-Thread能力认证考试12月——RCEA】经过第一次考试的验证,RT-Thread能力认证得到了更多社区开发者和产业界的大力支持!(点此查看)如果您有晋升、求职、寻找更好机会的需要,有深入学习和掌握RT-Thread的需求,欢迎垂询/报考!
能力认证官网链接:https://www.rt-thread.org/page/rac.html(在外部浏览器打开)
立即报名
#题外话# 喜欢RT-Thread不要忘了在GitHub上留下你的STAR哦,你的star对我们来说非常重要!链接地址:https://github.com/RT-Thread/rt-thread
你可以添加微信18917005679为好友,注明:公司+姓名,拉进 RT-Thread 官方微信交流群
RT-Thread
让物联网终端的开发变得简单、快速,芯片的价值得到最大化发挥。Apache2.0协议,可免费在商业产品中使用,不需要公布源码,无潜在商业风险。
长按二维码,关注我们
看这里,求赞!求转发!
点击阅读原文进入GitHub
Copyright © 2003-2013 www.wpsshop.cn 版权所有,并保留所有权利。