Newshot Secure Exclaves 与环境感知
我们最近推出了 HomeView，它最多可识别六个人，以提供丰富且个性化的体验。这项能力依赖于环境感知：使用麦克风和摄像头来理解周围环境，并识别已录入用户的声音和面部。我们一直认为，此类功能必须从底层设计起就保护用户安全与隐私，而现在我们正通过 Apple silicon 中专为环境感知构建的新安全架构，将这些保护进一步提升。这项工作既惠及我们最新的功能，也增强了我们已交付功能的安全性，例如“Hey Siri”检测。我们的目标是即使面对高度复杂的攻击也能保持环境传感器数据的安全，同时在传感器完全激活时，为用户提供清晰、可靠且防篡改的信号。
尽管环境感知依赖于处理来自摄像头或麦克风的输入，但它绝不能录制音频或视频，也不能将其暴露给操作系统其余部分。相反，它必须将传感器流简化为简单得多的信号，例如是否检测到特定声音，或是否识别出已录入用户的面部或声音，同时在处理期间保护原始传感器数据，并在完成后将其丢弃。
硬连线 LED 传感器指示灯易于理解，并在我们产品的隐私和安全中发挥重要作用，但不适合环境感知用例，因为它们会持续发光。这会削弱指示灯的作用，并使用户无法区分后台感知——例如设备正在监听“Hey Siri”唤醒——与主动音频和视频录制。相反，我们着手让环境感知在强隔离环境中运行，具备主应用处理器的完整性能，通过精确受控的接口接入系统其余部分，并采用安全指示机制，使用户在音频或视频数据被允许离开隔离边界时能够知晓。
为实现这一点，我们创建了 Secure Exclaves：受保护且分隔的运行时，用于与系统其余部分分开处理摄像头和麦克风数据。在芯片许多核心组件中加入的隔离功能协同工作，以保护 Secure Exclaves 并使其与系统其余部分隔离。在 Secure Exclave 中处理和分析的数据不能被主操作系统、应用或 Apple 访问。
我们使用 Secure Exclaves 来保护全新的用例，例如 HomeView 上的人物识别以及 Siri Recap 和 Live Rewind，如此处所述。我们还使用它们来保护 iPhone 18 Pro、iPhone 18 Pro Max 和 iPhone Duo 中使用的屏幕摄像头和麦克风指示灯，以及 MacBook Neo 和 HomeView 中的摄像头指示灯，全面提升用户的安全。
我们相信 Secure Exclaves 是业界最先进的环境感知架构，为这些用例定义了雄心勃勃的安全与隐私新水平。
Secure Exclaves 的架构
为了保护环境感知，我们旨在构建一个以两种不同模式运行的系统：针对摄像头和麦克风的环境模式和活动模式。在环境模式下，传感器可以响应周围世界中的特定触发条件，但只有特定元数据可以与系统其余部分共享。在活动模式下，完整传感器数据可以释放给主操作系统（OS），并且安全指示器会可靠地告知用户正在发生这种情况。
应对这一挑战最终需要构建一个新的隔离计算环境，它能够处理环境感知用例的全部性能需求，同时通过三项主要要求与主 OS 保持完全分离：
- 隔离：在 Secure Exclaves 中处理的数据不能从主 OS 中提取或修改。
- 受控接口：只有一组精确指定的信息可以从 Secure Exclaves 跨越边界进入主操作系统。
- 安全指示：用户必须能够看到是否有活动的传感器会话正在进行，且不受主操作系统干扰。
构建新的安全运行时需要高度安全的操作系统基础。为此，我们使用了 Apple 定制的 L4 微内核版本，该版本最初是为我们一些最安全敏感的部署而构建的，包括 Secure Enclave Processor（SEP）。这个微内核使用 capability，这是一种安全的资源句柄，既能标识底层资源，也能授权对底层资源的访问。这种简单但强大的机制同时应用于内存隔离和 IPC 安全，使我们能够构建一个不包含任何多余权限的安全系统。exclaves 微内核，以及我们对其正确性进行形式化验证的方法，将在本文后面详细介绍。
Secure Exclaves 在与主操作系统不同的处理器执行上下文中运行，这使我们能够采用一个独立操作系统，专门设计用于处理高安全、高性能工作负载。但隔离还要求谨慎处理应用处理器可用的所有共享资源：最重要的是系统内存以及与协处理器的通信。
为 Secure Exclaves 独占使用而隔离内存是一项严峻的工程挑战：页表的管理——页表用于组织和保护主设备内存——通常由主操作系统处理。我们在较早的版本中为隔离奠定了基础，将这个子系统划出并重建为 Secure Page Table Monitor（SPTM）：一个独立组件，负责页表和内存逻辑，并以高于主操作系统内核的权限级别运行。它不与主操作系统共享数据或代码，并由引导加载程序单独加载。这种重新架构不仅加固了整个系统以抵御某些内核级攻击，还为隔离 Secure Exclave 内存奠定了基础。
SPTM 依赖 Apple silicon 的原语来保护 exclaves 使用的内存免受系统其余部分访问。它管理应用处理器使用的每一个物理内存页，并强制在 Secure Exclaves 中执行的软件拥有与主操作系统所见内存分离且隔离的内存视图。微内核 capability 用于控制每个单独 exclave 的内存权限。这使每个 exclave 只能访问自己的内存，从而提供额外一层保护。
接下来，Secure Exclaves 必须考虑连接到 Apple silicon fabric 的其他协处理器和传感器。当某个协处理器对安全传感至关重要时，例如我们的 Always-On Processor（AOP），该协处理器操作系统内的一个安全隔区会处理与 Secure Exclaves 通信所需的工作。协处理器安全隔区同样构建在 exclaves 微内核之上，从而在应用处理器和协处理器之间保持安全保证的连续性。传感器内存等其他资源由专用内存过滤器保护，这些过滤器放置在每项资源与共享 fabric 之间，且只能由 SPTM 配置。这将内存隔离属性传播到整个系统。
Secure Exclaves 中运行的一些安全传感工作负载需要访问高性能推理硬件，以运行要求苛刻的机器学习模型。为此，我们扩展了 Apple Neural Engine（ANE），添加了隔离的工作负载队列，类似我们在 SEP 中使用的队列。内存过滤器保护这些队列不被主操作系统修改或访问，而从隔离队列切换到标准队列会刷新任何本地存储，以防止信息泄露。借助这些变化，我们可以提供高性能推理，为智能环境感知提供支持。
计算、内存和外设隔离技术叠加在一起，形成一个隔离但高性能的执行上下文。在这个上下文中，我们可以放置一个专用的安全操作系统，它能够访问麦克风和摄像头，并充分发挥 Apple silicon 的性能。
为了处理环境感知任务，Secure Exclaves 必须能够与主 OS 交换少量元数据。传统的进程间通信（IPC）机制为最大灵活性而设计，提供开放式接口，在移动数据时可以任意复杂地组合。对于 Secure Exclaves，我们从相反的角度处理这个问题，着手设计能够实现严格受限、完全可预测通信的 IPC 原语。
为此，我们构建了一种名为 Secure IPC 的新通信机制，用 Swift 编写以保证内存安全。它将接口描述语言与运行时结合起来，由运行时安全地连接允许通信的组件。所有 exclave 都使用 Secure IPC 相互通信以及与主 OS 通信。这种设计可防止组件之间出现意外串扰，并确保只有经授权的信息才能跨 IPC 边界流动。每个从 exclave 到主 OS 的 Secure IPC 接口都经过严格审计，以确保只有运行环境感知用例所需的最小元数据才能离开该 exclave。
微内核能力用于控制每个 exclave 的 IPC 连接。默认情况下，exclave 无法通信，甚至无法相互引用。只有当 exclave 拥有指向某个 IPC 连接的显式能力时，它才能发起 IPC。因此，Secure Exclaves 完全控制系统中的每个 IPC 接口和连接。exclaves 微内核与 Secure IPC 的结合使 Secure Exclaves 成为 Apple 有史以来创建的最安全运行时，我们已将其置于保障环境感知安全的核心。
当从环境感知转向完整的主动传感器用例（例如与 Siri 对话或 FaceTime 视频通话）时，系统必须告知用户，它现在正在与请求该传感器的 App 共享对传感器的广泛访问权限。我们基于现有的视觉语言来传达这一点——要么是 LED，要么是显示在屏幕上的指示点——但以全新的、业界尚无先例的高水平安全作为支撑。
一个名为 Exclave Indicator Controller 的专用 exclave 是传感器数据的整体系统守门人。只有在确认指示器已激活并已可见足够长时间后，它才允许数据流动。由于多个 App 可以同时请求音频和视频数据，Indicator Controller 会消除这些请求之间的冲突，并确保显示相应的指示器。
对于使用 LED 的 HomeView 等产品，只需要 Exclave Indicator Controller。它可以直接切换 LED，并确保其亮度足够高而可见。
对于使用屏幕上指示点的 iPhone 等产品，另一个 exclave 会确保每当系统共享完整传感器数据时该点可见。这个显示 exclave 使用显示子系统中的专用硬件模块来检查哪些像素已绘制到屏幕上。这种强制执行考虑了各种可能影响指示点外观的操作系统模式（如 Night Shift），并为其提供适配。它还确保这些像素满足最低亮度阈值，并且不会被附近的像素遮挡。显示控制器中的受信任固件与 exclave 共享精确的背光值，确保指示器对用户真正可见。
结合 Secure Exclaves 的隔离和受控接口组件，该系统提供了一种极其强大的机制，可安全处理高敏感工作负载。
HomeView 上的人员识别流程
为了说明这些组件如何协同工作，我们描述了在 HomeView 上使用摄像头进行人员识别的流程——这是一个由 Secure Exclaves 保护的环境感知用例。HomeView 必须始终被动执行最少的视觉处理，以检测视野中是否有人，但这绝不能使摄像头数据对更广泛的系统可用。Secure Exclaves 系统使人员识别能够快速且准确地进行，同时将环境视觉数据保护在 exclave 内。这意味着 HomeView 可以识别谁在使用它、对附近的移动做出反应，并根据用户在近处还是远处来显示内容。
启动时，人员识别 exclave 会从安全存储 exclave 加载先前已注册的面部和语音识别模型以及身份数据库 (1)。
连续的摄像头帧流被传递到摄像头 exclave，后者检测人脸、应用边界框，并将这些帧排队以进行进一步处理 (2)。摄像头 exclave 通知主 OS 中的守护进程可能有人存在；但是，没有任何图像数据离开 Secure Exclaves (3)。
同时，麦克风音频数据通过音频 exclaves 进行处理，用于异常检测和回声消除，然后被传递到人员识别 exclave (4)。如上所述，这些 exclaves 通知主 OS 中的守护进程可能有人存在，但不共享音频数据 (5)。
接下来，人员识别 exclave 请求 Neural Engine exclave 加载面部和声纹模型，以生成面部和声纹 (6)。所有数据始终保留在 exclave 控制的内存中，主 OS 无法访问。为此，Neural Engine 使用专用于 exclaves 的隔离工作队列，确保在每个模型完成后清除 Neural Engine 的状态。
最后，人员识别 exclave 内的编排服务将生成的面部和声纹特征与已注册用户的身份数据库进行匹配，并结合面部和语音识别以生成置信度分数。只有这些元数据——人员标识符、位置和置信度——会返回给在主 OS 中运行的人员识别守护进程 (7)。系统集成这些输出，使其正确地反映在依赖用户身份的功能中，例如 Calendar、Messages、Apple Music，或来自你 iPhone 的兼容第三方音频和视频 App (8)。在执行此识别过程时，不会与操作系统共享任何音频或视频数据。
iPhone 18 Pro 上的“Hey Siri”流程
我们还将描述最新 iPhone 机型上的“Hey Siri”流程，以展示这种新架构如何改善现有用例的安全性。手机必须始终被动执行最少的音频处理，以检测用户何时说出 Siri 的唤醒词。Secure Exclaves 系统使“Hey Siri”流程能够快速且准确地发生，同时将环境音频保护在 exclaves 内，直到活跃的 Siri 会话开始。
该流程始于 Always-On Processor (AOP)，这是一个持续监测唤醒词语音的低功耗协处理器 (1)。如果 AOP 上粗略的第一道过滤检测到潜在的“Hey Siri”，它会唤醒主处理器，并将音频缓冲区传递给音频 exclave (2)。这个 exclave 执行一次回声消除处理，使音频更清晰可懂，然后将音频传递给 Siri exclave (3)。
现在，Siri exclave 对音频运行第二轮处理，以确认实际上是否说出了唤醒词 (4)。这个模型更大且调优更精细——在主处理器上运行，使其能比 AOP 单独工作时过滤掉明显更多的误报。
如果这第二遍检测确认了唤醒词检测，Siri exclave 会通知运行在主操作系统中的 Siri 守护进程 (5)。此时不会与守护进程共享任何音频：只会传递它应被唤醒的标志。随后，Siri 守护进程通过向音频驱动请求麦克风访问权限来启动一个活动会话 (6)。驱动会调用 UI 绘制麦克风指示器 (7)，然后向 Exclave Indicator Controller (EIC) 请求音频访问权限 (8)。
EIC 要求安全显示 exclave 检查渲染到显示屏的像素——包括其颜色、形状和显示时长——是否都与麦克风指示器所期望的完全一致 (9)。如果该检查通过，系统就会从环境模式切换到活动模式。EIC 允许音频传输 (10)，Siri exclave 将包含“Hey Siri”的历史音频连同请求的其余部分发送给其守护进程 (11)。EIC 确保指示器一直留在屏幕上，直到 Siri 守护进程结束音频会话，且最短持续时间为三秒。
技术深入解析
本节将进一步介绍 Secure Exclaves 的基础机制，面向对系统实现的技术细节有特别兴趣的读者。
微内核通过最小化可信计算基（TCB）来构建大型安全系统；TCB 是维护系统安全所必须信任的那组代码。与 XNU 或 Linux 等在内核中处理硬件、网络和资源管理的传统内核不同，exclaves 微内核只实现运行和隔离应用服务所需的绝对最小功能。
虽然 exclaves 微内核是在 Apple 从零开发的，但其设计受到现代微内核研究的指导。它是一个基于能力的内核，类似 seL4 或 keyKOS，这意味着系统组件默认没有权限。相反，组件只有在被显式授予相应能力时，才能与其他组件或硬件交互。
由于 exclaves 微内核的 TCB 如此之小，Apple 得以逐步应用形式化验证，使用数学证明来验证内核的 C 实现完全按照高层功能规范所定义的方式运行。这一严谨流程已被证明在发现并消除核心子系统中微妙而关键的逻辑缺陷方面非常有效，否则这些缺陷可能导致内核被攻破：系统调用输入验证不完整、状态更新不一致、未对齐读取以及格式错误的页表更新。它还消除了一些 C 语言未定义行为类别。
为了与现有操作系统集成，该微内核实现了一种受 Composite 组件化操作系统启发的用户级调度模型。在该模型中，微内核依赖 XNU 出让 CPU 执行时间。当 XNU 调用微内核时，用户级调度器会执行相应的线程。当线程完成、发生定时器滴答或触发中断时，控制权会交还给 XNU，随后 XNU 可以再调用微内核以恢复执行。
在 exclaves 微内核之上构建 Secure Exclaves，使复杂系统服务能够作为隔离的用户级任务运行。该架构确保这些组件彼此之间以及与系统其余部分之间保持强隔离，防止一个服务被攻破时影响其他服务。
形式验证使用数学证明来表明系统满足我们定义的特定属性。在 Apple，我们在芯片开发中开展广泛的形式验证已超过 15 年，并在 2019 年开始使用形式验证来证明经典密码学，包括硬件公钥加速器（PKA）——Apple 芯片中执行椭圆曲线公钥运算的部分。最近，Apple 的密码学库 corecrypto 获得了量子安全 ML-KEM 和 ML-DSA 算法的实现。这些实现已经过形式验证，以确保它们忠实于 FIPS 203 和 FIPS 204 规范。
对于 exclaves 微内核——基于 exclave 的系统安全性的核心——我们利用同样的内部专业知识来形式验证我们的 C 实现满足抽象功能规范：对代码应做什么的精确数学描述。这提供了比常规软件测试所能提供的显著更高程度的保证；理论上，它使我们强烈相信，在证明适用的范围内，我们的实现完全按规范运行。实际考虑则更为复杂。无论以何种方式应用，形式验证都需要巨大的时间投入和深厚的专业知识。实现及其规范必须用精心选择的数学公式表示。要得出正确结论，公式必须忠实建模实现和规范的相关行为，并且其结构应使得证明能够以简单步骤写出。
由于 exclaves 微内核正在积极开发并频繁变化，我们的形式验证工作主要作为一种工具，用于发现深层的逻辑问题——例如，系统调用输入验证不完整、状态更新不一致、未对齐读取以及格式错误的页表更新。作为副作用，我们还表明，对于我们进行形式验证的代码，不存在某些类别的 C 未定义行为。虽然测试和模糊测试等其他方法有助于识别实现中的缺陷，并且通常是第一道防线，但形式验证已经能够在许多内核子系统中发现微妙但关键的问题，这些问题有可能导致整个内核被攻陷——例如，在用于释放能力存储对象（CNode）的递归算法中，在通过进程间通信（IPC）发送能力的实现中，以及在多处理器（SMP）系统上运行时的执行上下文（EC）状态管理中。得益于内核工程师与形式验证工程师之间的密切合作，其中许多问题在开发的早期阶段就被发现。由于这些持续变化，我们并不声称完整覆盖内核的所有方面；相反，形式验证是逐渐、增量地应用于不同部分的。为此，我们依赖 Isabelle/HOL 与 AutoCorres2，从 C 源代码构建内核实现的数学模型，并针对该模型进行形式验证。
exclaveOS 构建在 exclaves 微内核之上，创建一个与 XNU 和 Darwin 用户空间隔离的环境。可直接访问捕获敏感个人信息设备（如摄像头和麦克风）的软件，与管理对 exclaveOS 访问的软件一起被放入 exclaveOS。运行在 Darwin 中的驱动程序、守护进程和应用程序必须通过 exclaveOS 中的访问管理软件进行调用，才能访问这些设备。
XNU、Darwin 用户空间和 exclaveOS 中的所有软件都在应用处理器核心上执行。当 Darwin 中的用户级代码或内核内驱动程序希望与 exclaveOS 中的软件通信时，它会执行远程过程调用（RPC）。该调用经由 XNU 内核传递给 exclaveOS 一侧的特定软件单元，后者随后可以在处理该 RPC 的过程中与 exclaveOS 的其余部分交互。
由于每个 RPC 都是代表曾在 XNU 线程上运行的代码来处理的，因此 exclaveOS 中处理该 RPC 的代码运行在同一个 XNU 线程上。这意味着 XNU 负责调度 exclaveOS 中运行的所有代码，从而使 exclaveOS 受益于 XNU 调度器提供的全部优化。每当 exclaveOS 中的代码被抢占或进行同步时，该代码的状态都会由微内核捕获；exclaves 中的用户级调度器只向 XNU 提供足够的信息，以同步相关线程并在之后恢复执行。
Darwin 和 exclaveOS 都包含小型的可信组件，用于管理对资源的低层访问，主要方式是限制双方分别被允许直接映射和访问哪些物理内存与设备内存。SPTM 控制 XNU 和 Darwin 用户空间被允许访问的内容，而 exclaves 微内核控制 exclaveOS 中的软件被允许访问的内容。这两个组件相互信任对方会执行另一方所依赖的访问限制，从而构成双方之间最低层的边界，并协作管理共享处理器核心上的执行。
Secure Exclaves 具有一种文件存储协议，旨在防止 XNU 与 exclaves 之间以及各个 exclave 之间出现未经授权的通信通道。文件系统访问不是默认假定的——它在系统配置中静态表达，并且只授予真正需要它的组件。
文件访问可以是只读的，文件系统中还存在专用的、仅限组件使用的读写区域。所有只读文件都会根据随操作系统一起提供的完整性目录进行检查。所有可写文件只能由写入它们的 exclave 读取，并且所有写入都会被加密。
为启动 exclaves，iBoot 会将 exclaves 微内核、一个初始静态代码包，以及用于文件系统只读部分的完整性目录放入 wired memory。可动态加载代码的签名会在启动时被读取，并与完整性目录进行比较。在运行时，为加载系统的动态组件，代码会从只读文件系统读取，然后在变为可执行之前根据内存中的签名进行验证。任何未随 Secure Exclaves 一同提供的代码都无法执行。
exclaveOS 是我们用于在微内核之上运行敏感代码的操作系统和运行时。作为一个基于微内核的操作系统，exclaveOS 将大多数操作系统功能实现为用户级服务器，每个服务器都只具备运行所需的最小能力集。exclaveOS 的很大一部分使用 Swift 编写，以获得内置的内存安全性。该操作系统建立在几个关键概念之上：
- 静态的、构建时系统描述，用于描述系统中的所有地址空间、它们可以访问哪些资源以及它们如何通信。
- root task，负责建立初始系统，然后释放自身。
- ExclaveCores，实现系统服务和驱动程序的静态生命周期地址空间。
- ExclaveKits，动态生命周期地址空间，与一个 Darwin daemon 归组在一起并形成一个 conclave。
在启动时，exclaveOS root task 运行，按描述创建所有 ExclaveCore 地址空间，并分发相关内核能力。分发的资源中包括通向其他地址空间的通信端点。启动之后，root task 被销毁，在地址空间之间创建新连接的能力被不可逆地从运行中的系统中移除。
ExclaveKit 地址空间的创建和销毁不是由根任务完成的。相反，每个 conclave 都有一个关联的 ExclaveCore，称为 conclave launcher。每个 conclave launcher 维护与 XNU 的连接，以便其对应的 daemon 可以调用它来在其 conclave 中创建 ExclaveKit 地址空间。如果 daemon 被终止，XNU 会调用该 daemon 的 conclave launcher 来终止该 daemon 的 ExclaveKit 地址空间。重要的是，虽然 conclave launcher 可以创建和销毁地址空间，但它不能创建地址空间之间的连接，而是必须使用根任务在启动时给它的现有连接。
一旦根任务被销毁，系统中剩余的任何部分都不再拥有如此广泛的权限。例如，根任务将管理物理内存的能力授予物理内存服务器，但限制该能力，使得通过它映射的内存只能以只读或读写方式映射。另一方面，将物理内存的读-执行（但不可写）访问权分发出去的能力被授予代码加载服务器。系统中的每个组件都可以从物理内存服务器请求内存，但只有 conclave launcher 连接到代码加载服务器。
exclaveOS 在 exclaves 微内核提供的能力模型之上放置了一个组件架构。这些组件之间的通信由 Secure IPC 处理。
Secure IPC 是一个用于描述软件组件及其提供的接口，并在运行时管理其行为的系统。组件之间以及进出 exclaveOS 的所有通信都由 Secure IPC 处理。组件接口提前用一种类型安全的描述语言描述，允许系统周围的 RPC 数据流在运行之前被审计和批准。
该系统包含四个主要部分：
- 一种接口描述语言（IDL），用于描述组件、它们提供的服务以及客户端可以在它们上调用的方法。
- 一个编译器，它接受 IDL 描述作为输入，并生成实现这些接口的源代码。
- 一个组件运行时，负责组件的初始化和管理。
- 一个 RPC 运行时，将 Secure IPC 所基于的 IPC 系统从编译器生成的代码中抽象出来。
Secure IPC 用于描述 exclaveOS 中所有软件的接口，使得所有 RPC 数据的移动可以在构建时被审计和理解。在运行时，系统描述被根任务用来为每个地址空间的组件只提供它们构建预先批准的 RPC 链接所需的能力。这种严格的构建时接口声明以及运行时一次性的 RPC 链接构建，使得系统周围的数据能够进行静态的、类型安全的传输。
Secure IPC IDL 是一种类似 Swift 的类型安全语言，其中接口使用标量值、结构和枚举来描述。这些用于声明方法以及它们所属的服务。组件通过实现一组服务以及在它们的初始化器中声明它们自身作为客户端的服务，将一切连接在一起。
例如：
enum PlaybackStatus { case stopped = 1 case playing = 2}
struct TrackInfo { let trackIdentifier: UInt64 let status: PlaybackStatus}
service PlaybackController { func play(_ position: UInt64) -> Bool func stop() func getTrackInfo() -> TrackInfo}
component MediaPlayer: PlaybackController { init(audioOutput: AudioOutputController)}
Secure Exclaves 与环境感知
Secure IPC 编译器接收每个组件的这些 IDL 文件，然后生成 Swift 以及可选的 C 源代码，为这些文件所描述的软件提供运行时接口。生成的实现针对接口中使用的每种类型，使用一组经过审核的单一编码和解码方法，从而将系统中任意数据的处理完全集中化。
在 exclaveOS 中，软件的初始化和管理完全由操作系统处理。启动时，Secure IPC 组件运行时存在于每个 exclaveOS 地址空间中，根任务将构建时生成的数据以及诸如端点能力之类的运行时句柄交给它。Secure IPC 将这些数据传递给编译器构造的组件初始化器，以创建它们的运行时实例。随后，运行时负责通知组件实例有新客户端到达或离开，例如，一个 ExclaveCore 组件被告知某个 conclave 中的客户端已启动或退出。
在最底层，Secure IPC 与它运行所在的操作系统交互，以在组件和服务实例之间移动 RPC 数据。在 exclaveOS 中的组件之间通信时，Secure IPC 将消息编码到微内核 IPC 缓冲区中，并调用附加到该服务的端点能力。随后，同一个运行时还用于管理从运行于 Darwin 用户空间的守护进程到其运行于 exclaveOS 的 conclave 的数据传输；在这种情况下，它会将数据编码到一个缓冲区中，并通过系统调用将其交给 XNU。
SPTM 是一段高度特权的软件，它定义并强制执行安全策略，这些策略管控内核、用户应用和协处理器的页表管理。其意图是通过在不信任内核的情况下保护页表免受攻击者攻击，来保护整个系统。在受 SPTM 保护的产品上，内核不能自行写入页表项。每一次映射更改都是对 SPTM 的请求，SPTM 会在应用之前根据策略对其进行验证。
为了在这一层级强制执行安全策略，SPTM 必须拥有与 CPU 和 IOMMU 页表管理相关的所有架构状态。这涵盖页表本身、管理它们的数据和代码，以及 VMSA（Virtual Memory System Architecture）寄存器和 IOMMU 转换控制寄存器。SPTM 通过将自身置于一种独立的、更高特权的执行模式中来实现这一点，该模式由硬件与内核隔离；并且通过保护所有支撑页表和辅助数据结构的存储器，使得即使内核本身也无法修改它们。
SPTM 使用强大的类型系统管控暴露给应用处理器的每一页 DRAM。每一页都有一个关联类型，并且可以在受允许转换的允许列表和安全策略决策约束的情况下，被重新类型化为另一种类型。映射到用户空间进程中的页携带一种类型，而作为内核私有内存后备的页可以携带一种受策略约束明显更多的类型，例如，这种类型只允许该页存在单一内核映射。
这种类型系统集中使 SPTM 能够定义给定页类型的所有者、映射权限和策略，这些必须在 SPTM、XNU 内核和 Secure Exclave 各执行上下文下执行时适用。结果是每个上下文都有单独的权限视图，并由 Apple silicon 在硬件层面强制执行。
SPTM 结合 Apple 芯片安全方面的进展，为我们各平台上的现代安全内存管理原则提供了基础。在这一设计下，Secure Exclave 私有内存被分配为只有 Secure Exclave 上下文才拥有的类型。OS 内核无法重新指定这些页面的类型，也无法将它们映射到另一个 CPU 或 IOMMU 地址空间，或以其他方式获得读取其内容的路径。甚至 SPTM 本身，按设计也不保留对该内存的映射。这在 kernel 与 Secure Exclave 私有内存资源之间实现了清晰的隔离。
结论
我们相信 Secure Exclaves 为业界树立了操作系统安全的新标准。这一高性能、高保障的系统能够处理环境感知中最严苛的工作负载，同时为设备传感器采集的音频和视觉数据提供卓越级别的保护。没有任何安全架构是已经完成的，Secure Exclaves 也不例外。我们致力于继续加固这一系统，并借助 AI 加速的漏洞研究与扩展的形式化验证覆盖来推动这项工作。随着我们的产品为用户带来日益智能的功能，我们认为 Secure Exclaves 是关键一步，让用户清楚了解并确信他们的 Apple 产品如何回应周围的世界。