精华内容
下载资源
问答
  • seL4微内核操作系统初期总结 2018.10
    2020-01-14 15:45:54

     ab12696@qq.com衷心感谢您的拜读,希望我的分析对您有所帮助;另外,若您发现本文分析错误,或seL4版本更新特性变化,您可以发邮件告诉我,以便我能及时更新。考虑到关于信息量较多,在阅读过程中难免出现语义难明的词汇,对于前文出现的所有非公共词汇,后文均会明确其含义,请耐心阅读。

    seL4综述——可能是一个以权限控制为基础的微内核

    ——————————seL4相关理念——————————

    1. 由于seL4官方文档未区分Thread和Process,因此下文表述均采用线程

    2. 关于权限,seL4描述为能力,明确的抽象出3大基本元素:

    Read、Write、Grant(权限授予,即传递)。

    #define seL4_ReadWrite seL4_CapRights_new(0, 1, 1)

    #define seL4_AllRights seL4_CapRights_new(1, 1, 1)

    #define seL4_CanRead   seL4_CapRights_new(0, 1, 0)

    #define seL4_CanWrite  seL4_CapRights_new(0, 0, 1)

    #define seL4_CanGrant  seL4_CapRights_new(1, 0, 0)

    #define seL4_NoWrite   seL4_CapRights_new(1, 1, 0)

    #define seL4_NoRead    seL4_CapRights_new(1, 0, 1)

    #define seL4_NoRights  seL4_CapRights_new(0, 0, 0)

     

    3. 显式的权限控制

    seL4的权限控制是显式的,seL4的一切操作

    (下文提到的seL4提供的基础服务)

    都要在CSpace存在相关权限的情况下才能执行

     

    4. 权限:Grant

    seL4的权限以CNode为单位可被复制、转移。

    由于权限的可复制即可产生子权限,因此可以形成权限树。

    CSpace即据此组织CNode,形成有向图。

     

    5. 线程的VSpace和CSpace

    线程的创建会建立VSpace和CSpace,VSpace即虚拟地址空间;

    CSpace为Capability Space,

    为seL4内核的Capability全面控制提供基础

    6. 线程的IPC Buffer

    存在于其他线程通讯、与内核通讯需要的线程,

    在创建时即加入IPC Buffer,为后期IPC的基础,

    为设置IPC Buffer的线程不能对外通讯。

     

    7. 内存管理

    seL4仅可能分配出power(2,n)且大于16byte的内存

     

    8. 一般平台无关内存对象大小

    n-bit Untyped对象 power(2,n) bytes(n>=4)

    n-bit CNode对象 16*power(2,n) bytes(n>=2)

    Endpoint对象 16 bytes

    Notification对象 16 bytes

    IRQ Control --

    IRQ Handler --

     

    9. 其他平台相关对象

    TCB对象——一般1KB/512bytes

    页表相关对象

    ASID相关对象

    ——————————seL4词汇解释——————————

     

    1. Capability——权限的复合体,内容丰富

    (可能是seL4最精华的理念,因为seL4的一切据此展开)。

    每个线程不光有地址空间(VSpace),

    还有CapabilitySpace。

     

    线程想要调用系统功能,将会通过调用

    能力空间中的能力来实现系统功能

    (如IPC会调用endpoint capability)

     

    2. CNode(capability node)

    Capability的基础承载者,

    创建时即确定拥有的slot数量(power of 2),

    slot用于保存Capabilities,

    所保存的Capability为更深层的CNode时,即形成有向图。

    也由此,当父CNode的Capability被取消时,

    其子将会递归取消此Capability。

     

    3. TCB 一般线程控制块

     

    4. Endpoints

    为线程间通讯提供支持(详述见IPC)

     

    5. Notification 一般信号机制

    poll

     

    6. Untyped Memory 未类型内存

    Untyepd内存可被Retype成seL4定义的一些内存对象。

     

    7. CDT树(capability derivation tree)

    ——追踪源capability复制出的capability。

     

    CDT虽是独立的概念,但在实际实现是CNode对象的一部分

    (其实现可能是CNode数据结构中)

    seL4_Untyped_Retype()//大致是申请内存

    seL4_CNode_Mint();//复制CNode(可能包含权限降低)

    seL4_CNode_Copy();//复制CNode

    seL4_CNode_Mutate();//迁移CNode(可能包含权限降低)

    上述函数均生成子capability,均被CDT追踪。

    8. Slot——一段物理内存空间的实体。

     

    ——————————seL4基础服务——————————

    1. 线程(Threads)

    上下文切换、处理器时间分片的基本单位。

    1.1 每一个线程,都会有相应的CSpace(Capability Space)

    和VSpace(Virtual Space);

    同时,线程还会有IPC buffer,

    用于实现线程间通讯(详述见1.3 IPC)。

    1.2 每一个线程都有其归属的调度域

    (此处调度域与linux中存在很大区别)。

    内核在完成编译时就确定了此内核中的调度域的个数,

    内核将会定时、循环的调度各域。

    调度域内可存在多个线程(无上限),

    当且仅当线程所在调度域正在调度中时,线程才可能被调度执行。

    1.3 在调度域内,seL4采用256优先级的抢占式循环调度器。

     

    2. 地址空间(Address space)

    虚拟地址空间,由页表完成地址翻译。

    由于ASID资源限制,seL4设计了一个ASID Pool,

    通过ASID Control能力,线程VSpace与ASID Pool链接,

    以及通过ASID Pool使用ASID。

     

    3. 线程间通讯(IPC Inter-process communication)

    seL4线程间通讯通过endpoint(我认为应该是某种端点的含义)进行,

    消息内容的第一段为tag段,

    含有四部分:标志,消息长度,能力个数,开放能力的区域。

    seL4在IPC通讯时,会尽可能多的使用CPU寄存器,

    很多短内容的消息会直接通过CPU寄存器完成传递。

    seL4对IPC通讯的支持并不关心内容,

    需要用户层根据IPC消息的tag、消息所传来的能力等获得消息全部。

    (感觉类似socket?优化了的socket。)

    其他细节还很多,在此仅给以简述。

     

    4. Notification

    非阻塞的信号机制(与linux类似),比如对多路复用I/O的支持等。

     

    5. Device primitive

    seL4驱动是作为非特权程序执行在内核外,

    内核通过IPC实现硬件终端的分发。

     

    6. Capability Spaces(CSpace)

    CSpace是一个线程下CNode组成的的有向图的集合;

    也就是线程所拥有的Capability的集合。

     

    seL4以线程为单位拥有CSpace,

    内核启动第一个用户线程时即为之创建CSpace,

    此CSpace将包含所有其创建的CNode,

    当然也就包含所有其子线程的CSpace。

     

    CSpace含有CNodes,CNode中address可以找到slot,

    slot中有(或无)capability;

    当slot的Capability为另一个CNode,即可形成有向图;

    对每个线程,其CSpace都存在root CNode,可连通所有节点,

     

    另:

    线程发生系统调用,就会找到线程CSpace中,

    关于这个系统调用Capability的address,

    进而读取到相应slot,slot内容决定此系统调用是否执行。

     

    内核通过CNodes对象管理线程的CSpace;

    (简单说就是所有CNode都是连在一起的,有着共同的根,

    根据父子进程,CSpace通过CNode产生逐级依赖)

     

    ——————————seL4创建线程——————————

     

    1. seL4_Untyped_Retype()

    Retype对象来创建线程的TCB

     

    2. seL4_TCB_SetSpace()/seL4_TCB_Configer()

    设置TCB的CSpace、VSpace和EndPoint等

     

    3. seL4_TCB_WriteRegisters()

    关于栈指针和指令指针的一些操作

     

    4. seL4_TCB_Resume()

    激活线程,线程将会加入其父所在CPU调度

     

    5. 至此,线程将会被执行

     

    6. seL4_TCB_SetAffinity()

    在多核平台,可设置此线程的执行CPU

     

     

    ——————————seL4一些特点——————————

     

    1.缓存溢出免疫(基于严苛的capability设计)

    Buffer overflows are a classic security attack against operating systems, trying to make the software crash or even to inject malicious code into the cycle. We have proved that no such attack can be successful on seL4.

     

    2.访问空指针免疫(原理未知)

    Null pointer dereferences are another common issue in the C programming language. In applications they tend to lead to strange error messages and lost data. In operating systems they will usually crash the whole system. They do not occur in seL4.

     

    3.C中指针指错数据类型免疫(原理未知)

    In C it is possible to accidentally use a pointer to the wrong type of data. This is a common programming error. It does not happen in the seL4 kernel.

     

    4.内存泄漏免疫(基于严苛的capability设计)

    Memory leaks occur when memory is requested, but never given back. The other direction is even worse: memory could be given back, even though it is still in use. Neither of these can happen in seL4.

     

    5.算术溢出/异常免疫(原理未知)

    Humans and mathematics usually have a concept of numbers that can be arbitrarily big. Machines do not, they need to fit them into memory, usually into 32 or 64 bits worth of storage. Machines also generate exceptions when you attempt to do things that are undefined like dividing by zero. In the OS, such exceptions would typically crash the machine. This does not occur in seL4.

     

    6.未定义行为免疫(原理未知)

    There are many static analysis and verification tools that check for the absence of undefined behaviour in C. Our proof explicitly checks that no such undefined behaviour occurs.

     

     

    ——————————seL4总结————————————

    1. seL4内核层面的显式权限控制可以提供很高的安全保障,如DDOS不再有效。

     

    2. seL4提供的内存管理类类似于伙伴系统,能够有效减少内存碎片的产生,同样,不灵活的内存管理模式应该难以对内存充分利用。

     

    3. seL4的IPC基于Endpoint,受制于Capability,短消息由于采用CPU寄存器传递,效率不会明显下降,但长消息机制依赖于IPC Buffer的复制,效率不高。

     

    4. seL4的调度域根本隔离,带来的安全保障我并未想到,但调度域的静态设置应该会带来域内线程对用户响应的延迟,造成用户操作卡顿。

     

    因此,基于上述分析, 

    seL4的形式验证是一大亮点,

    其显式的权限管理也可以带来安全,

    但seL4还很年轻,社区活跃度不是非常高;

    seL4的应用开发框架基于C语言,必须采用接口-实体开发模式,

    不支持变长参数函数、函数指针等,因此代码移植可能存在难度。

    基础设施建设不完善,基于其设计思想的工业应用很少,

    若要真正投入使用,需要详尽分析其内核细节,

    详细分析其可能存在的缺陷、困难再考虑是否应用。

     

     

    seL4后续

    1.seL4中断通过Notification分发

    中断触发后,内核signal特定Notification,

    线程会seL4_Wait()/seL4_Poll()这个notification

     

    用户态用

    seL4_IRQHandler_SetNotification()

    之后线程开始seL4_Wait()/seL4_Poll()这个notification

     

    中断到达,线程处理完后

    seL4 IRQHandler Ack()提示内核处理完,内核可以发进一步的数据或后续中断

     

    seL4_IRQHandler_Clear()接触这个Notification的注册

     

    seL4没在主线中支持DMA

    但对于x86

    seL4支持了IOMMU

     

    也是作为一种能力

     

    seL4使用musl libc

    seL4可能会有文件系统(同济裴喜龙)

    seL4用的是gcc -O1,

    有形式验证过的编译器CompCert

     

    Norman Feske是搞Genode的,

    Genode是微内核之上的系统框架,

    这个系统框架类似linux的rootfs,

    Norman Feske把Genode移植到seL4了。

     

    写于2018.10

    更多相关内容
  • 国内知名大学的sel4文档手册,相当值得借鉴,中文版。带书签。
  • seL4操作系统编程.pdf

    2021-09-10 11:20:31
    seL4的功能介绍,API编程手册说明,非常详细
  • seL4:seL4微内核

    2021-05-11 14:08:24
    seL4微内核 该项目包含seL4微内核的源代码。 有关seL4微内核的详细信息,包括其形式正确性证明的详细信息,请访问网站和相关的 。 引用此存储库的最新版本的DOI: 我们欢迎对seL4的贡献。 请访问该网站以获取有关...
  • 沙发:在seL4微内核之上构建的操作系统
  • SEL4微内核是一个操作系统内核,被设计成在各种应用领域中为系统提供安全、安全和可靠的基础。 作为一个微内核,它为应用程序提供了少量的服务,例如创建和管理虚拟地址空间,线程的抽象,进程间通信的抽象。 内核的...

    1.介绍

    SEL4微内核是一个操作系统内核,被设计成在各种应用领域中为系统提供安全、安全和可靠的基础。
    作为一个微内核,它为应用程序提供了少量的服务,例如创建和管理虚拟地址空间,线程的抽象,进程间通信的抽象。
    内核的小尺寸也有助于对最坏情况下的执行时间进行完整而合理的分析。
    本手册从用户的角度描述sel4内核的API。
    本文首先简要概述了seL4微内核设计,然后介绍了seL4内核向用户空间公开的高级API。

    2.内核服务和对象

    微核提供了有限数量的服务原语,更多的复杂服务可以作为这些原语之上的应用程序来实现。
    这样,在特权模式下,系统的功能可以在不增加代码和复杂性的情况下进行扩展,同时仍然支持各种应用程序域的大量服务。

    sel4提供的基本服务如下:

    1.线程是支持运行软件的CPU执行的抽象

    2.地址空间是每个包含应用程序的虚拟内存空间。应用程序仅限于访问地址空间中的内存

    3.进程间通信是经过端点允许线程进行数据传输

    4.通知提供了一种类似于二进制信号量的非阻塞信号机制

    5.设备原语将设备驱动程序作为非特权应用程序实现。内核通过IPC消息导出硬件设备中断。

    6.功能空间存储内核服务的功能(即访问权限)及其簿记信息。(簿记信息是啥?)

    本章概述了这些服务,描述了用户空间应用程序如何访问内核对象,以及如何创建新对象

    2.1 基于能力的访问控制

    seL4微内核提供了一个基于功能的访问控制模型。

    访问控制管理所有内核服务,为了执行操作,应用程序必须调用其拥有的对请求的服务具有足够访问权限的功能。

    这样,系统就可以被配置为相互隔离软件组件,并且通过有选择地授予特定的通信能力,在组件之间启用授权的、受控的通信。
    这使得软件组件隔离具有高度的保证,因为只有那些由能力占有明确授权的操作才被允许。

    一个功能是一个不可伪造的令牌,它引用一个特定的内核对象(比如线程控制块),并携带控制哪些方法可能被调用的访问权限。

    从概念上讲,能力存在于应用程序的能力空间中;这个空间中的地址指的是一个插槽,它可能包含也可能不包含能力。

    应用程序可以引用一个内核服务的能力,例如使用拥有该能力的插槽的地址。
    这意味着,seL4能力模型是隔离(或分区)能力系统的实例,其中的能力由内核管理。

    能力空间被实现为一个由内核管理的能力节点(cnode)组成的有向图。CNode是一个槽位表每个槽位可能包含更多的CNode功能
    能力空间中的能力地址是插槽索引与节点索引的串联,形成到目标插槽的路径(这一点后续再看)

    功能可以在功能空间内复制和移动,也可以通过ipc传送。这个允许创建具有特定访问权限的应用程序,将权限委派给另一个应用程序,并将应用程序权限传递给新创建(或选定)的内核服务。此外,还可以使用原始功能的一部分权限创建派生功能(决不能使用更多权限)。新创建的功能可用于部分授权。

    还可以撤销功能从而撤销权限,撤销将递归地删除从被撤销的原始功能派生出来的任何功能。功能在系统中的传播由一个基于许可的模型控制。

    2.2 系统调用

    seL4内核提供了一个消息传递服务,用于在线程。这个机制还用于与内核提供的服务进行通信。有一个标准的消息格式,每个消息包含一些数据字和一些可能的功能。第四章详细描述了这些消息的结构和编码。

    线程通过调用其功能空间中的功能来发送消息。当以这种方式调用一个端点功能时,消息将通过内核传输到另一个线程。
    当调用内核对象的功能时,消息将被解释为以特定于内核对象类型的方式进行的方法调用。例如,使用格式正确的消息调用线程控制块(TCB)功能将挂起目标线程。

    逻辑上,内核提供三个系统调用:发送、接收和输出。然而,也有一些基本的Send和Receive调用的组合和变体,例如Call操作,它由来自同一个对象的一个Send和一个Receive组成。

    除了端点和通知之外,内核对象上的方法都映射到发送或调用,这取决于方法是否返回结果。(端点,通知还有方法是什么?)
    Yield系统调用不与任何内核对象相关联,并且是唯一不调用功能的操作。

    完整的系统调用:
    sel4_send:通过指定的功能和应用程序传递消息以继续。如果调用的功能是一个端点,并且没有接收者准备好立即接收消息,则发送线程将阻塞,直到消息可以被传递。
    sel4_NBSend:在端点上执行轮询发送。它与sel4send()类似,只是保证不会阻塞。如果消息不能立即传递,即没有接收者在目标点等待,则消息会自动丢弃。
    sel4_recv:由线程用于通过端点或通知接收消息。如果没有发件人或通知处于挂起状态,则调用者将阻塞,直到可以传递消息或通知为止。此系统调用仅适用于一个点或非通知功能,在尝试使用其他功能类型时会引发错误。
    sel4_Call:该调用将阻塞发送方线程,直到其消息被传递并收到回复消息为止,当sent消息被传递到另一个线程(通过endpoint)时,内核向传递到接收方的消息添加了一个额外的“reply”功能,使接收方有权回复原始发送方。应答能力存放在接收方的TCB中的一个专用插槽中,是一个单一的使用权,这意味着内核一旦被调用就会使它失效。
    sel_Reply:用于应答sel_call的,并使用产生于sel_call系统调用的应答功能,并存储在回复线程的TCB中。
    sel_ReplyRecv:是sel_reply和sel_recv的结合,它存在的主要原因是:通常情况下,响应一个请求并等待下一个请求可以在单个内核系统调用中执行,而不是在两个内核系统调用中执行。从应答到接收阶段的转换也是原子的。
    sel_NBRecv:线程使用它来检查通知对象上挂起的信号或端点上挂起的消息,而不阻塞。此系统调用仅适用于端点和通知对象功能.
    sel4_Yield:是唯一不需要使用某种功能的系统调用。它会丧失调用线程的时间片的剩余部分,并导致调用内核的调度程序。如果没有其他与调用者具有相同优先级的可运行线程,调用线程将立即使用新的时间片调度。

    2.3 内核对象

    在本节中,我们简要概述了内核实现的对象类型,这些类型的实例(也称为对象)可以由应用程序调用。这些对象的接口构成了内核本身的接口。
    内核服务的创建和使用是通过创建,操作和组合这些内核对象来实现的。

    CNodes:存储功能,允许线程调用特定对象上的方法,每个节点都有固定数量的插槽(slot),通常是2的幂,这取决于节点的创建时间,插槽可以是空的也可以包含功能。

    线程控制块(TCB):表示seL4中的一个运行线程,线程是调度、阻塞、非阻塞等的执行单元,具体取决于应用程序与其他线程的交互。

    Endpoints:促进了进程之间的消息传输,IPC是同步的:试图在端点上发送或接收消息的线程会阻塞,直到消息可以传递为止,这意味着只有当发送者和接受者在端点汇合时,消息传递才会发生,内核可以通过一个拷贝传递消息。
    端点的功能可以被限制为只发送或只接收。此外,端点功能可以拥有授予权,这允许将功能作为消息的一部分发送

    通知对象:提供一个简单的信号机制。一个通知是一个字大小的标志数组,每个标志的行为都像一个二进制信号量。操作在单个操作中向标志的子集发出信号,轮询检查任何标志,并阻塞直到任何标志被发出信号。通知功能可以是仅限信号的或仅限等待的。

    虚拟地址空间对象:用于为一个或多个线程构造虚拟地址空间,这些对象很大程度上直接对应于硬件对象,因此依赖于体系结构。内核还包括用于跟踪地址空间状态的ASID池和ASID控制对象。

    中断对象:中断对象给应用程序接收和确认来自硬件设备的中断的能力。最初,IRQControl有一个功能,它允许创建IRQHandler功能。IRQHandler能力允许管理与特定设备相关联的特定中断源。它被委托给一个设备驱动程序来访问中断源。IRQHandler对象允许线程等待并确认单个中断。

    非类型化内存:无类型内存是sel4内核中内存分配的基础。非类型化内存功能只有一个方法,允许创建新的内核对象。如果方法成功,调用线程将获得对新创建对象的功能的访问权。此外,非类型化内存对象可以划分为一组较小的非类型化内存对象,允许委托部分(或全部)系统内存。我们在下面的章节中一般地讨论内存管理。

    2.4 内核内存分配

    sel4微内核不为内核对象动态分配内存,相反,必须通过非类型化内存能力,从应用程序控制的内存区域显式创建对象。
    应用程序必须有明确的内存权限(通过非类型化内存能力)才能创建新对象,并且所有对象一旦创建就会消耗固定数量的内存。
    这些机制可用于精确控制应用程序可用的物理内存的具体数量,包括能够强制隔离应用程序或设备之间的物理内存访问。
    除了由硬件规定的资源之外,内核中没有任何任意的资源限制,因此可以避免许多由于资源耗尽而导致的拒绝服务攻击。

    在引导时,seL4预先分配内核本身所需的内存,包括代码、数据和堆栈部分(seL4是一个单内核堆栈操作系统)。然后创建一个初始用户线程(具有适当的地址和功能空间)
    然后,内核将所有剩余内存以非类型化内存的功能形式交给初始线程,并将引导初始线程所需的一些额外的内核对象功能交给初始线程。然后可以使用seL4 Untyped Retype()方法将这些非类型化内存区域分割为更小的区域或其他内核对象;创建的对象被称为原始无类型内存对象的子对象。

    使用seL4 Untyped Retype()创建对象的用户级应用程序,将接收对结果对象的全部权限。然后,它可以将其对该对象拥有的全部或部分权限委托给一个或多个客户端。

    非类型化内存对象表示两种不同类型的内存:通用内存或设备内存
    通用内存可以非类型化为任何其他对象类型,并用于内核提供的非类型化内存上的任何操作。设备内存覆盖由硬件平台决定的为设备预留的内存区域,这些对象的使用受到内核的以下方式的限制:

    1. 设备非类型化对象只能重新键入到帧或其他非类型化对象中;例如,开发人员不能从设备内存创建端点
    2. 从设备中重新类型化的帧对象不能设置为线程IPC缓冲区,或用于创建ASID池

    子无类型对象的类型属性(是否表示的是通用或设备内存)继承父亲的无类型对象,也就是说,未类型化设备的任何子设备也将是一个未类型化设备。开发人员不能更改无类型的类型属性。

    2.4.1 重用内存

    到目前为止所描述的模型对于应用程序分配内核对象、在客户机应用程序之间分配权限以及获得这些对象提供的各种内核服务是足够的。对于一个简单的静态系统配置来说,这一点就足够了。

    seL4内核还允许重用非类型化内存区域。只有当内存中的对象没有悬空引用(即功能)时,才允许重用内存区域。(悬空引用是啥)
    这样生成的树结构称为能力派生树(CDT)。2例如,当用户通过重新键入非类型化内存来创建新的内核对象时,新创建的功能将作为非类型化内存功能的子功能插入CDT。

    对于每个非类型化内存区域,内核保留一个水印,记录之前分配了多少区域。每当用户请求内核在非类型化内存区域中创建新对象时,内核将执行以下两种操作之一:
    如果区域中已经分配了现有对象,内核将在当前水印级别分配新对象,并增加水印。如果所有先前在区域中分配的对象都已被删除,内核将重置水印并从区域开始重新分配新对象。

    最后,CNode对象提供的seL4 CNode Revoke()方法销毁了从参数capability派生的所有功能。将最后一个功能撤消到内核对象会触发对现在未引用的对象的销毁操作。这只是清除它、其他对象和内核之间的任何内核依赖关系。

    通过对非类型化内存对象的原始功能调用sel4cnoderevoke(),用户将删除非类型化内存对象的所有子对象,即指向非类型化内存区域中对象的所有功能。因此,在这个调用之后,没有对非类型化区域中的任何对象的有效引用,可以安全地重新键入和重用该区域。

    2.4.2 对象大小总结

    在重新键入非类型化内存时,了解对象需要多少内存是很有用的。表2.1、2.2和2.3总结了物体尺寸。

    注意cnode和非类型化对象有变量大小。当将非类型化内存重新键入cnode或将非类型化对象分解为更小的非类型化对象时,使用seL4 untyped Retype()的size bits参数来指定结果对象的大小。表2.1显示了size bits参数(n)与seL4 Untyped Retype()之间的对应关系,以及每个可变大小对象的结果大小。

    对于所有其他对象类型,大小是固定的,seL4-Untyped_Retype()的size_bits_参数被忽略。对seL4UntypedRetype()的一次调用可以将单个无类型对象重新键入为多个对象。要创建的对象数量由它的num_objects参数指定。所有创建的对象必须具有相同的类型,由type参数指定。对于可变大小的对象,每个对象也必须具有相同的大小。如果所需内存区域的大小(通过对象大小乘以num_objects来计算)大于未类型化对象剩余的未分配内存,则会产生错误。

    3.功能空间

    回想一下第2.1节,seL4实现了基于功能的访问控制模型。每个用户空间线程都有一个关联的功能空间(CSpace),它包含线程所拥有的功能,从而控制线程可以访问哪些资源。

    回想一下,功能驻留在称为cnode的内核管理对象中。CNode是一个槽位表,每个槽位可能包含一个功能。这可能包括进一步扩展cnode的功能,形成一个有向图。从概念上讲,线程的CSpace是有向图中从CNode能力(CSpace根)开始就可到达的部分。

    CSpace地址指的是一个单独的插槽(在CSpace中的某些cnode中),它可能包含也可能不包含功能。线程在它们的cspace中使用存放该功能的槽的地址来引用功能。在CSpace中的一个地址是CNode能力的索引的连接,形成到目标槽的路径;

    功能可以在CSpace中复制和移动,也可以在消息中发送,此外,新的功能可以从旧的功能中的权限子集来获得。seL4维护了功能派生树(CDT),它在其中跟踪这些复制的功能与原始功能之间的关系。revoke方法删除了从所选功能派生的所有功能(在所有cspace中)。服务器可以使用这种机制来恢复它们提供给客户端的对象的唯一权限,或者非类型化内存的管理器可以使用这种机制来销毁内存中的对象,以便重新类型化。

    seL4要求程序员从用户空间管理所有内核内的数据结构,包括cspace。这意味着用户空间程序员负责构造cspace以及其中的寻址功能。本章首先讨论能力和CSpace管理,然后讨论如何在CSpace中处理能力,即应用程序在调用方法时如何引用其CSpace中的单个能力。

    3.1 能力和能力空间的管理

    3.1.1 CSpace的创建

    CSspace是通过创建和操作CNode对象而创建的。创建一个CNode时,用户必须指定它将拥有的插槽数,这决定了它将使用的内存量。每个插槽需要16个字节的物理内存,并且有恰好容纳一种能力的容量。
    像任何其他对象一样,CNode必须通过在适当数量的非类型化内存上调用seL4UntypedRetype()来创建(参见2.4.2节)。因此,调用者必须能够在现有cnode中获得足够的非类型化内存以及足够的空闲能力槽,以便seL4UntypedRetype()调用成功。

    3.1.2 CNode方法

    功能主要通过调用CNode方法来管理。
    CNode支持以下方法:
    sel4_cnode_mint():从现有功能在指定的CNode插槽中创建新功能。新创建的功能可能比原功能拥有更少的权限,并且有一个不同的保护。sel4nodemint()也可以从一个未标记的功能创建一个标记的功能。

    sel4_cnode_copy():与sel4_cnode_mint()类似,但新创建的功能与原来的功能具有相同的标记和保护。

    sel4_cnode_move():在两个指定的功能插槽之间移动功能。不能将功能移动到当前所在的插槽中。

    sel4_cnode_mutate():可以类似于sel4_cnode_move()移动功能,也可以类似于sel4_cnode_mint()减少其权限,但不保留原始副本。

    sel4_cnode_rotate():在三个指定的能力槽之间移动两个能力。它实际上是两个seL4CNodeMove()调用:一个从指定的第二个插槽到第一个插槽,一个从指定的第三个插槽到第二个插槽。第一个和第三个指定的槽位可能相同。

    sel4_cnode_delete():删除指定slot的能力。

    sel4_cnode_revoke():相当于对指定功能的每个派生子级调用sel4_cnode_delete()。它对能力本身没有影响,除非在第3.2节中概述的非常特殊的情况下。

    sel4_cnode_savecaller():将当前线程的内核生成的应答能力从创建它的特殊TCB插槽移动到指定的CSpace插槽。

    sel4_cnode_cancelbadgesends():取消任何使用相同标记和对象作为指定功能的未完成发送。

    3.1.3 新重新类型化对象的功能

    当使用seL4UntypedRetype()将未类型化内存重新类型为对象时,新重新类型化对象的功能将被放置在CNode的连续槽中,该CNode由根、node_index和node_depth参数指定。node_offset参数指定将放置第一个能力的CNode的索引。num_objects参数指定要创建的功能(以及对象)的数量。所有插槽必须为空,否则将导致错误。所有产生的功能都将放在同一个CNode中.

    3.1.4 能力权利

    如前所述,某些功能类型具有与之相关联的访问权限。目前,访问权限与端点(见第4章)、通知(见第5章)和页面(见第7章)的功能相关联。与功能相关联的访问权限决定了可以调用的方法。seL4支持三种正交访问权限,即读、写和授予。每个权利的含义是相对于各种对象类型进行解释的,详见表3.1。
    第一次创建对象时,引用它的初始能力携带最大访问权限集。使用诸如sel4nodemint()和sel4 cnodemutate()之类的方法,可以从这个原始功能中制造出其他不那么强大的功能。如果在这些调用中的任何一个中,为目标功能指定了比源功能更大的权限集,那么目标权限将被静默地降级为源权限。

    3.1.5 能力派生树

    正如2.4.1节中提到的,seL4在一个能力派生树中跟踪能力派生。
    各种方法,如seL4CNodeCopy()或sel4 cnode mint(),可以用于创建派生功能。并不是所有的功能都支持派生。通常,只有原始功能支持派生调用,但也有例外。
    总结各种能力类型的能力派生要成功必须满足的条件,以及如何在每个案例中报告能力派生失败。未列出的功能类型只能派生一次。
    在这里插入图片描述

    显示了一个示例功能派生树,该树演示了一个标准方案,顶层是一个大型非类型化功能,第二层将此功能拆分为两个区域,由他们自己的非类型化功能覆盖,这两层都是第一层的子集,左侧的第三级是第二级非类型化功能的副本,复制时的非类型能力总是创建子级,而不是兄弟级,在这个场景中,非类型化功能被输入到两个独立的对象中,在级别4上创建两个功能,它们都是各自对象的原始功能,都是从中创建的非类型化功能的子功能。
    普通的原始功能可以有一个级别的派生功能。这些派生功能的进一步复制将创建兄弟版本,在这种情况下仍在级别5上。对于端点和通知功能,这个方案有一个例外——它们通过标记支持额外的一层深度。原始端点或通知功能将被取消标记。使用mint方法,可以创建具有特定徽章的功能副本(见第4.2.1节,第5.1节)
    同一个对象的这个新的、带标记的功能被视为原始功能(“原始带标记端点功能”),并像其他功能一样支持一个派生的子级别
    在这里插入图片描述

    3.2 删除和撤销

    seL4中的功能可以被删除和撤销。这两种方法都主要影响能力,但它们可能对系统中的对象产生副作用,因为删除或调用会导致对对象的最后一种能力的破坏。

    如上所述,seL4CNodeDelete()将从指定的节点插槽中删除功能。通常,这就是所有发生的事情。但是,如果它是某个对象的最后一个类型功能,那么这个对象现在将被内核销毁,清除内核引用中剩余的所有内容,并准备内存以供重用。

    如果要销毁的对象是一个能力容器,即TCB或CNode,销毁过程将在销毁容器之前删除容器中保存的每个能力。如果包含的功能是最后的功能,这可能导致进一步对象的销毁。

    sel_cnode_revoke方法将删除派生树中指定功能的所有子功能,但是功能的本身不变,如果任何已撤销的子功能是对象的最后一个功能,则会触发相应的销毁操作。

    注意:sel4cnoderrecall()可能在两种特定情况下只能部分完成。第一个是包含执行撤销的线程的TCB的最后一个功能(或TCB本身的最后一个功能)的CNode由于撤销而被删除。在这种情况下,执行撤销的线程在触发期间被销毁,撤销未完成。

    第二种情况是,包含作为吊销目标的功能的存储作为吊销的结果被删除。在这种情况下,执行吊销的权限将在操作过程中被删除,并且操作会中途停止。这两种情况都可以而且应该通过构造在用户级别避免。
    注意,对于页表和页目录,sel4cnoderrecall()不会撤销映射到地址空间的帧功能。他们只会在空间中消失。

    3.3 CSpace 寻址

    在执行系统调用时,线程通过在其CSpace中提供地址来向内核指定要调用的功能。此地址是指调用方的CSpace中包含要调用的功能的特定插槽。
    cspace的设计允许稀疏性,并且查找功能地址的过程必须是高效的。因此,cspace被实现为受保护的页表。

    如前所述,CSpace是CNode对象的有向图,每个CNode是一个槽位表,其中每个槽位可以是空的,也可以包含一个功能,该功能可以引用另一个CNode。回想一下2.3节,CNode中的插槽数必须是2的幂。CNode有一个基数,也就是2的幂的大小,也就是说,如果一个CNode有2k个槽位,那么它的基数就是k。内核在线程的TCB中存储每个线程CSpace的根CNode的能力。从概念上讲,CNode功能不仅存储对它所引用的CNode的引用,而且还携带一个保护值,见3.3.1节。

    3.3.1 功能地址查找

    与虚拟内存地址一样,功能地址只是一个整数。与引用物理内存的位置(如虚拟内存地址)不同,能力地址引用能力槽。当查找用户空间线程提供的功能地址时,内核首先查询线程的TCB中的CNode功能,该TCB定义了线程的CSpace的根。
    然后,它将CNode的保护值与能力地址的最有效位进行比较。如果这两个值不同,则查找失败。如果保护位是相同的,要看这个radix位,它最终可能指向下一个cnode,这个cnode包含我们要找的能力。那个slot可能包含cnode也可能包含其他东西,也可能啥都没有。
    如果s包含一个CNode能力c,并且能力地址中还有剩余的位(在radix之后)还没有被转换,那么就会重复查找过程,从CNode能力c开始,并使用能力地址的剩余位。否则,查找过程成功终止;此处的能力地址指的是能力槽。

    在这里插入图片描述

    • 顶级CNode对象,12位保护设置为0x000和256个插槽
    • 具有直接对象引用的顶级CNode
    • 具有两个二级CNode引用的顶级CNode
    • 具有不同防护和槽数的二级CNodes
    • 第二级CNode,包含对顶级CNode的引用
    • 第二级CNode,包含对另一CNode的引用,其中还有一些位需要翻译
    • 第二级CNode,其中包含对另一CNode的引用,其中没有剩余的位要被翻译
    • 第二级CNodes中的对象引用

    3.3.2 寻址能力

    能力地址存储在一个CPointer(缩写为CPTR)中,它是一个无符号整数变量。根据上面描述的翻译算法处理功能。两种特殊情况涉及到CNode能力本身的寻址和一系列能力槽的寻址。

    回想一下,上面描述的转换算法将遍历CNode功能,但仍有需要转换的地址位。因此,为了为CNode能力寻址,用户不仅必须提供一个能力地址,而且必须指定要转换的能力地址的最大位数,称为深度限制。

    某些方法,如seL4UntypedRetype(),要求用户提供一系列的功能槽。这是通过提供一个base capability address(引用范围中的第一个槽位)和一个window size参数来实现的,该参数指定范围内槽位的数量(在基槽位之后有连续的地址)。

    在这里插入图片描述
    Cap A:第一个CNode有一个设置为0x0的4位保护和一个8位基数。Cap位于插槽0x60中,因此它可以被格式为0x060xxxxx的任何地址引用(其中xxxxx是任意数字,因为翻译过程在翻译地址的前12位之后终止)。为简单起见,我们通常采用地址0x06000000

    Cap B:同样,第一个CNode有一个4位保护设置为0x0,还有一个8位基数。第二个CNode通过L2 CNode cap到达。它还有一个4位保护0x0,Cap B驻留在索引0x60处。因此,Cap B的地址是0x00F06000。此地址的转换在前24位之后终止。

    Cap C:这种能力是通过两个CNodes来实现的。第三个CNode通过L3 CNode Cap到达,该Cap位于第二个CNode的索引0x00处。第三个CNode没有防护罩,而Cap C位于索引0x60处。因此,它的地址是0x00f00060。此地址的翻译将保留0位未翻译

    Cap C-G:通过提供0x00F00060的基址(指包含Cap C的插槽)和5的窗口大小来寻址这个能力插槽范围。

    L2 CNode Cap:回想一下,要定位CNode功能,用户不仅必须提供功能地址,还必须指定深度限制,即要转换的最大比特数。L2 CNode Cap位于firstCNode的偏移量0x0F,该节点有一个4位的0x0保护。因此,它的地址是0x00F00000,深度限制为12位。

    L3 CNode Cap:这个功能位于第二个CNode的索引0x00,由L2 CNode Cap到达。第二个CNode有一个4位的0x0保护。因此,该功能的地址为0x00F00000,深度限制为24位。注意L2和L3 CNode Caps的地址是相同的,但是它们的深度限制是不同的。

    总之,要引用CSpace中的任何功能(或插槽),用户必须提供其地址。当功能可能是CNode时,用户还必须提供深度限制。要指定功能插槽的范围,用户需要提供起始地址和窗口大小

    3.4 查找失败描述

    当功能查找失败时,将向调用线程或线程的IPC缓冲区中的异常处理程序提供失败的描述。描述的格式总是相同的,但根据错误发生的方式,IPC缓冲区中的偏移量可能不同。描述格式如下所示。第一个单词表示查找失败的类型,后面单词的含义取决于此。

    3.4.1 无效的根

    CSpace CPTR根目录(在其中查找功能)无效。例如,该功能不是aCNodecap

    3.4.2 缺失能力

    调用所需的功能不存在或没有足够的权限

    3.4.3 深度不匹配

    在解析一个功能时,遍历一个CNode,该CNode解析的比特数超过了CPTR中留给解码的比特数,或者遇到了一个非CNode功能,但仍有剩余的比特需要查找

    3.4.4 保护不匹配

    解析功能时,CNode的保护大小大于剩余的位数,或者CNode的保护与解析的PTR的下一位不匹配

    4.IPC

    seL4微内核为线程间的通信提供了一种消息传递IPC机制。同样的机制也用于与内核提供的服务进行通信。通过调用内核对象的功能来发送消息。发送到端点的消息被指定给其他线程,而发送到其他对象的消息则由内核处理。本章描述通用的消息格式、端点,以及如何将它们用于应用程序之间的通信。

    4.1 消息寄存器

    每个消息都包含一些消息字和可选的一些功能。消息字通过将它们放置在线程的消息寄存器来发送或接收。消息寄存器被编号,前几个消息寄存器是使用物理CPU寄存器实现的,而其余的由一个称为IPC缓冲区的固定内存区域支持。

    这种设计的原因是效率:非常短的消息不需要使用内存,物理CPU消息寄存器如下所示
    在这里插入图片描述
    在这里插入图片描述
    每个IPC消息也有一个标记(结构为seL4MessageInfo_t)。标签由四个字段组成:标签、消息长度、功能数量(extraCaps字段)和capsUnwrapped字段。消息长度和功能的数量决定了发送线程希望传输的消息寄存器和功能的数量,或者决定了实际传输的消息寄存器和功能的数量。标签不被内核解释,它作为消息的第一个数据有效负载未经修改地传递。例如,标签可以用来指定请求的操作。
    capsUnwrapped字段仅在接收端使用,用于指示接收功能的方式。第4.2.2节对此进行了描述。

    内核假设IPC缓冲区包含表4.3中定义的seL4IPCBuffer类型的结构。内核使用尽可能多的物理寄存器来传输IPC消息。当传输的参数多于可用的物理消息寄存器时,内核开始使用IPC缓冲区的msg字段来传输参数。但是,它在这个数组中为物理消息寄存器留下了空间。

    例如,如果IPC传输或内核对象调用需要4个消息寄存器(在这个体系结构上只有2个物理消息寄存器可用),那么参数1和2将通过消息寄存器传输,参数3和4将在msg[2]和msg[3]中。
    如果需要,这允许用户级对象调用存根将在物理寄存器中传递的参数复制到msg数组的剩余空间。tag字段的情况类似。在seL4IPCBuffer结构中有这个字段的空间,内核会忽略它。用户级存根可能希望将消息标签从其cpu寄存器复制到此字段,尽管内核提供的用户级存根不这样做。
    在这里插入图片描述

    4.2 Endpoints

    端点允许在两个线程之间传输少量数据和功能(即IPC缓冲区)。使用第2.2节中描述的seL4系统调用直接调用端点对象。

    IPC端点使用集合模型,因此是同步和阻塞的。端点对象可以对发送或接收的线程进行排队。如果没有接收方准备好,执行seL4Send()或seL4Call()系统调用的线程将在队列中等待第一个可用的接收方。同样,如果没有准备好发送方,执行seL4Recv()系统调用或seL4ReplyRecv()的后半部分的线程将等待第一个可用的发送方。

    4.2.1 endpoint badges

    可以创建端点功能,以创建带有badge(由mint操作的调用者选择数据字)的新端点功能。当用baged权能发送消息到端点时,badge被转移到接收线程的badge寄存器。

    带有零标记的端点功能被称为unbadge。这样的功能可以在包含该功能的CNode上使用seL4CNodeMutate()或sel4cnnodemint()调用进行标记。带有徽章的端点功能不能被取消标记、重新标记或用于创建带有不同徽章的子功能。

    只有低28位的徽章可以使用。内核会无声地忽略任何高4位的使用

    4.2.2 权能转移

    如果发送线程调用的端点功能具有授予权限,则消息可能包含将被传输到接收方的功能。尝试在没有授权的情况下使用端点功能发送功能,将导致原始消息的传输,而没有任何功能的传输。

    要在消息中发送的功能在发送线程的IPC缓冲区的caps字段中指定。该数组中的每个条目都被解释为发送线程的能力空间中的CPTR。要发送的功能数量在消息标签的extraCaps字段中指定。

    接收方指定它愿意接收能力的槽位,IPC缓冲区中有三个字段:receiveCNode、receiveIndex和receiveDepth。这些字段分别指定根CNode、能力地址和要解析的位数,以找到放置能力的槽位。第3.3.2节描述了能力寻址。

    接收端能力与原始能力拥有相同的权利,除非接收端能力缺乏写权限。在这种情况下,通过从接收的功能副本中剥离写权限,对发送功能的权限被削弱。

    请注意,接收线程可以只指定一个接收槽,而发送线程可以在消息中包含多个功能。包含多个功能的消息可以由内核对象解释。在消息中的一些额外功能可以展开的情况下,还可以将它们发送给接收线程。

    如果第n个能力指的是端点的消息通过消息发送,能力是打开:它的徽章是放在第n个位置数组接收机的徽章,和内核设置第n个点(从最低有效计数)capsUnwrapped消息的字段标签。能力本身没有被转移,所以接收槽可以被用于另一个能力。

    如果接收方收到一条消息,其标签的extraCaps为2,capsUnwrapped为2,则消息中的第一个能力被转移到指定的接收槽,第二个能力被打开,将其徽章放置在徽章中。发送者的邮件中可能存在无法打开的第三种功能。

    展开全文
  • seL4系统论文

    2016-01-04 11:40:40
    本文描述了seL4实时系能的基本测试。文中详细分析了中断响应时间、进程间切换的测试。
  • 作者:Gernot Heiser gernot@sel4.systems 翻译:TriAlley lg139@139.com 翻译版本:1.2 2020-06-10 原文:https://sel4.systems/About/seL4-whitepaper.pdf 译者学识浅薄,文中许多专有名词和英语文化表达尚未明晰...

    首发地址:http://trialley.top/pages/53ac44/
    CSDN地址:https://blog.csdn.net/lgfx21/article/details/117606097
    翻译与转发许可:
    在这里插入图片描述

    作者:Gernot Heiser gernot@sel4.systems

    翻译:TriAlley lg139@139.com

    翻译版本:1.2 2020-06-10

    原文:https://sel4.systems/About/seL4-whitepaper.pdf

    译者学识浅薄,文中许多专有名词和英语文化表达尚未明晰,均用括号标注英文原文。如果您有翻译建议,欢迎评论或邮件告知于我,不胜感激。

    vuepress的markdown不支持引文,文中[^1]样式的字段表示在文末有相应参考文献

    译注

    翻译中出现了许多容易混淆的名词,且某些词组仅在本文档中初出现过,国内外都找不到其他出处。由于译者并不是专业翻译,也不是微内核从业者,因此对这些名词只能尽量进行进行合理的意译,不周之处还请批评指正。

    1. security and safety
      1. security:包括防盗,防欺诈和篡改等。如data security数据加密防盗
      2. safety:指自身运行的安全特性。如data safety数据备份防丢失
      3. 在中文语境中,security和safety都可以指代安全,但英文中他们侧重不同。不同行业都使用这两个词语,但各领域对应中文翻译也不尽相同。译者综合分析,决定将security翻译为安全性,safety翻译为稳定性。
    2. incremental cyber retrofit >> 渐进式模块化改造
      1. 内外网只能找到incremental retrofit这个词组,翻译为渐进式改造或增量改造
      2. incremental cyber retrofit 可以翻译为渐进式网格化改造,渐进式模块化改造?
      3. 最终译者决定翻译为渐进式模块化改造😁
    3. hypervisor与VMM
      1. hypervisor是虚拟化层
      2. VMM通过虚拟化层控制VM
    4. Capability 能力
      1. 参考https://gitee.com/laokz/sel4_reference_manual
    5. communication channels
      1. 交流通道

    摘要

    本白皮书对 seL4 进行了介绍。我们将解释 seL4 是什么 (以及不是什么),并探讨它的特性。我们将解释是什么使 seL4 有资格成为安全关键系统、通用嵌入式嵌入式和信息物理系统(Cyber-Physical System)所选择的操作系统内核。我们将解释 seL4 的安全故事(assurance story)、它的防盗和稳定(security and safety)相关特性以及它的基准性能。我们还讨论了典型的使用案例和已有系统的渐进式改造案例。

    1 seL4 概述

    seL4是微内核。

    操作系统 (OS) 是一种控制计算机系统资源并提供安全性的底层系统软件。与用户态程序不同, OS 可以使用 CPU 的特权模式(kernel mode),这意味着 OS 可以直接访问硬件。而用户态程序只能使用用户模式(user mode),仅可以访问 OS 允许它访问的的硬件。

    操作系统微内核是操作系统的最小化内核,它将高权限代码的数量降到最少。seL4 是 L4 微内核家族 的成员,这个家族可追溯到 90 年代中期. (seL4 和 seLinux没有任何关系)

    seL4 是虚拟机管理器

    seL4 支持运行客户操作系统 (如 Linux)。seL4 的交流通道(communication channels)使客户机和它的应用程序可以彼此通信,本地程序也一样(as well as with native applications. )。

    在第二章中了解更多关于 seL4 微内核的信息及其作为虚拟机管理器的使用方法。在第七章中了解真实世界的部署场景和现有系统改造方法。

    seL4 的正确性验证

    seL4提供了一个正式的、数学的、机器检查的形式化验证,这意味着就其规范而言,内核很大程度上上是“没有bug的”。事实上, seL4 是世界上第一个经过形式化验证系统1

    seL4 是安全的

    除了实现上的正确性之外,seL4还进一步提供了安全性验证2。在一个正确配置的sel4系统中,内核保证了机密性、完整性和可用性等经典的安全属性。关于这些证明的更多内容在第三章。

    seL4通过能力进行安全高效的访问控制

    能力是访问令牌,它可以对哪个实体可以访问系统中的特定资源进行非常细粒度的控制。他们根据最低特权原则(也称为最低权威原则,POLA)设计,提供强大的防盗能力。这是高安全系统的核心设计原则,在主流系统(如Linux或Windows)中是不可能实现访问控制的。

    seL4 可作为稳定性硬实时操作系统

    seL4是世界上唯一一个对最坏情况执行时间(WCET)进行了完整和合理分析的内核(至少在开放文献中)34。这意味着,如果正确配置了内核,所有的内核操作在固定时间内完成,这是构建硬实时系统的先决条件。在硬实时系统中,如果不能在严格限定的时间内对事件作出反应,后果将是灾难性的。

    seL4是最先进的混合关键系统

    它为混合关键实时系统(MCS)提供了强大的支持。在这些系统中,关键活动与在同一平台上执行的不可信代码共存,要确保关键活动的时效性。一些成熟的MCS操作系统使用严格分区的时间和空间资源管理,seL4则通过更灵活的资源管理提高了利用率5。更多关于seL4的实时性和MCS特性见第5章。

    seL4是最快的微内核

    一般来说,速度和安全二者不可兼得,seL4的独特之处在于它全都要。seL4支持广泛的现实世界用例。无论安全性多重要重要,卓越的性能都是必需的。关于seL4性能的更多信息见第6章。

    seL4 发音 “s-e-l-four”

    sell four这个发音弃用了,现在直接读字母即可。

    2 没有IPC的虚拟机管理器不是好的微内核

    宏内核VS微内核

    主流操作系统(如Linux)和微内核(如seL4)之间的区别见图2.1。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kdtIorGn-1635304626728)(https://i.loli.net/2021/05/21/lLrjHg8qmOPIaGX.png)]

    左边是Linux的架构图。黄色的部分是操作系统内核,它为应用程序提供文件存储和网络等服务。所有实现这些服务的代码都在CPU的特权模式下执行,也称为内核模式或管理模式,即对系统中所有资源的无限制访问和控制的执行模式。相反,应用程序以非特权或用户模式运行,对硬件的访问受到限制,受限的资源必须通过操作系统访问。操作系统内部结构为许多层,其中每一层提供由下面的层实现的抽象(The OS is internally structured in a number of layers, where each layer provides abstractions implemented by layers below. 看不懂这句话)。

    特权模式代码的问题在于它很危险:如果这里出了什么问题,就没什么阻止破坏的办法了。特别是如果特权模式代码有一个漏洞,攻击者可以利用该漏洞以特权模式运行非法代码(称为特权升级或任意代码执行攻击),那么攻击者可以对系统为所欲为。这些缺陷是主流系统中都有的。

    当然,软件错误是现实存在的,操作系统也不例外。Linux内核由2000万行源代码组成(20 MSLOC);可以估计它包含成千上万的bug 6。这显然是一个巨大的攻击面!Linux有一个很大的可信计算基础(TCB),这个技术是整个系统的子集,整个系统的安全运行依赖于TCB。

    微内核设计背后的理念是大幅缩小TCB,从而减少攻击面。如图2.1右侧所示,仅有很小一部分处于特权模式。seL4有一万行源代码(10 kSLOC),比Linux内核小了三个数量级,攻击面也相应地缩小了(可能更小,因为bug的密度可能随代码大小线性增长)。

    很明显,不可能在如此小的代码库中提供与Linux相同的功能。事实上,微内核几乎不提供任何服务:它只是对硬件的一个薄薄的包装,仅仅足够安全地复用硬件资源。微内核主要提供的是隔离,即一个程序可以在不受其他程序干扰的情况下执行的沙箱。同时它提供了一种受保护的过程调用机制(出于历史原因,称为IPC)。这允许程序安全地调用另一个程序中的函数。微内核在程序之间传输函数的输入输出并控制接口使用权:函数只能在一个导出的入口点被调用,并且只能被授权的客户端调用(第4章)。

    关于seL4 IPC怎么用,建议阅读博客

    https://microkerneldude.wordpress.com/2019/03/07/how-to-and-how-not-to-use-sel4-ipc/

    微内核系统使用IPC来提供宏内核在内核态中实现的服务。在微内核世界中,这些服务只是程序,与应用程序没有区别,它们运行在自己的沙箱中,并为应用程序调用提供IPC接口。应用的故障将局限在沙箱内,系统的其余组件则不受影响(译注:指其余组件的安全性不受影响,但其余组件都无法继续使用故障组件提供的服务了)。这与宏内核形成了鲜明的对比,在宏内核系统中,内核故障将导致整个系统不可用。

    译注:我觉得作者主要想说微内核可以将不可挽回的故障限制在某用户进程,内核和其他进程不受影响;而宏内核的内核一旦故障,运行其上的所有软件就都不可用了。

    这种影响可以被量化:我们最近的研究表明,在Linux中所出现的严重问题,29%将被微内核设计完全消除,另外55%将被大大减轻,不再被列为关键问题7

    seL4是微内核,不是OS

    seL4是一个微内核,设计的目的是确保通用性同时最小化TCB。它是L4微内核家族的成员,可以追溯到90年代中期;图2.2显示了seL4的起源。它是由我们在UNSW/NICTA的团队开发的,最近一段时间被称为可信系统(TS)。当时,我们在开发高性能微内核方面有15年的经验,并有实际部署的跟踪记录:我们的OKL4微内核搭载在数十亿高通蜂窝调制解调器芯片上,我们的L4 -嵌入式内核从10年代中期就在所有iOS设备的安全协处理器(secure enclave)上运行。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-iHl7gqHC-1635304626731)(https://i.loli.net/2021/05/21/JDdEmiT4YNtQush.png)]

    作为一个微内核,seL4不包含任何常见的操作系统服务;这些服务是由运行在用户模式下的程序提供的。这是微内核设计缺陷之一:正常运行总需要很多组件。可以从开源操作系统(如FreeBSD或Linux)移植,也可以从头开始编写。但无论如何,编写组件是一项重要的工作。

    为了扩大规模组件规模,我们需要社区的帮助,而seL4 Foundation是使社区能够为基于seL4的系统合作、开发或移植此类服务的关键机制。其中最重要的是设备驱动程序、网络协议栈和文件系统。我们有相当数量的此类组件,但还需要更多。

    的组件开发来说,组件框架很重要,它允许开发人员专注于实现服务本身,不必关注seL4的某些细节。seL4目前有两个主要的开源组件框架:CAmkES和Genode。

    CAmkES是一个针对嵌入式和信息物理系统的框架,这些系统通常是静态架构,这意味着它们由一组定义好的组件组成,一旦系统完全启动,这些组件就不会改变。

    Genode在很多方面都是一个更强大、更通用的框架,它支持多个微内核,并且已经提供了大量的服务和设备驱动程序,特别是针对x86平台。它比CAmkES更方便,而且肯定是快速建立复杂系统的方法。然而Genode也有缺点:

    1. 由于Genode支持多个微内核(并非所有微内核都像seL4那样强大),因此它的功能是所有微内核种类的共同子集。它不能使用所有的seL4的安全和安全特性。
    2. 它没有可靠的故事(assurance story)。关于这一点,参见3.2节。

    seL4是虚拟机管理器

    seL4是一个微内核,但它也是一个管理程序:可以在seL4上运行虚拟机,如Linux。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-RguoLFRr-1635304626733)(https://i.loli.net/2021/05/22/IuRgJkjhWfeXvVt.png)]

    这提供了另一种提供系统服务的方法,即让Linux VM提供系统服务。这样的设置如图2.3所示,其中显示了一些服务如何从多个Linux实例中借用,这些实例作为客户机运行。

    在本例中,我们提供两种系统服务:网络和存储。

    网络是由直接运行在seL4上的本机协议栈提供的,lwIP或PicoTCP是常用的栈。我们没有移植网络驱动程序,而是借用Linux的一个驱动程序,这个精简的Linux客户机只有一个网卡驱动程序。协议栈通过sel4提供的通道与Linux通信,应用程序同样通过与协议栈通信获得网络服务。注意,在图中显示的设置中,应用程序没有到网卡驱动虚拟机的通道,因此不能直接与它通信:这是通过基于seL4能力而实现的(见第4章)

    存储服务与此类似;文件系统是Linux虚拟机提供的,而存储驱动程序则是本地的。同样,组件之间的通信也是受通道限制的,应用程序不能直接与存储驱动程序通信,两个Linux虚拟机不能相互通信。

    当用作虚拟机管理器时,seL4以特权模式运行(Arm上的EL2, x86上的Root Ring-0, RISC-V上的HS),这是比客户机更高的特权级别。seL4只在特权模式执行作为虚拟机管理器所进行的少量工作工作,其余的工作都留给用户模式。

    具体来说,这意味着seL4负责“世界切换”,当虚拟机的执行时间到期时,或者由于某些其他原因必须切出时,seL将进行状态切换操作。它还捕获虚拟化异常(Intel虚拟化架构中术语是VM exits ),并将它们转发给一个用户级处理程序,称为虚拟机监视器(VMM)。然后,VMM负责执行模拟操作。

    每个VM都一个VMM,VMM与客户操作系统以及其他VM相互隔离,如图2.4所示。这意味着VMM不能打破隔离,因此并不比客户操作系统本身更可信。特别是,这意味着不需要验证VMM,因为只要不验证来宾操作系统(通常是Linux),就不会增加真正的安全性。

    image-20210522165820444

    译注:

    由该小节可见,在seL4中,VM包含GuestOS与GuestApps,VMM可与VM交流但不能与GuestOS交流。

    那么问题来了,VM在seL4中是一个实体还是一个由GuestOS和GuestApps组成的虚拟概念?

    另外,VMM和Hypervisor要怎么在中文里进行区分?

    seL4不是seLinux

    许多人会搞混 seL4 和 seLinux (或许他们以为 seL4 是第 4 代 seLinux;译注:也可能因为 seL(inux) 缩写,就像 K8S). 事实上除了都开源, seL4 跟 seLinux 没有任何关系。他们在代码或概念上没有任何交集。 seLinux 不是微内核,它是 Linux 内置的安全框架。虽然比标准 Linux 更安全,但 seLinux 和标准 Linux 面对相同的问题:巨大 TCB 和相当大的攻击面。换句话说,seLinux 是一个根本不安全的操作系统的组件,因此仍然是根
    本不安全的。相比之下, seL4 提供了武装到牙齿的隔离。

    简而言之, seLinux 并不适合安全要求严格的情景,而 seL4 就是为这些用途而设计的。

    3 验证过程(Verification Story)

    2009年,seL4成为世界上第一个在源代码级别上经过机器证明功能正确性(machine-checked functional
    correctness proof)的操作系统内核。当时由20万行证明脚本,是有史以来最大的(我们认为它是第二大)。以前人们以为不会有功能正确(functionally correct)的OS内核,我们证明它是存在的。

    从那时起,我们将验证的范围进行了扩展,图3.1显示了证明链,下面将对此进行解释。重要的是,我们在内核不断发展的过程中一直保持这个验证措施:只有在不破坏证明的情况下,才允许提交到主线内核源代码,否则我们就更新证明代码(otherwise the poofs are updated as well)。这种证明工程是一种新事物。我们的seL4证明构成了迄今为止最大的还在维护的证明集(proof base)。到目前为止,证明脚本已经超过了100万行,其中大部分是手工编写然后用机器检查的(manually written and then machine checked)。

    image-20210522173600570

    正确性和安全性

    功能正确(Functional correctness)

    seL4验证的核心是功能正确性证明,要确保C代码没有缺陷。更准确地说,内核的功能有一个正式的规范,用一种称为高阶逻辑(high-order logic, HOL)的数学语言表示。这由图中写着“abstract model”的方框表示。C实现是抽象模型的具体化,这意味着C代码的可能行为是抽象模型允许的行为的子集。

    C语言不是形式化语言;为了允许在定理证明器中对C程序进行推理(我们使用Isabelle/HOL),必须将其转换为数学逻辑(HOL)。这是由一个用Isabelle编写的C解析器完成的。解析器定义了C程序的语义,并根据这个语义形成HOL。这种形式化是数学(抽象)模型的改进(It is this formalisation which we prove to be a refinement of the mathematical (abstract) model)。

    请注意,C语言没有正式的数学语义,而且C语言的某些部分是出了名的微妙,并没有定义得很好。我们通过将C的限制在该语言的一个定义良好的子集内来解决这个问题,对于这个子集我们有一个明确的语义。然而,这并不能保证我们为该子集假定的语义与编译器相同。下面将详细介绍。

    我们想让内核的行为与规范一致,不允许出现于规范不同的行为。这就避免了通常用来攻击操作系统的操作,如栈溢出、空指针引用、代码注入或控制流劫持等。

    编译验证(Translation validation)

    一个没有bug的C内核是很棒的,但是我们仍然受制于C编译器。这些编译器(我们使用GCC)本身就是有bug的大型程序。我们那完美的代码很有可能被编译成有bug的二进制文件。

    编译器出bug还是小事,就怕编译器使坏,包含一个木马程序,在编译操作系统时构建后门。木马也可以入侵用来编译编译器的编译器,这样我们想自己编译编译器也没法避免木马。Ken Thompson在他的图灵奖演讲中解释了这一攻击8

    为了防止有缺陷的或恶意的编译器,我们另外验证由编译器和链接器生成的可执行二进制文件。具体来说,我们证明了二进制代码是C代码的正确翻译,因此二进制代码也符合抽象规范。

    译注:

    这部分过于学术化,基础知识见SAT与SMT

    这张图的意思大概是把C代码和编译后的二进制都转化为数学描述,看这两种数学描述功能是否相同。

    image-20210522191457714

    与C代码的验证不同,这个证明脚本不是手写的,而是通过一个自动工具链完成的。它由几个阶段组成,如图3.2所示。在定理证明器中,处理器指令集(ISA)的形式化模型形式化了二进制;我们使用了RISC-V ISA的L3形式化和广泛测试的L3 Arm ISA形式化9

    然后,一个用HOL4定理证明程序编写的反汇编程序将这种低级表示转换为控制流的图语言表示。这个变换被证明是正确的。

    通过Isabelle/HOL定理证明器中可证明正确的变换,将形式化的C程序转换为相同的图形语言。然后我们得到了同一个程序的不同表示,我们需要表明它们是等价的。这有点棘手,因为编译器对代码进行了优化。We apply a number of such transformations through rewrite rules on the graph-language representation of the C program (still in the theorem prover, and thus provably correct).

    最后,我们得到了两个非常相似但不相同的程序,我们需要证明它们有相同的语义。从理论上讲,这相当于停机问题 (halting problem),因此是无法解决的。在实践中,编译器所做的事情是确定的,这使问题易于处理。我们通过将程序分成小块扔给多个SMT解决程序来解决这个问题。如果其中一个可以证明所有对应的部分具有相同的语义,那么我们就知道这两个程序是等价的。

    还需要注意的是,被证明符合形式化规范的C代码和二进制文件都具有相同的Isabelle/HOL形式。这意味着我们对C语义的假设脱离了证明所做的假设(This means that our assumptions on C semantics drop out of the assumptions made by the proofs.)。总之,这些证明不仅表明编译器没有引入bug,还证明其C子集的语义和我们定义的语义相同。

    安全属性

    图3.1还显示了抽象规范和高级安全属性(机密性、完整性和可用性)(这些通常被称为CIA属性)之间的证明。抽象规范实际上对安全很有用:在一个正确配置的系统中,内核将强制执行这些属性。

    1. 保密性:必须显式地给予数据读权限,seL4才允许实体读取数据
    2. 完整性:seL4不允许一个实体在没有被显式给予数据写权限的情况下修改数据
    3. 可用性:seL4不允许一个实体阻止另一个实体使用已授权的资源

    译:关于安全验证的补充说明,实在不会翻译了。

    These proofs presently do not capture properties associated with time. Our confidentiality proofs rule out covert storage channels but presently not covert timing channels, which are used by such attacks as Spectre. Preventing timing channels is something we are working on [Heiser et al., 2019]. Similarly, the integrity and availability proofs presently do not cover timeliness, but our new MCS model [Lyons et al., 2018] is designed to cover those aspects (see Section 5.2).

    证明假设

    所有关于正确性的推理都基于假设,无论是正式的推理(如seL4),还是非正式的推理(当有人思考为什么他们的程序可能是正确的)。每个程序都在某个上下文中执行,它的正确行为不可避免地依赖于对这个上下文中的一些假设。

    机器检查形式推理的优点之一是,它迫使人们明确地做出这些假设。不可能做出未声明的假设,如果证据依赖于没有明确声明的假设,那么它们就不会成功。从这个意义上说,形式推理可以防止忘记假设,或者不清楚假设;这本身就是核查的一大好处。

    对seL4的验证有三个假设:

    1. **硬件按预期运行。**这应该是显而易见的。内核受底层硬件的支配,如果硬件有bug(或者更糟,有木马),那么无论您运行的是经过验证的seL4还是任何未经验证的操作系统,都将失败。硬件验证超出了seL4的范围(以及TS的能力);其他人有研究这个的。

    2. **规范是正确的。**这是一个困难的问题,因为没人知道现在的规范是否完美。当然,有总比没有强。
      可以通过证明有关规范的属性来降低这种风险,正如我们在安全性证明中所做的那样,安全性证明表明seL4能够强制执行某些安全性属性。这就把问题转移到了这些属性的说明上。它们比内核规范简单得多,减少了误解的风险。
      但数学和物理之间总是存在着鸿沟,任何推理都无法完全消除这一点。形式推理的好处是,你确切地知道差距是什么

    3. **定理证明器是正确的。**这听起来像是一个严重的问题,因为定理证明本身就是一个庞大而复杂的程序。然而,在现实中,这是三个假设中最不值得关注的。因为Isabelle/HOL定理证明器有一个小核心(10 kSLOC),用来检查所有与逻辑公理相悖的证明。这个核心已经从广泛的形式推理领域中检查了许多大大小小的证明,所以它包含正确性关键错误的可能性是非常小的。

      译注:我觉得这种套娃证明无穷尽的思想就是古欧洲哲学的精髓了;与我国天人合一的哲学明显不同。

    证明进度

    seL4已经或正在被多个架构验证:Arm、x86和RISC-V。他们的验证进度各不相同,有的正在研究,有的就是缺钱搞。详情请参考seL4项目状态页面

    CAmkES组件框架

    CAmkES is a component framework that allows you to reason about a system architecturally, i.e. as a collection of sandboxed components with defined communication channels. Figure 3.3 shows the main abstractions.

    不会翻译

    组件用方框表示。它们表示由seL4封装的程序、代码和数据。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pseUjkf0-1635304626737)(https://i.loli.net/2021/05/21/T9RBGFlIVgOqvD7.png)]

    接口定义了如何调用一个组件,或者如何调用其他组件。接口要么被导入(调用另一个组件的接口),要么被导出(能够被另一个导入的组件的接口调用),共享内存接口除外,它是对称的。

    连接器将同类型的输入输出接口连接起来。CAmkES中的连接器总是一对一的。但是通过添加将单输入复制成多输出的组件实现广播或多播功能。

    CAmkES系统是用一种正式的体系结构描述语言(CAmkES ADL)指定的,它包含对组件、它们的接口和连接它们的连接器的精确描述。CAmkES对系统设计者的承诺是,ADL中指定的(如图3.3所示)就是可能产生的交互。特别地,它承诺除了图中所示的交互之外,没有其他交互的可能。

    image-20210521222054735

    当然,这个承诺依赖于seL4,ADL表示必须映射到低级seL4对象和对它们的访问权限。这就是CAmkES机制所实现的,如图3.4所示。

    在图的顶部展示了ADL中所描述的结构。这是一个相当简单的系统,由4个本机组件和一个包含两个驱动的虚拟机组件。Linux虚拟机只能通过crypto组件连接到其他组件,这就保证了虚拟机只能访问加密的链接,不会泄露数据。

    即使是这个简单的系统也会映射成百上千各seL4对象,CAmkES为我们降低了开发复杂度。

    对于sel4级的描述,我们有另一种正式的语言,称为CapDL(能力分配语言)。系统设计者永远不需要处理CapDL,它是一个纯粹的内部表示。CAmkES框架包含一个编译器,它自动将CAmkES ADL转换为CapDL,由左向下的方框箭头表示。图左侧的框给出了CapDL中描述的seL4对象的简化表示。

    CapDL规范是系统中访问权限的精确表示,也是seL4强制执行的。这意味着一旦系统进入CapDL规范描述的状态,它就保证按照CAmkES ADL规范描述的行为,因此体系结构级别的描述足以进一步推理安全属性(therefore the architecture-level description is sufficient for further reasoning about security properties. )。

    因此,我们需要确保系统启动到CapDL规范所描述的状态。我们通过第二个箭头实现了这一点:我们从CapDL生成启动代码,一旦seL4自身启动,就控制并生成规范引用的所有seL4对象,包括描述活动组件的对象,在初始化代码执行的最后,可以证明系统处于CapDL规范所描述的状态,因此也处于ADL规范所表示的状态。

    第三个箭头表示从ADL规范生成的组件之间的胶水代码。通过连接器发送数据需要调用seL4系统调用,这些系统调用的细节被CAmkES隐藏。胶水代码使用了这些系统调用。例如,RPC连接器将一个远程过程调用封装成了普通函数调用。

    在撰写本文时,关于CAmkES和CapDL的证明还没有完成,但离完成很近了。

    还请注意,所提到的验证工作都没有处理定时通道造成的的信息泄漏。这是一个尚未解决的重大问题,但我们就快搞定了。

    4 能力

    我们在第一章中遇到了一些功能,注意到它们是访问令牌。现在我们将更详细地研究这个概念。

    什么是能力

    image-20210521222538350

    如图4.1所示,一个能力是一个对象引用;它类似于指针(能力的实现通常称为胖指针)。能力是不可变的指针,指向内核中对应权限类型的对象。

    除了指针之外,能力还对访问权限进行编码。在基于功能的系统(如seL4)中,调用功能是对系统对象执行操作的唯一方法。

    例如,一个操作可能是调用组件中的函数。嵌在该功能中的对象引用指向该对象的接口,并表达调用该函数的权利。(The capability may or may not at the same time convey the right to pass another capability along as a function argument (delegating to the component the right to use the object referenced by the capability argument) )

    这是CAmkES抽象级别的高级描述。事实上,在CAmkES里,能力本身被封装了。

    在底层,连接器由端点对象表示,客户端组件需要具有调用权限的能力。

    正是这种细粒度的、面向对象的特性使得能力成为面向安全系统的访问控制机制。最小化每个组件的能力,这是最低特权原则所要求的。

    请注意,能力的这个概念与Linux所称的能力强大得多,后者实际上是具有系统调用粒度的访问控制列表(acl)。与所有ACL模式一样,Linux功能也存在令人困惑的问题,这是许多安全漏洞的根源,下一节将对此进行解释。seL4的能力没有这个问题。

    seL4能力也不容易受到该引文10中描述的攻击;这种攻击适用于直接在硬件中实现的功能,而seL4的能力由内核实现。

    有10种类型的seL4对象,它们都由能力引用:

    **端点Endpoints **用于执行受保护的函数调用

    **应答对象Reply Objects **表示来自受保护过程调用的返回路径

    **地址空间Address Spaces **提供了沙箱(硬件页表的封装)

    **节点Cnodes **存储表示组件访问权限的能力

    **线程控制块Thread Control Blocks **表示线程

    **调度上下文Scheduling Contexts **表示在处理器上使用一个时间片的权利

    **通知Notifications **是同步对象(类似于信号量)

    **帧Frames **表示可以映射到地址空间的物理内存

    **中断对象Interrupt objects **提供对中断处理的访问

    空类型Untypes未使用的(自由的)物理内存,可以转换为任何其他类型

    为什么要使用能力

    细粒度访问控制

    能力提供细粒度的访问控制,符合最小权限安全原则(也称为最小权限原则POLA)。这与访问控制列表(acl)这种更传统的访问控制模型形成了对比,后者在主流系统(如Linux或Windows)中使用,但也在商业系统(如INTEGRITY或PikeOS)中使用。

    要理解其区别,首先看访问控制在Linux中是如何工作的:文件(文件访问权限控制具有代表性)具有一组访问模式位。其中一组位决定了它的所有者可以对文件执行什么操作,另一组位代表了用户组中每个成员允许的操作,最后的一组位是授予其他人的默认权限。这是一个面向用户的方案,以用户身份区分权限。用户对权限设置相同的文件享有相同权限。

    这是一种非常粗粒度的访问控制形式。一个典型的场景是,用户希望用一个不受信任的程序(比如从互联网上下载)处理一个特定的文件,但希望阻止该程序访问该用户的其他文件。在Linux中没有优雅的方法来做到这一点,人们想出了一些笨重的解决方案,比如chroot,容器等。

    有了能力,这个问题很容易解决,因为能力提供了面向对象的访问控制形式。具体来说,当且仅当请求操作的程序拥有对应能力时,内核才会允许操作继续进行。在限制场景中,不受信任的应用程序只能访问被赋予权限的文件。因此Alice调用程序,将一个能力交给程序允许读取的一个文件,再加上一个能力让他可以把输出内容写到另一个文件里,这个程序不能访问任何其他事物——这就是最小权限。

    中介与授权Interposition and delegation

    能力还有很多特性。一个是中介访问的能力,这是不透明对象引用的结果。如果Alice被赋予了一个对象的能力,她不知道这个对象到底是什么,她所能做的就是调用对象上的方法。

    例如,系统设计者可能假装给Alice的能力指向一个文件,而实际上它指向一个通往安全监视器的通道,安全监视器持有实际能力。监视器可以检查Alice请求的操作,如果合法Alice执行文件操作,不合法则忽略请求。监视器有效地虚拟化了文件。

    中介不仅仅可以用来做安全检查;该方法可用于包过滤、信息流跟踪等。调试器可以透明地插入和虚拟化对象调用。它甚至可以懒加载一个对象:Alice调用该对象时,对象才会被创建。

    能力的另一个优点是,它们支持安全有效的权限授权。如果Alice想让Bob访问她的一个对象,她可以为该对象创建(在seL4中叫mint)一个新能力,并将其交给Bob。然后Bob就可以使用该能力来操作对象,而不需要还给Alice。(相反,如果Alice想要保持对这个过程的控制,它可以使用上一段讲的中介技术。)

    新能力的权利可能会减少;Alice可以只给Bob只读权限。Alice可以在任何时候撤销Bob的访问权,方法是摧毁她交给Bob的派生能力。

    授权功能很强大并且在ACL系统中无法轻松且安全地完成。一个典型使用授权的例子是设置自主管理资源的子系统。当系统启动时,初始进程拥有对系统中所有资源的权限(除了内核本身使用的少量且固定的资源)。然后,这个初始资源管理器可以通过创建新的进程(子资源管理器),并赋予他们互不相交的权限,来分割出不同子系统。

    然后子系统可以自主地(不参考原始管理器)控制它们的资源子集,同时不相互干扰。只有当他们想要改变原始资源分配时才需要访问初始管理器。

    周围权限和困惑的副手

    image-20210523001305605

    acl有一个无法解决的问题,通常称为混淆代理。让我们来看一个C编译器。它接受一个C源文件并产生一个输出文件,文件名作为参数传递。要运行编译器,用户Alice必须对编译器具有执行权限,如图4.2所示。

    假设编译器还在系统级日志文件中创建了一个用于审计目的的条目。日志文件对普通用户是不可访问的,因此编译器必须以提升的权限执行,以便写入日志文件(传统上通过将其设置为setuid程序来完成)。

    如果Alice是恶意的,她可以欺骗编译器去做它不应该做的事情。例如,Alice可以在调用编译器时指定密码文件作为输出文件。除非编译器非常小心地编写以避免任何潜在的滥用,否则它将只打开输出文件(密码文件),并使用已编译的目标代码覆盖它。Alice编写一个程序,使新生成的密码文件赋予她不应该拥有的特权,这并不需要很多技巧。

    这里的基本问题是,当编译器打开它的输出文件进行写入时,操作系统通过查看编译器的用户ID来确定访问的有效性,以确定它是否有访问该对象的权限。由编译器决定操作是否有效,使编译器成为系统TCB的一部分,这意味着必须完全信任它,以便在所有情况下做正确的事情。

    ACL系统可以采用一些防御措施来减轻特定的问题,例如,确保密码文件和日志文件在不同安全域(这不会阻止爱丽丝痛击日志文件)。这就导致了通常的攻击和防御的军备竞赛。

    这种混淆是由环境权限(ambient authority)引起的:操作的有效性由代理(编译器)的安全状态决定,在本例中代理是代表Alice。为了适当的安全性,访问必须由Alice的安全状态决定。这意味着命名(对文件的引用)和权限(对文件执行操作的权利)必须耦合在一起,这一原则称为没有权限就不指定。如果是这种情况,那么编译器将使用指定的权限(来自Alice)调用指定的对象(输出文件),这样Alice就不会再混淆代理了。

    这正是能力系统所做的。在这样的系统中,Alice需要拥有三种能力:执行编译器的能力、读输入文件的能力和写输出文件的写能力。她使用执行能力调用编译器,并将另外两个能力作为参数传递。然后,当编译器打开输出文件时,它使用Alice提供的能力进行操作。编译器使用一个独立的能力来打开日志文件,使日志和编译输出分开。特别是,Alice不可能欺骗编译器写入一个她自己无法访问的文件。

    解决“困惑的副手问题”是能力的杀手级应用,因为这个问题无法用acl解决。因此,下次有人试图向你出售一个安全的操作系统时,不仅要问他们是否有操作系统的正确性证明,还要问它是否使用了基于能力的访问控制。如果这两个问题的答案都是否定的,那么你就得到了假货(原文snake oil 蛇油指假的万金油)。

    5 支持硬实时系统

    seL4被设计为一个保护模式的实时操作系统。这意味着,与经典的RTOSes不同,seL4结合了实时能力和内存保护,以确保安全性,并部分支持混合关键系统。

    一般实时支持

    seL4有一个简单的、基于优先级的调度策略,易于理解和分析,这是硬实时系统的核心需求。内核将自己永远不会调整优先级,因此用户是控制者。

    另一个需求是有限中断延迟。与L4微内核家族的大多数成员一样,seL4在内核模式下执行时禁用中断。这个设计决策极大地简化了内核的设计和实现,因为内核(在一个单核处理器上)不需要并发控制。否则,seL4的正式验证是不可行的,但该设计也使优异的平均情况性能成为可能。

    人们普遍认为,为了保持较低的中断延迟,实时操作系统必须是可抢占的(除了短的临界部分)。虽然对于在简单微控制器上运行的传统非保护模式RTOSes是正确的,但在保护模式系统上并不对,如seL4。因为当运行在一个启用了内存保护的强大微处理器上时,进入内核、切换上下文和退出内核的时间非常长,不比seL4系统调用少多少。就中断延迟而言,可抢占设计几乎没有什么好处,但复杂性方面的成本将非常高,使得可抢占设计不合理。

    只要所有系统调用都很短就行。在seL4中系统调用都很短,但也有例外。特别是撤销一个能力可能是一个耗时的操作。seL4处理这种情况的方法是将这些操作拆分为短的子操作,使他可以被中断,被打断的操作可以在中断完成后接着执行。

    这种方法被称为增量一致性。每个子操作将内核从一个一致状态转换为另一个一致状态。该操作的结构是这样的:在中止之后,可以重新启动该操作,而无需重复中止之前成功的子操作。内核在每个子操作之后检查挂起的中断。如果有,它将中止当前操作,此时中断将强制重新进入内核,由内核处理中断。当完成时,原始系统调用将重新启动,然后从它被中止的地方继续执行,以确保进展。

    我们对seL4进行了完整而合理的最坏情况执行时间(WCET)分析,这是唯一有记录的保护模式OS的最坏情况执行时间分析1112。这意味着我们已经得到了所有系统调用延迟的可证明的硬上界,以及最坏情况下的中断延迟。

    这种WCET分析是支持硬实时系统的先决条件,也是使seL4在竞争中脱颖而出的特性。虽然已经对不受保护的RTOSes进行了完整和可靠的WCET分析,但保护模式系统的行业标准方法是将内核置于高负载下,测量延迟,采用观察到的最坏的延迟,并添加一个安全系数。不能保证这种方法得到的界是安全的,而且它不适合安全关键系统(safety-critical systems)。

    我们为Arm v6处理器做了seL4的WCET分析。由于Arm不再提供指令的最坏情况延迟所需的信息,而英特尔也从未为其架构提供这些信息,该系统从此陷入停顿。然而,随着开源RISC-V处理器的出现,我们将能够重新进行这一分析。

    5.2 混合关键系统

    什么是混合关键系统

    关键是一个来自安全领域的术语,与组件故障的严重程度有关。例如,航空电子标准对故障进行了分类,从对车辆安全没有影响到灾难性故障(造成人员伤亡)。组件越关键,所需的保证就越广泛(也越昂贵),因此有强烈的动机保持低关键(there is a strong incentive for keeping criticalities low. )。

    混合关键系统(MCS)由不同关键的组分(相互作用)组成。它的核心安全要求是一个组件的故障不能影响到任何更关键的组件,从而确保关键组件独立于不那么关键的组件

    传统上,关键系统的每个功能都使用专用的微控制器,即电气隔离。随着功能的增长,这种方法导致处理器(及其封装和布线)的激增,从而导致空间、重量和功率(SWaP)问题,而这正是MCS的目标。

    这类似于在同一个系统中同时拥有受信任和不受信任组件的组件,在这两种情况下,操作系统的核心需求都是强隔离。安全领域的挑战在于,安全性不仅依赖于功能正确性,还依赖于及时性:关键组件通常有实时需求,这意味着它们必须在截止时间前对事件做出响应。

    传统MCS

    传统的MCS操作系统完全隔离部件的时间和空间,一种称为严格时间和空间划分(TSP)的方法,以ARINC 653航空电子标准ARINC13为例。这意味着每个组件被静态地分配一个固定的内存区域,并且分区根据预先确定的调度顺序和固定的时间片执行。

    TSP方法保证隔离,但有严重的缺点。最明显的一个是资源利用不足。每个实时组件必须能够在它的时间片内完成它的工作,所以时间片必须至少是组件的最坏情况执行时间。组件的WCET可以比通常的执行时间大几个数量级,因为它必须考虑到异常情况。

    此外,确定WCET的安全边界通常是棘手的。对于关键组件,必须非常保守地说服持怀疑态度的认证机构,这通常会导致估值较大。这意味着处理器通常没有得到充分利用。但是,由于严格的分区,空闲时间不能被其他组件使用,因此利用率不佳是一个固有的问题。基本上,通过保留间隙实现强隔离,TSP资源使用率较差。

    TSP的另一个大缺点是中断延迟本身就很高。以图5.1为例,它可能表示一个(高度简化的)自动驾驶汽车。关键部件是一个控制回路,它每5毫秒执行一次,处理传感器数据并向执行器发送命令。它的WCET,也就是时间片,是3毫秒。车辆还与一个地面站通信,它可以更新路径点。因为系统以5毫秒的时间运行,这是可以处理网络中断的延迟时间,极大地限制了网络吞吐量和对外部事件的响应能力。

    image-20210522102253001

    seL4的MCS

    MCS的核心挑战是操作系统必须提供强大的资源隔离,但是TSP过于简单(因此不灵活)。就空间资源而言,seL4已经有了一个灵活、强大且可证明安全的模型:对象能力(见第4章)。接下来讨论时间资源:对处理器的访问也由能力控制。

    用于处理器时间的seL4能力称为调度上下文能力。组件只有在拥有这样的能力时才能获得处理器时间,并且它可以使用的处理器时间量被编码在该能力中。这类似于空间对象的访问权限的工作方式。

    在传统的seL4中(就像在它之前的大多数L4内核中一样),线程有两个主要的调度参数:优先级和时间片,它们决定对处理器的访问。

    优先级决定了线程何时可以执行,如果没有更高优先级的可运行线程,它可以运行。时间片决定内核在抢占线程之前允许线程运行多长时间(除非它在被一个更高优先级的线程成为可运行线程之前被抢占)。当时间片耗尽时,调度器将再次选择优先级最高的可运行线程(可能是刚刚被抢占的线程),并在优先级级别中使用循环策略。

    seL4的MCS版本将时间片替换为调度上下文对象的能力,该对象执行类似的功能,但以更精确的方式执行隔离:调度上下文包含两个主要属性。(1)时间预算,类似于旧的时间片,并限制线程可以执行的时间。(2)一个时间段,它决定了预算可以被使用的频率:无论优先级如何,在该时间段内他都会被分到自己时间预算那么长的处理器时间。

    调度上下文支持推理一个线程可以消耗多少时间,还有多少时间剩余。可用于防止高优先级线程独占处理器。

    应用于上面的例子,这意味着我们可以给(不太关键的)设备驱动程序一个比(关键的)控制组件更高的优先级。这允许驱动程序抢占控制,提高响应速度。但是时间预算将阻止驱动程序过度使用CPU。例如,我们给控制器一个3ms的预算(它的WCET)和一个5ms的周期(对应于它运行的频率)。我们给高优先级驱动3µs预算,周期为10µs,这意味着它在任何情况下都不能消耗超过总处理器时间的30%,但可以足够频繁地执行以确保良好的响应性。重要的是,我们可以保证控制器(它需要的可用处理器时间不超过60%)有足够的时间满足截止时间。

    通过不考虑驱动程序的行为而保证关键截止日期,将控制与不受信任的驱动程序隔离。特别是,驱动不需要被认证为安全关键。

    seL4的时间能力模型解决了MCS的许多其他挑战,超出了本白皮书的范围,有兴趣的读者可阅读这篇文章14。可以说,在所有关键操作系统中,seL4提供了最先进和最灵活的MCS支持。

    6 安全性能全都要

    性能一直是L4家族的标志,seL4也不例外。我们构建seL4是为了实际应用,我们的目标是相对于我们之前拥有的最快的内核而言,IPC性能损失不超过10%。结果是,seL4最终比这些内核还快。

    它的性能胜过任何其他微内核。这是一种很难证明的说法,因为竞争对手通常会将他们的性能数据保密(出于非常好的理由!)

    然而,我们会利用一切机会,公开宣布这一业绩。如果有人不同意,他们需要出示证据。我们还通过一些非正式渠道了解到,其他系统的IPC性能往往比seL4慢2倍到慢得多,通常大约是seL4的10倍。

    有几个独立的性能对比验证了我们的优越性。

    这篇文章15比较三个开源系统的性能,seL4, Fiasco.OC和Zircon 。它发现seL4 IPC成本比内核进入、地址空间切换和内核退出的硬件限制大约高出10% 20%。Fiasco.OC比seL4慢2倍以上(接近硬件极限的3倍),Zircon的速度几乎是seL4的9倍。

    这篇文章16比较了CertiKOS和seL4的性能,在CertiKOS中实现双向IPC花了3820个运行周期,而在seL4中花了1830个周期。然而,事实证明,sel4bench (seL4基准测试套件)在处理x86上的计时器时存在一个bug,导致了夸大的延迟。正确的seL4性能值大约是720个循环,比CertiKOS快5倍以上。另外CertiKOS提供特性非常有限,也没有基于能力的安全性。

    7 实际生产和渐进式改造

    一般情况

    当计划使用seL4的安全特性时,第一步应该是确定需要保护的关键资产。目标是将可信计算基础TCB最小化,并使其尽可能模块化,使每个模块都成为受sel4保护的CAmkES组件。

    另一个重要的准备工作是检查平台上seL4的可用性和验证状态。显然,seL4的卖点就是经过形式化验证。然而,即使在未验证的平台上,它也比其他操作系统更安全。但是要牢记,没有验证就没有完全的安全保证。如果您使用的内核没有为您的平台进行验证,或者您魔改了内核,那出了事您一定不要怪我们

    您还需要评估seL4的基础软件生态是否满足您的目的。如果不是,那么这就是社区可以帮助你的地方。有一些公司专门为seL4提供支持。此外,如果您自己开发了任何通常组件,您应该认真考虑在适当的开源许可下与社区共享它们。助人者人恒助之。

    改造现有系统

    在现实世界中,大多数seL4的部署都不会在本地(native)运行所有内容,有可能以虚拟机的方式运行在seL4上。通常,有一些重要的遗留组件移植起来会很昂贵,因为它们可能依赖目前seL4不支持服务。此外,通常情况下,本地运行这些遗留堆栈不会带来什么安全性或安全性收益。

    使用seL4的虚拟化能力通常是一种实用的方法,第2.3节给出了一些示例。

    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ob6NrEdy-1635304626741)(https://i.loli.net/2021/05/22/WdCq1MHYB9xwf5Q.png)]

    典型的方法是我们所谓的“渐进式改造”,这是当时DARPA项目主任约翰·朗奇伯里创造的术语。如图7.1所示,通常首先将整个现有软件堆栈放入在seL4上运行的虚拟机中。显然,这个步骤在安全性和安全性方面没有任何价值,它只增加了非常小的开销。它的重要意义在于,它提供了模块化的开端。

    一个很好的例子是我们的HACMS项目合作伙伴对波音ULB自动直升机进行的网络改造。最初的系统运行在Linux上,在第一步中,团队将seL4放在了下面。

    下一步出现了两个组件:特别不受信任的摄像头软件被转移到同样运行Linux的另一个虚拟机,两个Linux虚拟机通过CAmkES通道通信。同时,网络堆栈从VM中取出并转换为原生CAmkES组件,也与主VM通信。

    最后一步是将所有其他关键模块以及(不可信的)GPS软件放入单独的CAmkES组件中,移除原来的主VM。最后的系统由许多运行sel4本机代码的CAmkES组件和一个只运行Linux和摄像软件的单个VM组成。

    结果是,虽然最初的系统很容易被DARPA雇佣的专业渗透测试人员侵入,但最终状态是高度弹性的。攻击者可以破坏Linux系统并对其为所欲为,但无法突破并破坏系统的其他部分。这个团队有足够的信心证明是在飞行中攻击。(The team was confident enough to demonstrate an attack in-flight)

    总结

    seL4是世界上第一个经过形式化验证的OS内核。

    虽然到目前为止有其他经过验证的内核,seL4仍然是最先进的。它有最全面的验证过程17。它也是唯一的基于能力的OS验证,它有最先进的实时性支持。我们的持续研究使得seL4在安全导向内核中始终处于领先水平。例如,我们对通过定时通道泄露信息的系统性和原则性预防18

    除了这种技术上的领先地位,seL4在实际应用方面仍然远远领先于其他人:我们从一开始就为现实应用设计seL4,而几乎所有其他经过验证的内核都是学术玩具,离现实应用还很远。事实上,我们只知道另一个(最近)验证过的系统实际上是可部署的(尽管在更有限的场景中)。

    seL4在生产中的应用得益与两大目标:性能上不妥协(第6章)以及旨在支持最广泛应用场景的安全策略,后者通过基于能力的访问控制实现(第4章)。

    seL4参与实际生产的10年经验,显然帮助我们完善和改进了系统,但我很自豪地说,轻微的、增量的改变就足够了。唯一的例外是MCS支持(第5.2节),这需要对模型及其实现进行相当重大的改变,但时间的特权管理是我们在最初设计时已经计划去做的事情。19

    希望这份白皮书能让您对seL4有一个大体的认识,让您知道可以用它做什么,重要的是,让您知道为什么想要使用它。我希望这将帮助您成为seL4社区的活跃成员,包括加入和参与seL4基金会。

    我希望这份文件能够不断发展,我也很期待得到反馈。但最重要的是,我很想听听您部署seL4的经验。

    致谢

    我非常感谢我收到的关于本白皮书早期版本的反馈,这有助于改进它。TS的以下成员对草稿进行了评论:Curtis Millar, Gerwin Klein, Ihor Kuz, June Andronick, Liz Willer, Luke Mondy, Michael Norrish和Zoltan Kocsis。

    此外,我还收到了来自社区成员Ben Leslie和Davor Ocelic的评论。

    Kim Pastor 在创立基金会品牌方面做了很好的工作。

    参考文献


    1. Gerwin Klein, Kevin Elphinstone, Gernot Heiser, June Andronick, et al. seL4: Formal verification of an OS kernel. In ACM Symposium on Operating Systems Principles, pages 207–220, Big Sky, MT, US, October 2009. URL https://ts.data61.csiro.au/publications/nicta_full_text/1852.pdf ↩︎

    2. Gerwin Klein, June Andronick, Kevin Elphinstone, Toby Murray, Thomas Sewell, Rafal Kolanski, and Gernot Heiser. Comprehensive formal verification of an OS microkernel. ACM Transactions on Computer Systems, 32(1):2:1–2:70, February 2014. URL https://ts.data61.csiro.au/publications/nicta_full_text/7371.pdf. ↩︎

    3. Bernard Blackham, Yao Shi, Sudipta Chattopadhyay, Abhik Roychoudhury, and Gernot Heiser. Timing analysis of a protected operating system kernel. In IEEE Real-Time Systems Symposium, pages 339–348, Vienna, Austria, November 2011. IEEE Computer Society. URL https://ts.data61.csiro.au/publications/nicta_full_text/4863.pdf. ↩︎

    4. Thomas Sewell, Felix Kam, and Gernot Heiser. High-assurance timing analysis for a high-assurance real-time OS. Real-Time Systems, 53:812–853, September 2017. URL https://ts.data61.csiro.au/publications/csiro_full_text//Sewell_KH_17.pdf. ↩︎

    5. Anna Lyons, Kent McLeod, Hesham Almatary, and Gernot Heiser. Scheduling-context capabilities: A principled, light-weight OS mechanism for managing time. In EuroSys Conference, Porto, Portugal, April 2018. ACM. URL https://ts.data61.csiro.au/publications/csiro_full_text//Lyons_MAH_18.pdf. ↩︎

    6. Simon Biggs, Damon Lee, and Gernot Heiser. The jury is in: Monolithic OS design is flawed. In Asia-Pacific Workshop on Systems (APSys), Korea, August 2018. ACM SIGOPS. URL https://ts.data61.csiro.au/publications/csiro_full_text//Biggs_LH_18.pdf. ↩︎

    7. Simon Biggs, Damon Lee, and Gernot Heiser. The jury is in: Monolithic OS design is flawed. In Asia-Pacific Workshop on Systems (APSys), Korea, August 2018. ACM SIGOPS. URL https://ts.data61.csiro.au/publications/csiro_full_text//Biggs_LH_18.pdf. ↩︎

    8. Ken Thompson. Reflections on trusting trust: Turing award lecture. Communications of the ACM, 27(8):761–763, August 1984. ↩︎

    9. Anthony Fox and Magnus Myreen. A trustworthy monadic formalization of the ARMv7 instruction set architecture. In Proceedings of the 1st International Conference on Interactive Theorem Proving, volume 6172 of Lecture Notes in Computer Science, pages 243–258, Edinburgh, UK, July 2010. Springer. ↩︎

    10. William Earl Boebert. On the inability of an unmodified capability machine to enforce the–property. In 7th DoD/NBS Computer Security Conference, pages 291–293, September 1984. ↩︎

    11. Bernard Blackham, Yao Shi, Sudipta Chattopadhyay, Abhik Roychoudhury, and Gernot Heiser. Timing analysis of a protected operating system kernel. In IEEE Real-Time Systems Symposium, pages 339–348, Vienna, Austria, November 2011. IEEE Computer Society. URL https://ts.data61.csiro.au/publications/nicta_full_text/4863.pdf. ↩︎

    12. Thomas Sewell, Felix Kam, and Gernot Heiser. Complete, high-assurance determination of loop bounds and infeasible paths for WCET analysis. In IEEE Real-Time and Embedded Technology and Applications Symposium (RTAS), Vienna, Austria, April 2016. URL https://ts.data61.csiro.au/publications/nicta_full_text/9118.pdf. ↩︎

    13. ARINC. Avionics Application Software Standard Interface. ARINC, November 2012. ARINC Standard 653. ↩︎

    14. Anna Lyons, Kent McLeod, Hesham Almatary, and Gernot Heiser. Scheduling-context capabilities: A principled, light-weight OS mechanism for managing time. In EuroSys Conference, Porto, Portugal, April 2018. ACM. URL https://ts.data61.csiro.au/publications/csiro_full_text//Lyons_MAH_18.pdf. ↩︎

    15. Zeyu Mi, Dingji Li, Zihan Yang, Xinran Wang, and Haibo Chen. SkyBridge: Fast and secure inter-process communication for microkernels. In EuroSys Conference, March 2019 ↩︎

    16. Ronghui Gu, Zhong Shao, Hao Chen, Xiongnan (Newman) Wu, Jieung Kim, Vilhelm Sjöberg, and David Costanzo. CertiKOS: An extensible architecture for building certified concurrent OS kernels. In USENIX Symposium on Operating Systems Design and Implementation, pages 653–669, Savannah, GA, US, November 2016. USENIX Association. ↩︎

    17. Gernot Heiser. 10 years seL4: Still the best, still getting better, August 2019. URL https://microkerneldude.wordpress.com/2019/08/06/10-years-sel4-still-the-best-still-getting-better/. Blog post. ↩︎

    18. Qian Ge, Yuval Yarom, Tom Chothia, and Gernot Heiser. Time protection: the missing OS abstraction. In EuroSys Conference, Dresden, Germany, March 2019. ACM. URL https://ts.data61.csiro.au/publications/csiro_full_text//Ge_YCH_19.pdf ↩︎

    19. Gernot Heiser and Kevin Elphinstone. L4 microkernels: The lessons from 20 years of research and deployment. ACM Transactions on Computer Systems, 34(1):1:1–1:29, April 2016. URL https://ts.data61.csiro.au/publications/nicta_full_text/8988.pdf ↩︎

    展开全文
  • seL4用户手册

    2018-10-02 16:31:18
    seL4微内核设计针对实时应用,可潜在应用于强调安全和实时性
  • 操作系统形式化验证实践教程(5) - 搭建seL4环境 尽管我们有太多的基础知识都还没有讲,我们还是要快速进入到验证操作系统的世界中。先知道有什么用,然后再学习,可能是一种比较高效的方法。 搭建seL4验证环境 关于...

    操作系统形式化验证实践教程(5) - 搭建seL4环境

    尽管我们有太多的基础知识都还没有讲,我们还是要快速进入到验证操作系统的世界中。先知道有什么用,然后再学习,可能是一种比较高效的方法。

    搭建seL4验证环境

    关于seL4有多牛,我们就不多介绍了,等我们了解了足够多的细节,回头再看,可能有更加鲜活的印象。基本上,seL4是第一个被完整形式化验证的有商用的操作系统。
    架构图我们也后面再讲,先搞工程化,搭环境。

    下载源代码

    验证seL4需要三部分, seL4源代码,l4v检验脚本代码,以及isabelle。

    我们创建一个验证的目录,然后将seL4代码和l4v代码clone下来:

    git clone https://github.com/seL4/seL4
    git clone https://github.com/seL4/l4v
    

    接着还需要将isabelle的路径link到这个验证目录下。

    安装依赖库

    从上一节我们已经了解到,isabelle的依赖环境很复杂。但是,要验证操作系统,我们依赖的工具更多,比如交叉编译链,设备树编译器,cmake, ninja等,还有一系列辅助的python库。
    在ubuntu下,可以使用apt-get安装部分依赖库:

    sudo apt-get install \
        python3 python3-pip python3-dev \
        gcc-arm-none-eabi build-essential libxml2-utils ccache \
        ncurses-dev librsvg2-bin device-tree-compiler cmake \
        ninja-build curl zlib1g-dev texlive-fonts-recommended \
        texlive-latex-extra texlive-metapost texlive-bibtex-extra \
        mlton-compiler haskell-stack
    

    安装python脚本

    基本操作是安装sel4-deps库。
    例如:

    pip3 install sel4-deps --user
    

    选择sudo pip install的,还有使用virtual-env的请自助。

    设置isabelle环境

    在l4v目录下,将l4vf的默认配置复制过来:

    mkdir -p ~/.isabelle/etc
    cp -i misc/etc/settings ~/.isabelle/etc/settings
    ./isabelle/bin/isabelle components -a
    ./isabelle/bin/isabelle jedit -bf
    

    最后检验一下环境是否可以正常工作:

    ./isabelle/bin/isabelle build -bv HOL-Word
    

    输出如下:

    Started at Thu Aug 6 17:45:32 GMT+8 2020 (polyml-5.8.1_x86_64_32-darwin on IT-C02YX0A4LVDQ)
    ISABELLE_BUILD_OPTIONS=""
    
    ML_PLATFORM="x86_64_32-darwin"
    ML_HOME="/Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/contrib/polyml-5.8.1-20200228/x86_64_32-darwin"
    ML_SYSTEM="polyml-5.8.1"
    ML_OPTIONS="--minheap 500"
    
    Session Pure/Pure
    Session Tools/Tools
    Session HOL/HOL (main)
    Session HOL/HOL-Library (main timing)
    Session HOL/HOL-Word (main timing)
    
    Finished at Thu Aug 6 17:45:35 GMT+8 2020
    0:00:02 elapsed time
    

    编译HOL-Word,需要依赖HOL/HOL-Libaray, HOL/HOL, Tools/Tools和最基础的Pure/Pure库。

    因为没有ROOT文件,大家可能觉得有点抽象,不知道幕后究竟发生了什么。没关系,我们增加一个-l参数列出每个会话的每个文件列表,我们会看到一个长长的列表,我选贴一部分,要不然太长了:

    Session Pure/Pure
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/contrib/polyml-5.8.1-20200228/x86_64_32-darwin/poly
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Pure/Concurrent/cache.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Pure/Concurrent/counter.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Pure/Concurrent/event_timer.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Pure/Concurrent/future.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Pure/Concurrent/lazy.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Pure/Concurrent/mailbox.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Pure/Concurrent/multithreading.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Pure/Concurrent/par_exn.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Pure/Concurrent/par_list.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Pure/Concurrent/single_assignment.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Pure/Concurrent/standard_thread.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Pure/Concurrent/synchronized.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Pure/Concurrent/task_queue.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Pure/Concurrent/thread_attributes.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Pure/Concurrent/thread_data.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Pure/Concurrent/thread_data_virtual.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Pure/Concurrent/thread_position.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Pure/Concurrent/timeout.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Pure/Concurrent/unsynchronized.ML
    ...
    Session Tools/Tools
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Tools/Code/code_haskell.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Tools/Code/code_ml.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Tools/Code/code_namespace.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Tools/Code/code_preproc.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Tools/Code/code_printer.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Tools/Code/code_runtime.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Tools/Code/code_scala.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Tools/Code/code_simp.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Tools/Code/code_symbol.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Tools/Code/code_target.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Tools/Code/code_thingol.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Tools/Code_Generator.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Tools/cache_io.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/Tools/nbe.ML
    Session HOL/HOL (main)
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/ATP.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Archimedean_Field.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Argo.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/BNF_Cardinal_Arithmetic.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/BNF_Cardinal_Order_Relation.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/BNF_Composition.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/BNF_Def.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/BNF_Fixpoint_Base.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/BNF_Greatest_Fixpoint.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/BNF_Least_Fixpoint.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/BNF_Wellorder_Constructions.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/BNF_Wellorder_Embedding.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/BNF_Wellorder_Relation.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Basic_BNF_LFPs.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Basic_BNFs.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Binomial.thy
    ...
    Session HOL/HOL-Library (main timing)
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Library/AList.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Library/AList_Mapping.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Library/Adhoc_Overloading.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Library/BNF_Axiomatization.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Library/BNF_Corec.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Library/BigO.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Library/Boolean_Algebra.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Library/Bourbaki_Witt_Fixpoint.thy
    ...
    Session HOL/HOL-Word (main timing)
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Library/Boolean_Algebra.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Library/Cardinality.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Library/Numeral_Type.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Library/Phantom_Type.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Library/Type_Length.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Library/Z2.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Word/Bit_Comprehension.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Word/Bits.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Word/Bits_Int.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Word/Bits_Z2.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Word/Misc_Arithmetic.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Word/Misc_Auxiliary.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Word/Misc_Typedef.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Word/More_Word.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Word/Tools/smt_word.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Word/Tools/word_lib.ML
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Word/Word.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Word/Word_Bitwise.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Word/Word_Examples.thy
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Word/document/root.bib
      /Applications/Isabelle2020.app/Contents/Resources/Isabelle2020/src/HOL/Word/document/root.tex
    
    Finished at Thu Aug 6 17:59:10 GMT+8 2020
    0:00:03 elapsed time
    

    管理分支

    另外需要注意的是管理代码分支与Isabelle/HOL的兼容性。
    比如在目前的时间点上,默认分支使用Isabelle 2020是跑不通的,需要切换到isabelle-2020分支。

    git checkout isabelle-2020
    

    运行回归测试

    下面我们就可以通过跑测试来验证环境的问题了,运行l4v的run_tests脚本。大约需要十几个小时。

    运行结果类似下面这样:

    Testing for L4V_ARCH=ARM:
    Testing Orphanage for ARM
    Running 49 test(s)...
      Started isabelle ...
      Finished isabelle                  passed      ( 0:00:05 real,  0:00:22 cpu,  0.51GB)
      Started Lib ...
      Finished Lib                       passed      ( 0:00:56 real,  0:05:16 cpu,  3.31GB)
      Started CamkesGlueSpec ...
      Finished CamkesGlueSpec            passed      ( 0:00:31 real,  0:01:42 cpu,  1.83GB)
      Started Sep_Algebra ...
      Finished Sep_Algebra               passed      ( 0:00:39 real,  0:03:37 cpu,  2.91GB)
      Started Concurrency ...
      Finished Concurrency               passed      ( 0:01:09 real,  0:04:24 cpu,  1.87GB)
      Started tests-xml-correct ...
      Finished tests-xml-correct         FAILED *    ( 0:00:00 real,  0:00:00 cpu,  0.01GB)
      Started haskell-translator ...
      Finished haskell-translator        passed      ( 0:00:00 real,  0:00:00 cpu,  0.00GB)
      Started SepTactics ...
      Finished SepTactics                passed      ( 0:01:05 real,  0:05:20 cpu,  3.16GB)
      Started TakeGrant ...
      Finished TakeGrant                 passed      ( 0:00:28 real,  0:01:29 cpu,  1.75GB)
      Started ASpec ...
      Finished ASpec                     passed      ( 0:00:06 real,  0:00:23 cpu,  0.50GB)
      Started AInvs ...
      Finished AInvs                     passed      ( 0:19:53 real,  1:23:31 cpu, 14.11GB)
      Started BaseRefine ...
      Finished BaseRefine                passed      ( 0:04:39 real,  0:10:15 cpu,  5.49GB)
      Started Refine ...
      Finished Refine                    passed      ( 0:27:47 real,  2:25:11 cpu, 17.19GB)
      Started RefineOrphanage ...
      Finished RefineOrphanage           passed      ( 0:01:49 real,  0:05:21 cpu,  3.72GB)
      Started DBaseRefine ...
      Finished DBaseRefine               passed      ( 0:03:00 real,  0:07:30 cpu,  4.96GB)
      Started DRefine ...
      Finished DRefine                   passed      ( 0:08:57 real,  0:50:21 cpu,  5.12GB)
      Started Access ...
      Finished Access                    passed      ( 0:05:06 real,  0:24:18 cpu,  5.42GB)
      Started CamkesAdlSpec ...
      Finished CamkesAdlSpec             passed      ( 0:01:48 real,  0:03:42 cpu,  3.29GB)
      Started InfoFlow ...
      Finished InfoFlow                  passed      ( 0:25:37 real,  1:10:27 cpu,  8.55GB)
      Started DPolicy ...
      Finished DPolicy                   passed      ( 0:02:29 real,  0:07:55 cpu,  3.91GB)
      Started CamkesCdlRefine ...
      Finished CamkesCdlRefine           passed      ( 0:02:40 real,  0:06:38 cpu,  3.32GB)
      Started Bisim ...
      Finished Bisim                     passed      ( 0:00:47 real,  0:02:29 cpu,  2.87GB)
      Started ExecSpec ...
      Finished ExecSpec                  passed      ( 0:04:39 real,  0:11:51 cpu,  4.56GB)
      Started DSpec ...
      Finished DSpec                     passed      ( 0:02:39 real,  0:08:01 cpu,  4.40GB)
      Started SepDSpec ...
      Finished SepDSpec                  passed      ( 0:00:50 real,  0:04:05 cpu,  2.24GB)
      Started DSpecProofs ...
      Finished DSpecProofs               passed      ( 0:01:08 real,  0:06:09 cpu,  2.29GB)
      Started ASepSpec ...
      Finished ASepSpec                  passed      ( 0:00:20 real,  0:01:05 cpu,  1.55GB)
      Started HaskellKernel ...
      Finished HaskellKernel             FAILED *    ( 0:00:00 real,  0:00:00 cpu,  0.02GB)
      Started SysInit ...
      Finished SysInit                   passed      ( 0:02:58 real,  0:13:16 cpu,  3.42GB)
      Started SysInitExamples ...
      Finished SysInitExamples           passed      ( 0:02:19 real,  0:07:46 cpu,  2.20GB)
      Started CParser ...
      Finished CParser                   passed      ( 0:00:06 real,  0:00:25 cpu,  0.55GB)
      Started CLib ...
      Finished CLib                      passed      ( 0:00:42 real,  0:04:26 cpu,  3.65GB)
      Started LibTest ...
      Finished LibTest                   passed      ( 0:04:23 real,  0:13:57 cpu,  6.98GB)
      Started c-kernel ...
      Finished c-kernel                  passed      ( 0:00:01 real,  0:00:00 cpu,  0.02GB)
      Started CKernel ...
      Finished CKernel                   passed      ( 0:00:07 real,  0:00:26 cpu,  0.50GB)
      Started CSpec ...
      Finished CSpec                     passed      ( 0:07:10 real,  0:38:37 cpu,  9.98GB)
      Started CBaseRefine ...
      Finished CBaseRefine               passed      ( 1:07:16 real,  6:04:21 cpu, 17.59GB)
      Started CRefine ...
      Finished CRefine                   passed      ( 1:01:46 real,  4:59:21 cpu, 17.40GB)
      Started InfoFlowCBase ...
      Finished InfoFlowCBase             passed      ( 0:32:30 real,  1:32:45 cpu, 10.14GB)
      Finished SimplExportAndRefine      passed      ( 3:15:33 real,  7:36:36 cpu,  8.88GB)
      Started CParserTest ...
      Finished CParserTest               passed      ( 0:00:06 real,  0:00:23 cpu,  0.51GB)
      Started CParserTools ...
      Finished CParserTools              passed      ( 0:00:01 real,  0:00:00 cpu,  0.02GB)
      Started AutoCorres ...
      Finished AutoCorres                passed      ( 0:01:01 real,  0:05:48 cpu,  3.34GB)
      Started CamkesGlueProofs ...
      Finished CamkesGlueProofs          passed      ( 0:13:20 real,  0:45:57 cpu,  4.98GB)
      Started AutoCorresDoc ...
      Finished AutoCorresDoc             passed      ( 0:00:18 real,  0:00:53 cpu,  1.84GB)
      Started AutoCorresTest ...
      Finished AutoCorresTest            passed      ( 0:05:11 real,  0:32:09 cpu,  9.17GB)
    

    其中最长的用例SimplExportAndRefine消耗7个多小时CPU时间。

    展开全文
  • seL4 下载

    千次阅读 2014-08-30 17:36:49
    本文译至:http://sel4.systems/Download/ 代码 所有的seL4代码和证明都可以在GitHub上找到: https://github.com.au/seL4, 在标准的开放源代码许可证下。...l4v seL4 证明seL4 seL4 内核 seL4 项目 seL4
  • sel4.0.8.pdf

    2020-04-07 20:24:22
    seL4内核参考手册中文翻译,主要依据原版本11.0.0(2019年11月20日),对截止当前(2020年4月7日)的内核树少量变动也作了同步更新。在对照源码的基础上力求搬运地清楚准确。
  • seL4 微内核是世界上第一个具有实现正确性和安全执行的数学、机器检查证明的操作系统(OS)内核。它在Arm和RISC-V处理器上的全面证明仍然是独一无二的。它也是开源的、免费使用的性能基准,并得到中立的、非营利的 seL...
  • seL4-manual-3.0.0.pdf

    2021-09-10 11:22:58
    国外原版介绍seL4系统操作手册,非常详细,值得阅读
  • seL4 构建和测试

    千次阅读 2014-08-28 23:36:13
    转载至:https://source2014.hackpad.com/seL4--IJItb9IDncR
  • Unix sel4 微内核源码

    2018-05-15 17:29:26
    seL4是世界上最小的内核之一。但是seL4的性能可以与当今性能最好的微内核相比。 作为微内核,seL4为应用程序提供...seL4是高性能的L4微内核家族的新产物,它具有操作系统所必需的服务,如线程,IPC,虚拟内存,中断等。
  • seL4微内核学习之四:系统调用

    千次阅读 2016-12-08 23:45:24
    seL4系统调用主要有以下八个: seL4 Send(): 通过已被命名的cap传递消息,然后允许程序继续,如果调用这个cap的是endpoint,且没有receiver接收消息,sender将会被阻塞到有receiver接收。Reciver和内核对象不会...
  • sel4线程和执行

    2021-03-10 21:47:26
    sel4 线程和执行 线程 seL4提供了表示执行上下文和管理处理器时间的线程。在seL4中,线程由其线程控制块对象(TCB)表示。每个TCB都有一个相关的CSpace(见第3章)和VSpace(见第7章),它们可以被其他线程共享。TCB还可以...
  • 作为微内核操作系统seL4只提供很少的基础内核服务,复杂的服务将在用户态基于这些基础内核服务实现。 基础内核对象有以下五个: Threads:是运行CPU的抽象。 Address spaces:是分配给应用程序的虚拟地址空间,...
  • 9 月 16 日下午,seL4 基金会主席、悉尼新南威尔士大学教授 Gernot Heiser,以及鉴释 CEO 梁宇宁,围绕下一代汽车操作系统微内核 seL4,在直播间分享了 seL4 的验证故事及其实际的工程实践,此次直播是中英双语进行...
  • sel4源码解析(一) - sel4内核对象

    千次阅读 2020-02-16 07:22:21
    Sel4提供了七个内核对象,分别是: 1.CNodes:CNodes本质是一个结构体数组,该数组的元素是cte(capability table entry),该cte中包含一个cap_t结构体和mdb_node_t结构体(todo)。一个进程的CNodes称为Cspace,C...
  • 操作系统微内核架构研究

    千次阅读 2020-11-18 17:02:46
    微内核是操作系统内核的一种,在工控系统、嵌入式系统、实时系统等领域发挥着重要作用。本文较为全面地研究了微内核技术的各个方面,包括微内核的定义、微内核的体系架构、微内核的发展历史、微内核的特点、微内核的...
  • 微内核越大的系统潜在的bug就越多,所以微内核在减少bug方面很有优势,seL4是世界上最小的内核之一。...seL4是高性能的L4微内核家族的新产物,它具有操作系统所必需的服务,如线程,IPC,虚拟内存,中断等。...
  • Mixed-Criticality System ,Scheduling in seL4 PHP JIT AArch64 backend Implementation 闪存系统一致性的新探索 腾讯云软硬一体虚拟化技术实践 TypeScript到WebAssembly的实践和探索 边缘算力网络的探索与实践 ...
  • 作者承认他对微内核、调度和操作系统开发的熟悉程度很低。 有关此存储库的所有内容都应视为已损坏,直至另行通知。 安装 从头开始 按照官方 seL4 说明 。 简而言之,一旦您具备以下先决条件: $ mkdir schedul4-...
  • 操作系统形式化验证实践教程(4) - 工具环境 如前面我们所了解的,Isabelle/HOL是套相当复杂的系统,它的底层基于Standard ML语言,它自己使用HOL和Isar语言,它可以生成ocaml,haskell和scala的代码,它有要使用到很...
  • 该楼层疑似违规已被系统折叠隐藏此楼查看此楼引入成熟的微内核技术改良...应用sel4微内核的高度安全特性打造ntoskrnl模块的稳固。进而把精力用于继续兼容windows应用,或者引入posix子用户层兼容UNIX/Linux软件。---...
  • 微内核设计的基本思想是简化内核功能,在内核之外的用户态尽可能多地实现系统服务,同时加入相互之间的安全保护。内核只提供最基础的服务,比如多进程调度、多进程通信(IPC)等。其中进程通信是作为连接应用与用户态...
  • 本研发基于开源项目 ...例如,Docker 不支持实时操作系统(RTOS),仅适用于 POSIX 系统。 此外,在智能工厂和智能汽车等边缘网络和设备上,行业生态和供应商网络的现状造就了应用程序必须由多个独立供应商组装。例如
  • 开源微内核seL4

    万次阅读 2015-07-10 11:15:56
    越大的系统潜在的bug就越多,所以微内核在减少bug方面很有优势,seL4是世界上最小的内核之一。 如今,安全越来越成为一个新兴嵌入式设备的关键要素,如智能手机。

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 23,711
精华内容 9,484
关键字:

sel4操作系统

友情链接: music.rar