单内核操作系统的问题所在

现代操作系统通常将其操作分为两个主要的安全域：非特权域（用户模式）和特权域（内核模式）。软件大部分时间都在用户模式下运行，在这种模式下，软件被限制不能直接执行诸如访问文件或网络通信等强大操作。为了执行这些操作，软件必须通过发起一个“系统调用”暂时提升到内核模式，这是一个请求内核接管并执行所需操作的请求。例如，当一个程序想要打开一个文件时，它会发起一个系统调用，这将程序切换到内核代码并运行在内核模式下。内核代码会验证程序是否有访问权限访问该文件，然后返回一个特殊的句柄到用户模式，该句柄代表已打开的文件。

大多数操作系统使用的是_单内核（monolithic kernel）_设计，在这种设计中，内核对整个系统——包括所有硬件、内存和用户数据——具有无限制的访问权限。在没有软件缺陷的理想世界里，如果没有人试图破坏安全，这种设计或许是可以接受的。然而，软件常常会有缺陷，其中一些缺陷会导致安全漏洞。由于单内核通常较大，因此这些漏洞出现并被利用的机会也更大。一旦漏洞被成功利用，可能导致整个系统的完全崩溃，因为操作系统的所有功能都集中在内核单一的“鸡蛋篮子”里。

一种名为_微内核_的替代内核设计，将内核自身的功能最小化，将大部分操作移至独立的无特权进程中。这可以通过隔离潜在的漏洞来提高安全性。然而，微内核可能会遇到性能问题，并给应用程序软件增加额外的复杂度。因此，单内核设计仍然很普遍，与之相关的漏洞问题依然存在。

iOS、macOS、tvOS、visionOS 和 watchOS 共享的内核 —— 命名为 XNU —— 是基于一个名为 Mach 的微内核（monolithic kernel）。然而，XNU 的实现方式将所有系统功能置于同一个特权范围内，因此实际上它作为一个单内核（monolithic kernel）在运行。和所有单内核（monolithic kernel）一样，XNU 内核不幸的是也经常发现一些常见的漏洞。

隔离努力

多年来，人们开发了各种基于软件和硬件的缓解措施，以将系统的一些部分与其更为脆弱的单内核系统隔离。以下是几个非苹果公司的例子：

• Microsoft 虚拟化基础的安全性（VBS），用于 Windows 中的 凭据保护 功能
• Intel 的 SGX 和 VT-X2 技术

• ARM TrustZone — 支持三星 Knox、三星 Pay、Android 安全启动、Android 安全 PIN 输入等功能等特性

  苹果也越来越多地尝试将数据从内核中隔离出来，相关内容将在下文详述。

2013 — Apple安全区域技术

在2013年，苹果公司发布了iPhone 5s，这是第一款内置安全岛（Secure Enclave）的iPhone。安全岛通过一个专用的、加固的CPU核心运行一个名为_SepOS_的微内核操作系统来实现。_SepOS_的基础内核是cL4，这是苹果基于L4嵌入式微内核的定制版本。安全岛用来存储和保护敏感数据，比如加密密钥和生物信息（如Face ID）。安全岛独立运行，并且不依赖于iOS内核，仅通过受控的安全交互方式向iOS提供服务。即使iOS内核被破解，安全岛也通常不受影响，除非安全岛本身也有漏洞被利用。

别把 Secure En 区域与本文提到的 Secure Ex 区域搞混！

2017 — 页防层

随着 iPhone 8 和 iPhone X 搭载 A11 处理器的推出，苹果引入了一项名为 页面保护层 (PPL, Page Protection Layer) 的安全功能。这一软硬件结合的特性将内核的一部分隔离，赋予其修改内存页面表的权限——这些结构是管理内存访问的关键。内核的其余部分则无法直接修改这些页面表。由于 PPL 攻击面很小，绕过它的难度极高。虽然 PPL 增加了一层保护，但它仅部分有效，因为内核的其他部分仍然保有大多数权限，可以不修改页面表就破坏数据。

基于安全页表的2021–2023监控

在PPL之后，iPhone 13搭载的A15处理器发布了新的功能特性，这些功能特性中包括了iOS 17中的Secure Page Table Monitor（SPTM）。SPTM取代并增强了PPL，通过保护额外的内存功能并将其划分为不同的子系统，进一步隔离了小型内核组件，使它们更加独立。代码签名验证过程也被单独隔离，以确保所有代码都已由Apple签名。

大约在这个时候，XNU 源代码中开始出现对 飞地（exclave） 的一些间接提及。这些 飞地（exclave） 可能是由 SPTM 管理的子系统。然后，2024 年来了……

2024 — 飞地：XNU 的一个重要新增功能

随着支持M4和A18系统的XNU源代码（如iPhone 16）的发布，部分揭露了exclaves的真面目。需要注意的是，exclaves在之前的处理器上并未被激活。

现在很明显的是，飞地是 XNU 安全框架大规模重新设计的一部分。

XNU离散区域

先声明一下：此分析不会完全正确——这些地区很多部分未公开，其内部运作我们只能通过猜测或推测来了解.

2005年闭门会议：白烟表示新教皇已经选出；在这次情况下，是教宗本笃十六世

外飞地功能是一组新的功能，代表了XNU传统单内核的重要改进。外飞地是指从XNU中隔离的资源，即使内核受损也能得到保护。这些资源在操作系统构建时预先定义好的，并通过名称或ID进行标识，具有不同的类型，启动时初始化，并按独特领域组织。SPTM使用新的特定于外飞地的页面类型来保护外飞地内存，使其免受XNU的影响。资源类型包括：

• 可由内核和外clave访问的共享内存缓冲，可以选择将其设置为只读或读写模式供XNU使用。
• 用于确保摄像头和麦克风访问指示器等功能的音频缓冲区和传感器。
• 外clave，将多个资源分组到其各自的独立安全域中及其相应的外clave管理器。
• 可在XNU中的线程调用时于外clave空间中执行代码的服务。

这些线程在不同的权限级别和其他世界之间切换上下文环境

安全的内核 — seL4？ (？)

为了在与XNU隔离的情况下执行外飞地服务（exclave Services），Apple引入了一个新内核，称作安全内核（SK）。SK镜像文件包含“cL4”的版本字符串。尽管我尚未尝试对其进行反汇编，但有迹象表明，它实际上基于seL4内核，尽管名称为“cL4”。XNU与SK通信所用的IPC结构更接近seL4，而非最初用于SepOS cL4内核的L4-embedded。SK中的字符串常提及其能力、帧、未类型化内存和铸造等概念，这些与seL4紧密相关。

或许并非偶然，seL4基金会在2024年4月公开宣布苹果公司加入。顺便提一下，苹果公司新推出的C1基带芯片的内核也是基于某种L4版本的，因此，苹果公司在这一领域投入很大。

安全的世界吗 — ARM TrustZone

如前所述，SepOS 运行在一个专用的处理器上，以实现最大隔离。相比之下，SK 运行在与 XNU/iOS 相同的高速应用处理器上。为了实现这一目标，可能需要额外的处理器权限级别——这可能是通过虚拟化扩展、苹果对 SPTM 的特定扩展，或者最有可能是通过 ARM 的 TrustZone 技术（或简称 TZ）实现的。XNU 源代码中有多个关于过渡到和离开 TrustZone 的 安全世界 概念的引用，并且这可能是最干净的实现方式。

TrustZone将系统划分为两个世界：_安全世界_和非安全世界。ARM提供了几种TrustZone的设计模式，苹果似乎受到了这些模式的影响。XNU（和iOS）运行在非安全世界中，而SK则运行在安全世界中，提供了一个有限的操作环境给外飞地、资源和服务。这与ARM建议的可信应用程序设计模式不同。鉴于外飞地服务的隔离性质和安全内核有限的攻击面，从安全世界逃逸以攻击XNU可能要比直接从非安全世界中利用它要困难得多。

苹果可能使用SPTM来管理安全和非安全状态之间的切换，这只是我的猜测，因为这并未开源，所以需要反汇编二进制文件。代码将这种转换称为RINGGATE。

更深入的了解

领域和资源：

XNU 在启动时初始化一个两层内核表结构，用于存储发现的专属资源信息。每个资源仅有一种类型，并包含安全世界或两个世界中的资源的信息。

根表通过名称来识别各个域，每个域都关联到一个二级表，该二级表保存了该域的所有资源。到目前为止，我们已经发现了以下域及其资源：

com.apple.kernel — 此领域包含内核使用到的许多资源，包括：

• com.apple.service.ConclaveLauncherControl — 启动控制服务
• com.apple.service.ConclaveLauncher_Debug — 调试服务（Debug）
• com.apple.service.ExclaveIndicatorController — 安全指示灯控制器服务
• com.apple.service.LogServer_XNUProxy — 日志记录服务
• com.apple.service.FrameMint — 用于启动 ExclaveKit 的服务（FrameMint）
• com.apple.storage.backend — 共享内存缓冲区，用于通过 upcalls 从 XNU 空间进行文件 I/O（详情见下文）
• Conclave Manager x — 每个 Conclave 使用一个，用于控制 Conclave
• Conclave Manager y 等等…

com.apple.darwin — 没有开源组件使用这个域名

com.apple.conclave.name — 每个宗座只有一个域。

• 服务X
• 服务Y
• 音频缓存
• 共享内存缓存
• 等等等

com.apple.driver.name — 每个设备驱动程序一个域 — 这些域的存在是基于评论而非在开源代码中实际看到。我猜测这些只是每个驱动程序的私有区域。

议事厅

一个康克瓦是一种资源，自身可以包含多个资源。但是，它远不止是一个资源容器。它让一组服务和其他资源能相互访问。而Mach任务只能调用有限数量的康克瓦。

每个会议都有一个“会议管理者”（一种专属资源），位于内核域。

会议有一个生命周期，在这个过程中，其会议管理员首先被连接到一个Mach任务上，然后被启动运行。它们也可以被停止和断开。在生命周期中，存在诸如启动中和停止中这样的状态。

公会——生成与附着

XNU 中的 posix_spawn() 函数可以通过调用 task_add_conclave() 将一个任务与一个 conclave 管理器关联起来。这是一个一对一的关系——一个任务只能关联到一个 conclave 管理器，反之亦然。只有 launchd 和具有 _com.apple.private.exclaves.conclave-spawn_ 权限的任务才能启动一个 conclave。而 _com.apple.private.exclaves.conclave-host_ 权限则类似，但我认为它仅仅允许任务关联自身，而不是能够为此目的启动新任务。

内核会在 com.apple.kernel 域中查询目标集群对应的集群管理资源。然后将一个 tightbeam 端点保存到该集群管理者的端点，记录在集群资源结构中。这个端点将用作未来控制集群的所有指令的目标。Tightbeam 看起来是一种用于模块之间通信的 RPC 框架。

注意，这个附件是跟任务相关的——而不是线程。服务的执行会在后面提到。

管控任务不允许具有内核权限。

闭门会议 — — 开始

一旦附加后，一个公会议（conclave）可以被启动。启动尝试必须从附加到公会议的管理任务中进行。启动公会议的尝试等待，直到外离单元（exclave）完全启动（进入状态 EXCLAVES_BS_BOOTED_EXCLAVEKIT——这将在以后详细说明）。

在XNU中添加了一个新的Mach陷阱（即系统调用），用于exclave功能，并最终调用__exclaves_ctl_trap()函数。此调用可以执行通过参数传递的不同操作，其中启动conclave的操作码为"EXCLAVES_CTL_OP_LAUNCH_CONCLAVE"。

启动操作调用了一个被删节的函数，_conclave_launcher_conclavecontrollaunch()，并将紧束光束连接传递给共clave 管理器，用来执行启动操作。我觉得这可能是在请求在安全世界中为共clave 初始化可执行代码和资源。

在生产环境中，当启动时，会议主机可能会被 受到污染，此时调用 exit() 函数可能导致内核崩溃。

新引入的机制/系统调用机制

如前所述，_exclaves_ctl_trap() 函数处理与外部区域功能相关的新的 Mach 陷阱。该函数是重载的，其行为取决于提供的操作参数，并通常验证操作权限。具体操作如下：

• EXCLAVES_CTL_OP_BOOT — 在系统启动过程中被调用两次 — 第一次用于启动独立区域第二阶段，然后用于启动 ExclaveKit。调用者必须是 launchd 或拥有 com.apple.private.exclaves.boot 的权限。

以下所有操作至少需要具备当前任务具有 com.apple.private.exclaves.kernel-domain 权限，或者作为相关 conclave 的管理任务

• EXCLAVES_CTL_OP_LAUNCH_CONCLAVE — 启动一个公会议，之前已讨论过
• EXCLAVES_CTL_OP_LOOKUP_SERVICES — 查找一个飞地服务并将它的结构复制到用户空间缓冲区。首先在当前任务的飞地域中查找，如果失败则检查Darwin域，然后是内核域（如果有权这么做）
• EXCLAVES_CTL_OP_ENDPOINT_CALL — 调用当前任务域中飞地服务的端点，这将导致当前线程从内核模式切换到安全世界并执行特定代码
• EXCLAVES_CTL_OP_NAMED_BUFFER_CREATE — 创建命名缓冲区资源
• EXCLAVES_CTL_OP_NAMED_BUFFER_COPYIN — 将用户空间缓冲区中的数据复制到内核缓冲区（与飞地共享）
• EXCLAVES_CTL_OP_NAMED_BUFFER_COPYOUT — 将内核缓冲区（与飞地共享）中的数据复制到用户空间缓冲区
• EXCLAVES_CTL_OP_AUDIO_BUFFER_CREATE — 创建一个音频缓冲区
• EXCLAVES_CTL_OP_AUDIO_BUFFER_COPYOUT — 将音频缓冲区中的数据复制到用户空间缓冲区
• EXCLAVES_CTL_OP_SENSOR_CREATE — 创建一个传感器资源（例如摄像头、麦克风）
• EXCLAVES_CTL_OP_SENSOR_START — 启动传感器
• EXCLAVES_CTL_OP_SENSOR_STOP — 停止传感器
• EXCLAVES_CTL_OP_SENSOR_STATUS — 获取传感器状态
• EXCLAVES_CTL_OP_NOTIFICATION_RESOURCE_LOOKUP — 创建一个通知资源 — 待定，但很可能是用于协调/调度的

在安全环境中运行代码

下行呼叫是指调用外飞地 Services 端点的调用，也就是在安全世界中代码执行的地方，这样更符合中文的表达习惯。

这些调用非常复杂，主要是因为需要管理线程和IPC的上下文，并调度当前线程在安全环境中运行代码。

1. 下调用会将当前线程切换到安全世界，并从安全代码中的入口点开始执行，而不是请求其他线程代表当前线程执行任务。
2. 调用任务必须具有内核域权限，或者必须是附属于服务密舱的管理任务。
3. 密舱最多可以调用128个服务，这意味着每个密舱最多可以有128个服务被调用。
4. 看起来XNU通过调用sk_enter()函数将线程调度到安全内核。XNU似乎负责安全世界中所有线程的调度，而SK可能没有独立的线程。
5. 在安全世界中执行的线程可以执行暂时上调调用，将线程返回到内核模式进行上调调用，然后强制返回到安全世界上下文。稍后将提供更多关于上调调用的详细信息。
6. 在安全世界中运行的线程可以执行正常调度器类型的操作，如让出、等待、挂起或中断。发生这种情况时，线程会离开安全世界并返回到XNU内核上下文。从那里，它必须通过XNU中的外舱调度代码重新调度到安全世界。线程将继续根据需要重新调度到安全世界，直到完成下调。
7. 如果安全世界中的线程在一个CPU核心上触发panic()（这将通过SPTM调用XNU的panic()），则不再在其他核心上为安全世界调度新的任务，它们将等待超时期。如果一切顺利，等待中的线程将永远无法完成等待。但是，如果超时期结束，等待中的线程将……执行panic() :)
8. 看起来XNU处理所有中断处理，而不是SK。当XNU完成处理中断后，如果中断的线程是在安全世界中执行的，它将被返回到安全世界。将中断导向到不安全或安全内核是ARM可信执行环境的功能之一。
9. 在进入安全世界之前，下调用的IPC结构通过sk_enter()调用设置请求和响应缓冲区。
10. 在最终化IPC请求结构和调用sk_enter()期间，会禁用中断和抢占。
11. 下调用响应可以通过另一个CPU的核心响应缓冲区返回，因为下调用可能被中断、上调或让出并需要重新调度。
12. 通过线程结构中的th_exclaves_state位字段来协调线程的外舱状态（以避免重新进入SK等）。

来自 Secure World 的 XNU 调用

在安全世界中，由于下调调用，一个线程可能需要XNU提供的帮助，这可以通过Tightbeam框架调用给隔离区的上调处理程序来实现。上调仅限于XNU中的特定函数。希望进行上调的线程会返回到不安全的世界，在那里特定的上调处理程序会被调用。在此状态下，线程不能返回用户模式（这是显而易见的），也不能再次下调到安全世界中，即不允许线程再次“重新进入”隔离区。相反，线程将在执行上调的地方返回到安全世界。

允许的回调会出现在如下的函数中：

内存分配
调用内存分配函数 exclaves_memory_upcall_alloc(npages, kind, completion)；
调用内存释放函数 exclaves_memory_upcall_free(pages, npages, kind, completion)；

文件存储操作
exclaves_storage_upcall_root(exclaveid, completion); // 获取隔离区的根目录
exclaves_storage_upcall_open(fstag, rootid, name, completion); // 打开文件
exclaves_storage_upcall_close(fstag, fileid, completion); // 关闭文件
exclaves_storage_upcall_create(fstag, rootid, name, completion); // 创建文件
exclaves_storage_upcall_read(fstag, fileid, descriptor, completion); // 读取文件
exclaves_storage_upcall_write(fstag, fileid, descriptor, completion); // 写入文件
exclaves_storage_upcall_remove(fstag, rootid, name, completion); // 删除文件
exclaves_storage_upcall_sync(fstag, op, fileid, completion); // 同步文件
exclaves_storage_upcall_readdir(fstag, fileid, buf, length, completion); // 读取目录
exclaves_storage_upcall_getsize(fstag, fileid, completion); // 获取文件大小
exclaves_storage_upcall_sealstate(fstag, completion); // 获取密封状态

DriverKit
exclaves_driverkit_upcall_irq_register(id, index, 完成);
exclaves_driverkit_upcall_irq_remove(id, index, 完成);
exclaves_driverkit_upcall_irq_enable(id, index, 完成);
exclaves_driverkit_upcall_irq_disable(id, index, 完成);
exclaves_driverkit_upcall_timer_register(id, 完成);
exclaves_driverkit_upcall_timer_remove(id, timer_id, 完成);
exclaves_driverkit_upcall_timer_enable(id, timer_id, 完成);
exclaves_driverkit_upcall_timer_disable(id, timer_id, 完成);
exclaves_driverkit_upcall_timer_set_timeout(id, timer_id, duration, 完成);
exclaves_driverkit_upcall_timer_cancel_timeout(id, timer_id, 完成);
exclaves_driverkit_upcall_lock_wl(id, 完成);
exclaves_driverkit_upcall_unlock_wl(id, 完成);
exclaves_driverkit_upcall_async_notification_signal(id, 通知ID, 完成);
exclaves_driverkit_upcall_mapper_activate(id, 映射索引, 完成);
exclaves_driverkit_upcall_mapper_deactivate(id, 映射索引, 完成);
exclaves_driverkit_upcall_notification_signal(id, mask, 完成); // 参数mask表示信号掩码，用于过滤特定的通知信号

Apple 神经引擎驱动程序

设置电源状态（设置设备的电源状态）
exclaves_driverkit_upcall_ane_setpowerstate(id, desiredState, completion);
提交任务（将任务提交给处理）
exclaves_driverkit_upcall_ane_worksubmit(id, requestID, taskDescriptorCount, submitTimestamp, completion);
任务开始（标记任务开始的时间）
exclaves_driverkit_upcall_ane_workbegin(id, requestID, beginTimestamp, completion);
任务结束（标记任务结束的时间）
exclaves_driverkit_upcall_ane_workend(id, requestID, completion);

注释：

• id：标识符
• desiredState：期望的电源状态
• completion：完成回调
• requestID：请求标识符
• taskDescriptorCount：任务描述符数量
• submitTimestamp：提交时间戳
• beginTimestamp：开始时间戳

闭会
exclaves_conclave_upcall_suspend(flags, completion); // 挂起调用
exclaves_conclave_upcall_stop(flags, completion); // 停止调用
exclaves_conclave_upcall_crash_info(shared_buf, length, completion); // 获取崩溃信息

XNUProxy（代号）

关于 XNUProxy 的提及很多，但我还没有确切地弄清楚它到底是什么以及它在哪里。我考虑过的选项有：

• 它是一个独立域，类似于 com.apple.xnuproxy
• 它是一个运行在 com.apple.kernel 域中的独立服务或一组服务，为特定类型的下层调用提供服务。
• 它是 SPTM 中的一个子系统，用于向安全世界发起下行调用

评论在 Exclaves_L4.h 中指出，XNU 代理让以下这些区域可以访问（除了通常包含单词“HELLO”的测试飞地）：

• EXCLAVES_XNUPROXY_EXCLAVE_USERAPP/2/3（模板化用户应用程序...）
• EXCLAVES_XNUPROXY_EXCLAVE_AUDIODRIVER
• EXCLAVES_XNUPROXY_EXCLAVE_EXCLAVEDRIVERKIT（ExclaveDriverKit工具包）
• EXCLAVES_XNUPROXY_EXCLAVE_SECURERTBUDDY_AOP（面向常驻处理器的RT助手）
• EXCLAVES_XNUPROXY_EXCLAVE_SECURERTBUDDY_DCP（面向显示处理器的RT助手）
• EXCLAVES_XNUPROXY_EXCLAVE_CONCLAVECONTROL（Conclave启动器控制）
• EXCLAVES_XNUPROXY_EXCLAVE_CONCLAVEDEBUG（调试工具）
• EXCLAVES_XNUPROXY_EXCLAVE_SECURERTBUDDY_AOP_EDK（面向常驻处理器的ExclaveDriverKit连接）
• EXCLAVES_XNUPROXY_EXCLAVE_SECURERTBUDDY_DCP_EDK（面向显示处理器的ExclaveDriverKit连接）

请注意，RTBuddys 用于与 RTKit 通信，而 RTKit 是运行在显示处理器、Apple Neural Engine、NVMe 控制器、SMC 控制器、智能键盘、Siri 控制器、Apple Pencil、AirPods、AirTags……等设备上的苹果操作系统，我想它也可能运行在 AOP 上。

启动阶段一

在系统启动时初始化飞地需要两个世界的微妙协作。任何出错通常会导致触发panic()，这通常会导致系统恐慌。

启动过程分为三个阶段。第一阶段对开源不可见，但很可能是一个安全启动过程，其中SK被加载到内存并被验证其代码签名后才被执行。成功完成第一阶段启动后，启动状态会变为EXCLAVES_BS_NOT_STARTED。

启动阶段 2

1. 通过创建一个紧束光端点来初始化上行调用服务
2. 通过一次特殊的调用来进入安全世界以收集启动信息
3. 再次通过正常的端点调用进入安全世界，但不确定为什么……可能是为了触发内核区的启动
4. 初始化外域调度程序
5. 初始化XrtHostedXNU内核扩展程序
6. 初始化回调（我认为是向上述的内核扩展程序）
7. 启动调度程序——只为启动CPU核心设置请求和响应机制，并绑定到启动核心
8. 循环调用安全世界，看是否需要内存分配，直到其确认所有外域均已启动
9. 初始化多核心——为所有核心设置请求和响应内存
10. 初始化XNU代理——创建用于IPC调用的缓存，创建一些线程上下文，并设置一个用于下行调用的紧束光端点
11. 初始化外域的恐慌内核线程程序
12. 发现所有静态外域资源，并构建域和资源的根表
13. 为所有Conclave管理资源创建紧束光端，并为每个端点调用初始化过程
14. 为每个Conclave填充有效的服务ID位图（从0到127）
15. 在内核构建时，将启动任务列表存储在__DATA_CONST段中。现在根据优先级排序并调用每个启动任务函数。我可能只了解了一部分，但这些任务包括为每个外域指示器控制器服务、存储后端服务、日志服务器和堆栈快照服务创建端点
16. 启动状态现在是EXCLAVES_BS_BOOTED_STAGE_2阶段

第三引导阶段：引导ExclaveKit

舞台多次调用与“frameint”相关的指令。这表明SK可能是基于seL4的。

1. 查询“com.apple.service.FrameMint”服务，并为它创建一个tightbeam端点。
2. 调用了一个被省略的函数framemint_framemint__init()。
3. 调用了一个被省略的framemint_framemint_populate()函数，我猜这将会引发安全世界中各种令人兴奋的活动。
4. 启动状态现在是EXCLAVES_BS_BOOTED_EXCLAVEKIT。

SPTM记忆打字模式

SPTM 给内存页面标记类型以控制不同子系统的访问。现有的类型有:

• XNU_USER_EXEC
• XNU_USER_DEBUG
• XNU_USER_JIT
• XNU_ROZONE
• XNU_KERNEL_RESTRICTED
• +TXM、DART 等类型

已添加如下:

• SK_DEFAULT（仅限 SK 使用 —— XNU 不可访问）
• SK_IO（仅限 SK 使用 —— XNU 不可访问）
• SK_SHARED_RO（与 XNU 共享的内存（XNU 只读））
• SK_SHARED_RW（与 XNU 共享的内存（XNU 可读写））

瑞典说，结论是

面对高级威胁行为者持续的剥削行为，苹果公司通过实现 Exclaves 在其操作系统中增加了额外的多层次防御，这是一项重大的投资。通过隔离敏感资源，苹果公司减少了潜在的攻击面，并减少了单个内核被攻陷的影响。防御单内核系统是一个如同西西弗斯式任务般的挑战，而 exclaves 是应对这一挑战的一种方法——这是否是长期的正确方向，还是一个暂时的步骤？在我的梦想中，我想象着一个使用 CHERI 和使用 ARM Morello 实现的生产系统重新设计的未来 😊 无论如何，这比任何其他终端用户设备制造商目前所尝试的防御努力都要更大规模。

关键的是，本文并未直接考察从内核移动到外飞地的具体内容是什么。但是，构建图像表明，它们正在用于安全的摄像头/麦克风指示器、一些与Apple神经引擎相关的功能、一些设备驱动程序、与安全飞地通信的组件等等。未来可能还会有更多组件迁移到飞地，从中受益，外飞地的整体有效性可能取决于持续最大化其使用的努力。所有XNU之外仍在飞地之外的内容仍可能被修改。

我也怀疑，孤立计算节点可能被用于苹果的私有云计算系统中，以增强隐私保护以应对外部威胁，从而提供更强的隐私保护。

我特别想强调Dataflow Forensics的工作，他们没有源代码的帮助，对SPTM进行了更为深入的分析。我非常期待他们关于 exclaves 的承诺博客文章，我希望他们能解答许多剩余的问题，提供详细的反汇编说明，纠正我的错误和假设。

要做的事情（由比我聪明得多的人来）！

• ExclaveKit…
• ExclaveDriverKit…
• 真正的“XNUProxy”在哪里？
• 通过反汇编来确定XNU如何切换到安全世界，看看是否涉及SPTM和/或TrustZone…
• 关于安全内核的几乎所有内容…

• 几乎在安全世界用户空间中发生的所有事情…

  这是基于Apple的XNU开放源代码版本11215进行的分析。

我通过使用AI来改善我开头部分的写作技巧。