苹果设备内存安全的完整愿景：内存完整性强化
Memory Integrity Enforcement (MIE) 是我们历时 50 年、前所未有的设计和工程努力的结晶，它将 Apple 芯片硬件的独特优势与我们先进的操作系统安全性结合在一起，为我们的设备提供业界首创的、始终在线的内存安全保护，而不会影响我们同类最佳的设备性能。我们相信，“内存完整性强化 ”是消费类操作系统历史上对内存安全的最重大升级。
针对 iPhone 的恶意软件攻击从未有过成功和广泛的案例。我们在野外观察到的唯一系统级 iOS 攻击来自于雇佣间谍软件，它比普通的网络犯罪活动和消费级恶意软件复杂得多。雇佣间谍软件历来与国家行为者有关，它使用耗资数百万美元的漏洞链来攻击极少数特定个人及其设备。虽然绝大多数用户不会以这种方式成为攻击目标，但这些漏洞利用链在任何时候都展示了一些最昂贵、最复杂和最先进的攻击者能力，在我们努力保护 iPhone 用户免受最复杂的威胁时，这些漏洞利用链是独一无二值得研究的。已知的针对 iOS 的雇佣军间谍软件链与针对 Windows 和 Android 的间谍软件链有一个共同点：它们利用内存安全漏洞，这些漏洞可以互换、功能强大，而且存在于整个行业。
对于苹果公司来说，提高内存安全是一项广泛的工作，包括使用安全语言进行开发和大规模部署缓解措施。(有关我们如何考虑内存安全的初步介绍，请参阅 本篇博文 的开篇)。我们创建了 Swift，这是一种易于使用的内存安全语言，我们将其用于新代码和有针对性的组件重写。在 iOS 15 中，我们引入了用于内核的安全内存分配器 kalloc_type，随后又在 iOS 17 中引入了用户级对应的 xzone malloc。这些安全分配器利用了了解分配类型(或分配目的)的优势，从而以一种使利用大多数内存破坏漏洞变得固有困难的方式组织内存。
2018 年，我们在业内率先在 A12 Bionic 芯片中部署了指针验证码 (PAC)，以在内存损坏的情况下保护代码流的完整性。这一防御机制在增加漏洞利用复杂性方面取得了巨大成功，毫无疑问，软件和硬件安全的深度整合将是解决我们面临的一些最大安全挑战的关键。有了 PAC 的支持，我们立即开始了设计和评估工作，以找到最有效的方法将复杂的内存安全功能直接内置到苹果芯片中。
Arm 于 2019 年发布了Memory Tagging Extension (MTE)规范，作为帮助查找内存损坏 bug 的硬件工具。MTE 的核心是内存标记和标记检查系统，其中每个内存分配都标记了一个秘密；硬件保证，只有在请求包含正确秘密的情况下，才会批准以后访问内存的请求。如果密文不匹配，应用程序就会崩溃，事件也会被记录下来。这样，开发人员就能在内存损坏错误发生时立即识别出来。
我们进行了深入的评估和研究，以确定所设计的 MTE 能否实现硬件辅助内存安全的目标。我们的分析发现，在作为实时防御措施使用时，最初的 Arm MTE 版本存在我们无法接受的缺陷，因此我们与 Arm 合作，在 2022 年发布的新增强内存标记扩展(EMTE) 规范中解决了这些缺陷。更重要的是，我们的分析表明，虽然 EMTE 在规范中具有巨大潜力，但如果能在硬件和操作系统的深度支持下严格实施，就能实现突破，产生非凡的新安全机制。
考虑到 MTE 可以配置为同步或异步报告内存损坏。在后一种模式下，内存损坏不会立即引发异常，这就为攻击者留下了一个竞赛窗口。我们不会实施这种机制。我们认为，内存安全保护需要严格同步、默认开启并持续工作。但是，要在关键攻击面上支持始终开启的同步 MTE，同时保持出色的高性能用户体验，对硬件的支持要求极高。
此外，为了让 MTE 在对抗环境中提供内存安全性，我们需要对操作系统进行微调，以保护 MTE 所依赖的新语义和内存标签的机密性。最终，我们决定，要提供真正一流的内存安全性，我们将在整个苹果公司开展大规模的工程设计工作，包括更新苹果芯片、操作系统和软件框架。这一努力，加上我们非常成功的安全内存分配器工作，将把 MTE 从一个有用的调试工具转变为一个开创性的新安全功能。
今天，我们将介绍这一努力的成果： Memory Integrity Enforcement (MIE)，我们为苹果平台提供的全面内存安全防御。Memory Integrity Enforcement 建立在我们的安全内存分配器所提供的稳健基础之上，与同步模式下的增强内存标记扩展(EMTE)相结合，并得到广泛的标记保密性执行策略的支持。MIE 内置于所有型号 iPhone 17 和 iPhone Air 的 Apple 硬件和软件中，为包括内核在内的关键攻击面提供了无与伦比、始终在线的内存安全保护，同时保持了用户所期望的强大功能和性能。此外，作为今年早些时候在 WWDC 期间发布的新增强安全 功能的一部分，我们将在 Xcode 中向所有 Apple 开发人员提供 EMTE。
本篇文章的其余部分将深入探讨设计和验证内存完整性强制机制所需的大量工程工作。
设计内存完整性强化功能
内存完整性强制执行始于我们的安全内存分配器–kalloc_type、xzone malloc 和 WebKit 的 libpas–所有这些分配器都使用 type information 来决定如何组织内存分配。对于 “无限制使用 ”和 “越界 ”漏洞，攻击者的目标是创建对内存的重叠解释，他们通过控制某些特定类型分配的精确位置来实现这一目标。正如我们在kalloc_type post中所描述的，我们的安全内存分配器的类型感知放置策略有助于挫败这些内存破坏技术。我们的安全分配器为防止内存破坏的软件保护设定了新的高标准，同时还保持了与被它们取代的分配器相同甚至更好的性能。
分配器只能在内存页面(iOS 上为 16KB)的粒度上应用保护，这自然适合多页面分配。对于较小的分配，我们的安全分配器可以使用页面级保护，帮助防止不同类型桶之间的内存损坏攻击。不过，页面级保护过于粗糙，无法抵御同一类型桶内的攻击，因此我们使用内存标记来弥补这一缺陷。
让我们来看看 EMTE 如何用于防范两种最常见的内存破坏类型：缓冲区溢出和使用后释放漏洞。对于缓冲区溢出，分配器负责为相邻的分配使用不同的标记。如果访问内存的请求溢出到具有不同标记的相邻内存，硬件就会阻止它，操作系统就会采取行动并终止进程。下面我们用三个相邻的分配来直观地表示这种情况，它们分别标记了三个不同的秘密：⏺️、🔼 和 ⏹️。两次带有🔼标记的访问尝试都被允许访问带有🔼标记的内存，但第三次访问尝试却被阻止，因为它溢出到了相邻的、带有 ⏹️ 标记的分配中。
内存完整性执行阻止缓冲区溢出
当内存被重新用于其他用途时，分配器还负责重新标记内存。在下图中，🔼 分配在被系统释放并重新分配后，会被重新标记为 ⏹️。如果使用较旧的🔼 标记请求重新标记的内存，就像在使用释放后内存漏洞中看到的那样，硬件就会阻止它，并让操作系统采取进一步措施。
内存完整性执行阻止 “使用后释放 ”访问
原始 MTE 规范的一个关键弱点是，硬件不会检查对非标记内存(如全局变量)的访问。这意味着攻击者在试图控制核心应用程序配置和状态时，不必面对那么多防御约束。有了增强型 MTE，我们规定从标记内存区域访问非标记内存需要知道该区域的标记，这样攻击者就很难将动态标记内存中的越界错误转化为通过直接修改非标记分配来规避 EMTE 的方法。
最后，我们还开发了标签保密性强制机制(Tag Confidentiality Enforcement)，以保护我们的安全分配器免受技术威胁，并保护 EMTE 标签的保密性，包括防止侧信道攻击和投机执行攻击。
我们的类型化分配器和 EMTE 都依赖于内核数据结构对用户应用程序的保密性，以及分配器所选标记的保密性。攻击者可能会试图通过泄露这些机密来击败 EMTE，进而击败内存完整性强制执行(Memory Integrity Enforcement)。为了保护内核分配器的后备存储和标记存储，我们使用了安全页表监控器，该监控器即使在内核受损的情况下也能提供强有力的保证。我们还确保内核代表应用程序访问内存时，采用与用户空间相同的标记检查规则。
基于投机执行的攻击也可以用来暴露秘密。为了提高性能，现代 CPU 会预测先前指令(可能延迟更长)之后指令的执行情况。如果预测正确，计算速度就会非常快。如果预测错误，CPU 就会丢弃预测，计算速度就会变慢。不幸的是，被丢弃的预测会产生可观察到的影响，从而泄露系统状态和数据。由于投机性攻击在使用过程中永远不会导致系统崩溃或以可观察到的方式出现异常，因此它们对攻击者特别有用。例如，在我们最初的指针验证码(PAC)实现中，评估指针验证指令会投机性地暴露时序差异，这将使有效签名被隔离。在内存完整性强制执行的设计阶段，我们发现并解决了可能破坏标签机密性的三个推测性漏洞。
首先，当 EMTE 启用时，访问内存的请求会导致硬件检查标签。至关重要的是，在对标签检查指令进行推测评估时，不能暴露出时序差异，从而使攻击者能够隔离有效标签。从一开始，我们就设计了苹果芯片实现，使标记值不会以任何方式影响推测执行。最近发布的安全研究 表明，谷歌 Pixel 设备上的 MTE 实现易受此类攻击的影响，从而使 MTE 在谷歌 Chrome 浏览器和 Linux 内核中被绕过。
其次，分配器会为内存分配随机标签，攻击者一定无法预测系统将选择的标签值。为了解决这个问题，我们经常对用于选择新标签的底层伪随机发生器进行重新播种。
第三，Spectre 变种 1 (V1)是一个投机执行漏洞，允许攻击者利用条件分支泄漏数据，包括 MTE 标记值。迄今为止，消费级操作系统还没有解决这一问题的方案，因为一般的 Spectre V1 缓解措施(如 Speculative Load Hardening)的 CPU 成本过高。EMTE 的存在使 Spectre V1 成为攻击者最后一个可用于引导攻击的途径，因此我们设计了一种全新的缓解措施，以几乎为零的 CPU 成本限制 Spectre V1 泄露的有效范围，并迫使攻击者与类型隔离作斗争。这种缓解措施使攻击者使用 Spectre V1 变得不切实际，因为他们通常需要 25 个或更多的 V1 序列才能达到 95% 以上的可利用率–除非其中一个序列与被利用的漏洞有关，这与我们的 kalloc_type analysis的推理类似。
我们对内存完整性强制执行的使命是在默认情况下保护所有用户，并对内存损坏漏洞的利用提供非同寻常的破坏。为此，我们考虑了广泛的威胁，包括一些最具挑战性的威胁(如侧信道)，最终实现了这一广泛的功能组合，这是其他 MTE 实现所不具备的。去年，谷歌迈出了伟大的第一步，他们为那些选择加入高危用户计划的用户提供了 MTE。但是，即使是对开启了 MTE 的用户而言，安卓系统上 MTE 的有效性也受到了限制，因为它缺乏与操作系统的深度集成，而这正是内存完整性强化技术及其在苹果芯片上使用 EMTE 的不同之处。
为了让全新的 A19 和 A19 Pro 芯片支持内存完整性强制执行，我们在安全方面投入了大量的 Apple 芯片资源，包括 CPU 面积、CPU 速度和用于标签存储的内存，投入之大前所未有。为了充分实现这项硬件投资，我们将 MIE 的所有新操作系统元素与硬件工作结合起来设计，包括安全分配器、EMTE 和标签保密保护。
由于 EMTE 标签检查会带来性能成本，因此我们在设计内存完整性强制执行系统时，首先利用了安全分配器的优势，并使用 EMTE 仅保护类型桶内较小的单个分配，而软件分配器无法单独保护这些分配。然后，通过了解部署 EMTE 的位置和方式，我们可以准确模拟操作系统的标签检查需求，并设计我们的芯片来满足这一需求。我们的硬件实现影响了其他软件设计决策，进一步降低了标签检查的开销。重要的是，以这种精确度部署 EMTE 支持我们的策略，即尽可能为不支持 EMTE 的前几代 iPhone 用户提供更多内存安全改进。
为了对内存完整性强制执行进行安全评估，我们从一开始就让我们的进攻研究团队参与其中。从 2020 年到 2025 年，他们不断对系统进行分析和攻击–首先是概念上的理论攻击，然后是模拟环境中的实际攻击，最后是在新硬件原型上的攻击。进攻研究团队的长期参与使我们能够在攻击者发现整个攻击策略和技术之前将其识别和消除，从而从一开始就拥有更强大、更成熟的功能。
我们的攻击研究团队确定了攻击者最有可能入侵系统的位置和方式，我们的内存完整性强制措施部署就是以他们的研究成果为指导的。值得注意的是，这包括确保这种强大的新保护措施适用于可能成为攻击者入口的第三方应用程序，如社交网络、消息应用程序或任何其他可针对特定用户的应用程序。随着 MIE 的推出，任何开发人员都可以立即开始测试其应用程序的强大保护功能，包括使用 Xcode 中的Enhanced Security设置在支持 EMTE 的硬件上测试 EMTE。
内存完整性强制执行 “的精心规划和实施使我们能够为平台上所有要求苛刻的工作负载保持同步标签检查，以最小的性能影响提供突破性的安全性，同时对用户完全不可见。
安全性评估
Memory Integrity Enforcement(内存完整性强化)有一个雄心勃勃的目标：让开发和维护基于内存破坏的针对我们平台的雇佣间谍软件攻击变得更加昂贵和困难。虽然没有十全十美的安全措施，但 MIE 的设计旨在极大地限制攻击者及其在利用过程中的自由度。
在内存完整性强制执行的整个设计和实施过程中，我们的攻击研究团队通过研究以前针对我们平台的复杂利用链、最近的漏洞和我们自己的内部研究，评估了我们的进展。首先，我们致力于重建和调整以前见过的漏洞利用链，使其适用于受 MIE 保护的系统。但只考虑 MIE 出现之前开发的利用链是不够的，因为攻击者肯定会针对这些新的保护措施进行调整。因此，我们还评估了一些我们认为最有可能在 MIE 中幸存下来的最新漏洞。对于这些漏洞，我们仔细列举了所有可能的利用机会，这与我们对 SockPuppet against kalloc_type 的评估类似。
两种方法都得出了相同的结论： 内存完整性强制措施大大减少了攻击者可以利用的策略。虽然内存损坏漏洞通常是可以互换的，但 MIE 从根本上切断了许多漏洞利用步骤，以至于无法通过交换新漏洞来恢复漏洞链。即使付出巨大努力，我们也无法重建这些链条，以绕过 MIE。剩下的几个内存损坏效应并不可靠，无法为攻击者成功利用这些漏洞提供足够的动力。
下面是攻击者的直观感受。下图代表了我们评估过的六个实际漏洞利用链，并显示了内存完整性强制执行(安全分配器、EMTE 或两者)阻止攻击的步骤。
内存完整性实施与真实世界漏洞链对比
值得注意的是，攻击者在利用过程的早期就会遇到内存完整性强制措施。虽然有些问题(例如分配内缓冲区溢出)能够在内存完整性强制执行中存活下来，但此类问题极为罕见，而能够被完全端到端利用的问题更是少之又少。不可避免的是，攻击者必须在其能力仍然非常有限的阶段面对 MIE，这使得可行的利用途径寥寥无几。这就导致了脆弱的链条，只要破坏一个步骤，往往就足以使整个利用策略失效。当这种情况发生时，链上的大部分组件都无法重复使用，攻击者不得不利用全新的漏洞重新开始开发。
结论
iPhone 拥有业界领先的安全性，这意味着绝大多数用户的设备从未受到过系统级攻击。我们在内存安全方面的工作主要是针对雇佣军间谍软件和监控行业，他们花费数百万美元利用内存损坏漏洞，针对少数人，因为他们是谁，他们做什么。在过去的五年中，我们开发了一种全面的内存安全方法，整合了我们最好的硬件和软件能力，今天的宣布是这一宏伟愿景的顶点。随着 iPhone 17 系列和 iPhone Air 的推出，我们很高兴能提供内存完整性强制执行功能：业界首个全面、始终在线的内存安全保护功能，覆盖关键攻击面(包括内核和 70 多个用户态进程)，基于增强内存标记扩展 (EMTE)，并由安全类型分配器和标记保密保护提供支持。
根据我们对内存完整性强制系统与过去三年中异常复杂的雇佣间谍软件攻击进行的评估，我们相信 MIE 将大大提高漏洞利用链的开发和维护成本和难度，破坏过去 25 年中许多最有效的漏洞利用技术，并彻底重新定义苹果产品的内存安全格局。我们相信，内存完整性强化技术将大大降低攻击者利用我们设备上内存损坏漏洞的能力，是消费类操作系统历史上对内存安全的最重大升级。
本文文字及图片出自 Memory Integrity Enforcement: A complete vision for memory safety in Apple devices
两种方法都得出了相同的结论： 内存完整性强制措施大大减少了攻击者可用的漏洞利用策略。虽然内存损坏漏洞通常可以互换，但 MIE 从根本上切断了许多漏洞利用步骤，以至于无法通过交换新漏洞来恢复漏洞链。即使付出巨大努力，我们也无法重建这些链条，以绕过 MIE。仅存的一些内存损坏效应并不可靠，无法为攻击者成功利用这些漏洞提供足够的动力。
这一点很好，而且有点埋下了伏笔。雇佣间谍软件的部分经济效益依赖于可互换部件的链条，直接针对这一特性的对策非常有趣。
就苹果公司的克里姆林宫学而言，这应该被看作是向CHERI(https://en.wikipedia.org/wiki/Capability_Hardware_Enhanced_R…)这样的基于能力的全面内存安全迈出的一步，还是更应该被看作是苹果公司发出的信号：它认为没有CHERI这样的东西也可以过得去？
在我看来是后者；CHERI 需要在编译和链接层进行大量繁重的工作，这限制了应用程序代码的行为，并对微体系结构进行了巨大的改动。另一方面，堆ookies/标签机密可以在运行时委托给分配器，如 MIE / MTE，现有的组件级构件(如 SPTM)可以提供部分保证，而不需要整个并行内存架构来实现 CHERI 所要求的功能。
MTE 和 CHERI 是如此不同，以至于很难，甚至不可能同时做到这两点(在 CHERI 128 位 ptr 中可能没有足够的空闲位用于 MTE 标记)。
它们还意味着系统结构的截然不同。
当然，我并不是说苹果公司真的可以同时实现这两种功能。不过，他们现在可以采用负担较轻的方法，同时打算以后用另一种方法取而代之。
找到你了。我关于不同系统架构的观点让我觉得你不太可能想这么做。
> MTE 和 CHERI 是如此不同，以至于很难甚至不可能同时做到这两点(在 CHERI 128 位 ptr 中，你可能没有足够的空闲位来使用 MTE 标记)。
如果有 CHERI，为什么还需要 MTE？
如果有不需要第二条总线的有效缓解措施，为什么还需要 CHERI？
我认为这是一枚硬币的两面，苹果选择了硬币的另一面。
这两个系统在很大程度上是正交的；我认为，如果苹果选择从一个系统转向另一个系统，那将是一代人的改变，而不是渐进的改变。MTE/MIE 的优势在于你可以通过改变分配器提供的高位来逐步实现；而 CHERI 则需要根本性的模式转变。苹果公司喜欢范式转换，但没有迹象表明他们会在这里进行范式转换；如果他们这样做了，那将是一项单独的工作。
CHERI是确定性的。
从理论上讲，这确实更好。
(你也可以说不是。)
FWIW (与您相比，我是个无名小卒；我没有做 FIL-C 🙂 ) – 我认为 MIE/MTE 实际上优于 CHERI。
我还认为这个论点很有说服力，因为一个存在于数以百万计的消费者硬盘中，一个不存在于数以百万计的消费者硬盘中(MTE -> MIE)。
第二条总线？
CHERI 从根本上依赖于内存中的功能，而内存在架构上与程序内存是分离的。你可以使用总线防火墙来实现这一点，但这样你就和使用 SPTM 的 MIE 站在了同一起跑线上。
所以是为不属于正常程序池的分页表内置 RAM？这样，无论你使用何种攻击手段，用户空间都无法传递指向它的指针？
并不是说两者都要。只是回答为什么 MTE 不是通往 CHERI 的途径。
但这里有一个两者都要的理由： CHERI的UAF故事并不精彩。加入 MTE 意味着你至少可以得到一个概率故事
没错！反过来说，MTE 在对象内部损坏方面很糟糕：如果我访问了一个带指针的堆对象，MTE 不会影响我，我可以继续写入该对象，因为我拥有该标记。
总的来说，我的看法是，CHERI 以巨大的代价取得了巨大的成功，而 MTE 则以较低的代价取得了巨大的成功。但是，每个系统都有各自擅长的弱点。
我认为内部对象问题可能很小众，不重要。
而 CHERI 只能选择性地解决这个问题，如果你能接受需要修改更多代码的话。
我想我大致同意你的观点。在我看来，标签实际上比像 CHERI 这样的能力系统更有价值。
是的，但 CHERI 开辟了全新的系统设计可能性，包括超廉价的_intra_-address-space 安全边界等。参见 https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/201607…
> 我们以CHERI的ISA设施为基础，建立了一个软件对象能力模型，支持比当前设计更高的分隔性能和粒度。我们利用这些能力建立了一种硬件-软件领域转换机制和编程模型，适用于互不信任的软件之间的安全通信。
和 https://github.com/CTSRD-CHERI/cheripedia/wiki/Colocation-Tu…
> 进程是 Unix 的天然隔间，许多现有软件都使用了这一模型。问题是，进程是重量级的；通信和上下文切换的开销使得使用进程进行细粒度分隔变得不切实际。Cocalls 速度很快(比函数调用慢一个数量级，比最便宜的系统调用快一个数量级)，旨在解决这个问题。
该功能围绕两个函数展开：调用方(客户端)的 cocall(2) 和被调用方(服务)的 coaccept(2)。这两个函数使用了 CHERI 魔法，以 CInvoke / LDPBR CPU 指令的形式实现，无需进入内核即可切换保护域，但从 API 用户的角度来看，它们大多看起来像普通的系统调用，并遵循相同的约定，如 errno 等。
随着新的系统架构可能性的出现，我们有很大的机会将为 CHERI 所付出的性能成本连本带利地收回来。
MTE 帮助我们确保现有架构的安全。CHERI 使新架构成为可能。
是的，但这会破坏镜像映射。
不过 UAF 取得了一些进展！https://dl.acm.org/doi/10.1145/3703595.3705878
警戒实验室的逝去
好吧，有点激烈，我真的不知道这会不会影响到他们。
我认为他们会印制钞票帽，但我们拭目以待。请记住：北约友好情报和执法机构为这项技术支付的费用并没有一个现实的上限；它与人类情报竞争，而人类情报的价格高得吓人。
> This is great …
这是苹果公司，这是谷歌公司(从早期的 Chrome 浏览器/Android 时代就开始从事内存安全工作)：
https://news.ycombinator.com/item?id=39671337
谷歌安全(例如：TAG 和 Project Zero)在处理 CSV 方面做了大量工作，但在 MTE 方面却严重失误。
这是丹尼尔-柏林(Daniel Berlin)发表的一篇文章，解释了为什么谷歌最初没有在 Android 上全时启用 MTE。它明确承认，让每个人都启用 MTE 可以阻止漏洞。
> 我们认为内存安全保护需要严格同步、默认开启并持续工作。
FWIW, I presume this is “from experience”–rather than, from first principles, which is how it comes off — as this is NOT how their early kernel memory protections worked ;P. 2015 年，在 iOS 9 中，苹果发布了内核补丁保护(KPP)，它可以异步验证内核是否被修改过，而且频率并不高，因为我推测这是一项昂贵的检查，如果检测到损坏，就会慌乱。
https://raw.githubusercontent.com/jakeajames/rootlessJB/mast…
> 首先，让我们来看看自 iOS 9 以来我们最大的敌人：KPP(内核补丁保护)。KPP 会在设备不忙的时候，每隔几分钟检查一次内核的更改。
> 事实上，卢卡-托德斯科(Luca Todesco)发布了一个完全绕过 KPP 的方法，这涉及到一个设计缺陷。KPP 并不阻止内核打补丁，它只是不断检查，一旦发现内核打补丁，内核就会慌乱。然而，由于我们仍然可以打补丁，这就为竞赛条件提供了机会。如果我们做得足够快，然后再恢复，KPP 就什么都不知道了；)
我有一些内幕消息。KPP 大约是在 A11 上实施 KTRR 的时候发布的，目的是在 <A11 SoCs 上实现少量均等。我依稀记得，当时高层下达了指令，要求实现这种同价，并在一定的时间限制内以最好的方式实现了这一目标。他们再也没有这样做过。
> FWIW, I presume this is “from experience”–rather than, from first principles, which is how it comes off
我把这句话理解为他们在最初研究/开始实施 MTE 时想出的办法，而不是 $longTimeAgo 之后的计划。
苹果公司在安全方面确实做得更好了，我猜想你列举的这些事情就是原因之一。越狱者显然迫使他们学到了很多东西。
是啊，这些事情很难第一次就做对。
> 从来没有针对 iPhone 的成功、广泛的恶意软件攻击。我们在野外观察到的唯一系统级 iOS 攻击来自雇佣军间谍软件……以极少数特定个人及其设备为目标。尽管绝大多数用户永远不会成为这种攻击的目标…
如果我说错了，请指正我，但已经开发出来的间谍软件只要进行基本修改，按一下按钮就能大规模应用。他们只是选择暂时不这么做。我觉得这一段的区别比实际存在的要大。
苹果和谷歌都不知道对其产品的攻击有多普遍，尽管他们把自己描述得好像对此有完美的洞察力。他们自称知道自己无法知道的事情。GrapheneOS 公布了从漏洞开发者那里泄露的数据，显示他们在利用设备和跟上更新方面比大多数人想象的要成功得多。我们能获得的信息比我们公布的要多，因为我们不会在没有多个独立来源的情况下公布这些信息，以避免泄露信息被识别出来。这些工具广泛存在，无论是数据提取还是远程利用，一般人都不可能知道它们是何时被使用的。在野外捕获漏洞利用是例外情况，否则漏洞利用开发公司的工作就会困难得多，因为它们需要在漏洞被大量使用后继续制作新的漏洞利用程序。如果单个漏洞利用链在被使用 5 万次后停止工作，他们就不会像现在这样看重它了。世界各地的执法部门都可以使用 Cellebrite Premium 等工具，这些工具被用来对付许多越境者、抗议者等。这就是大规模使用。对远程漏洞的了解要少得多，因为远程漏洞不一定要广泛传播才能被广泛使用。
> 像 Cellebrite Premium 这样的工具被用来对付许多跨越国界的人
我在想，什么时候才会有第一个人因为拥有一台 iPhone Air 而被美国边境检查人员拒之门外，而 CBPs 的手机提取工具却无法在这台 iPhone Air 上使用呢？
苹果和谷歌可以获取类似或比你更多的信息，只是出于类似的原因没有公布而已。
> 苹果和谷歌可以获取类似或比你更多的信息，他们只是出于类似的原因没有公布这些信息。
如果是这样的话，那么他们在这方面的许多公开声明就显得格外不诚实了。针对 Safari、Chrome 浏览器、iOS 和 Android 的漏洞利用非常普遍。这些攻击不仅是针对政府等大力追捧的人的罕见攻击。他们并不像他们说的那样有那么多的可视性。
你能更具体地说明你认为的 “广泛 ”与 “罕见 ”的区别吗？
我认为至少在影响上，这并不构成广泛传播，但有时恶意应用程序会出现在应用程序商店中，并被用来窃取加密货币。
也许有，也许没有。但指出这一点似乎很公平。当然，如果它像 Windows 那样暴露，那么就会有很多。
我的意思是，如果你看了漏洞链，它们适用于所有 iPhone，而且是可蠕虫攻击的。
这主要是针对安卓系统的。我不认为它与文章的其他部分有什么关系(而且，虽然我没有什么洞察力，但戴着阴谋论的帽子，加入这篇文章是为了兜售其应用程序商店模式的优点)。
即使没有阴谋论，它也非常适合作为简单的营销信息。"我们努力做好安全工作。这是我们最新的工具"。
就我个人而言，我并不觉得这是针对安卓系统的抨击。如果是，我个人也不知道它指的是什么攻击，除了可能是供应商安装的恶意软件之外。
但如果是供应商安装的恶意软件，他们真的可以为所欲为，不是吗？这并不是真正的安全漏洞。只是信任。
这真是令人印象深刻。
据我所知，在攻击者有机会多次尝试的情况下，这并不能保护你的安全。
我们可以采取的方法是：离开边界足够远，以跳过直接相邻的对象，或者在空闲后使用，并进行大量梳理，这样就有机会获得匹配的标签。获得匹配标签的概率是 1/16。
但是这篇文章没有提供足够的细节，所以我对我所说的没有信心。时间会证明一切！如果成功了，那么剩下的漏洞链将不得不依赖逻辑错误，这对坏人来说将是非常痛苦的事情
即使是 Android MTE，其中一个变通方法也是对小标签进行概率攻击，这意味着需要多次尝试。这里的一大区别是统一同步执行，因此写入会立即捕获，而不是在下一次上下文切换时捕获。
在安卓系统上，它通常以同步或非对称模式使用。非对称模式保持了与非对称模式几乎相同的性能，只是写入保持异步。一旦有读取或系统调用，就会强制执行。同步模式在内核中更为重要，因为有很多漏洞可以绕过它，这也是 GrapheneOS 在内核中使用同步模式而在用户空间中使用非对称模式的原因。异步部署仍然有用，因为它是一种广泛分布的错误查找工具，成本几乎为零。主要的代价是它发现了大量需要解决的错误，这也是第三方应用程序部署它的一个障碍。
主要弱点是 MTE 只有 4 位……绕过它的几率甚至不是 1/16，而是通常的 1/15，因为标签通常保留给元数据、空闲数据等。Linux 内核对内核使用的标准实现不必要地保留了超过 1 的位数，以方便调试。MTE 为更安全的内存标签实现扫清了道路，它具有更多的位和其他功能。它提供了一条明确的途径，可以针对漏洞利用(尤其是远程/近程漏洞利用)中使用的主要漏洞类别提供非常强大的保护。这是一项伟大的功能，但与当前的 4 位 MTE 相比，它更令人印象深刻。摆脱一些已知的侧信道并不能使其成为内存安全实现。
你比我更清楚，我只是整个开发领域的旁观者。我其实只是在回应这样一种观点，即这些反制措施会落到多次得手的攻击者身上 — 这些攻击者显然是威胁模型的一部分。我认为，我对 MIE 的修订会产生什么影响(提高成本，也许随着时间的推移，会淘汰平台上较低层次的漏洞开发者)有现实的预期。
我认为他们很可能做得很好，并认为这将大大提高 iPhone 的安全性。我不喜欢这种类似技术博文的夸张营销。这就好像他们在生产中部署的 CHERI 几乎没有开销，而不是比多年前人们在生产中使用的标准 ARM Cortex 内核的增量改进。
其他公司也意识到了 MTE 需要改进的地方，并且多年来一直在努力改进。Cortex 推出的 MTE 存在侧信道问题，但这总比不推出要好，而且问题会得到解决。苹果公司自己的 CPU 也有很多侧信道漏洞。通过 MTE 提供的确定性保护不会受到侧信道的负面影响，还能避免仅依赖 4 位熵。使用 MTE 的明显方法并不是唯一的方法。
GrapheneOS 在 Pixel 8 提供了量产质量的实现后，就开始在生产中使用 MTE，这比它本可以提供的时间晚了很多，因为 Pixel 并不是新 Cortex 内核的早期采用者。在这些内核上，异步 MTE 几乎是免费的，而非对称 MTE 与 -fstack-protector-strong 类似。同步的成本相对较高，因此使其性能优于早期提供 MTE 的 Cortex 内核似乎是苹果公司取得重大改进的地方。与目前的 Cortex 内核相比，苹果拥有更高端、更大的内核。高通公司的 MTE 实现即将推出，这将是一次有趣的比较。我们预计，安卓系统将大量采用 MTE，因此，出于必要，MTE 的速度会更快。对于用户空间来说，同步比非对称的安全优势值得怀疑。这一点在内核中更为明显，因为终端用户设备的 CPU 占用时间很少。我们在内核中使用同步，在用户空间中使用非对称。我们没有将完全同步作为一个选项，主要是因为我们没有任何实例表明同步会带来不同。除了读取之外，系统调用也是一个同步点。
* 我认为他们很可能做得很好，并认为这将大大提高 iPhone 的安全性。我不喜欢这种类似技术博文的夸张营销。这就好像他们已经在生产中部署了CHERI，其开销几乎为零，而不是比多年前人们一直在生产中使用的标准ARM Cortex内核的增量改进。
我只想谈谈这一部分。为什么苹果不能在这里宣传或推广其成就？如果他们有效地减轻和/或阻止了现实世界中的攻击，并似乎消除了一类安全漏洞，他们为什么不应该夸耀一下呢；这表明安全研发是他们制造产品的首要任务，这是向具有安全意识的消费者销售更多产品的有效策略。
我不是一个骗子，而是一个股东，我投资苹果是因为他们在很多技术领域都走在前列。
是啊，这真的很好。
这让概率对攻击者非常有效。但这并不能保证
但其他 15/16 次尝试都会导致崩溃，而如此不稳定的错误在生产中实际上是无法使用的，这一方面是因为用户会很明显地感觉到这一点/向上游发送诊断程序，另一方面是因为当你把几个这样的 15/16 次尝试堆叠在一起时，实际上需要相当长的时间才能获得好运。
通常为 14/15，因为标签通常是为元数据、空闲数据等保留的。Linux 内核将多个标签保留给内部内核使用，因为它更多是作为硬件加速调试功能被引入上游，尽管它对加固非常有用。
我明白了。这也是我要补充说明的原因，即这并不能防止攻击者进行多次尝试。
> 2018 年，我们在业内率先在 A12 仿生芯片中部署了指针验证码 (PAC)，以在内存损坏的情况下保护代码流的完整性。这一防御机制在增加攻击复杂性方面取得了巨大成功，毫无疑问，软硬件安全的深度融合将是解决我们面临的一些最大安全挑战的关键。
自 PAC 推出以来，已经出现了多种全链攻击。由于攻击者不断找到 PAC 的旁路，因此它并不能有效阻止攻击。这应该让您对 EMTE 的安全性有所怀疑。
> 因为攻击者不断找到 PAC 旁路，所以它并没有起到有意义的攻击威慑作用。
更正：它迫使攻击者寻找 PAC 旁路。它们并不是无限的。
像这样劫持控制流并不是漏洞利用的硬性要求。一般来说，特定软件版本中的漏洞并不是无限的，所以这并不意味着什么。
公平地说，他们并没有声称这是一种有意义的攻击威慑。他们说的是 “成功……增加了利用的复杂性”。
当然，整个句子有点怪异混乱。翻译过来就是：它使漏洞利用变得更加复杂，所以我们得出结论，我们需要一种SW/HW相结合的方法。我对这句话的理解是，他们承认 PAC 没有奏效，所以他们需要想出一种新方法，而这种方法的一部分就是接受他们无法单独使用 SW 或 HW 方法的事实。
话又说回来… 我对 PAC 不甚了解，但在我看来，它是一种硬件功能，需要对软件进行修改才能使用，所以它已经是硬件+软件的结合体了。但这也是无谓的争论；EMTE 需要更多的协调，覆盖面也更广。
让攻击者付出更多努力仍然是一个值得追求的目标。没有一种安全是完美的。
哈哈，被绕过并不意味着没有效果。
有了欧盟的聊天控制，国家就会控制我的设备，可以访问他们想要的一切，决定我能做什么，不能做什么。一旦谷歌强迫我们使用 WEI，整个网络都将被锁定。安全启动和现在的 MIE 将确保我们永远无法夺回自由。
> MIE will make sure we can never take back our freedom.
这里的意思是，让手机更安全是……坏事？因为这会让越狱更难开发？
我认为是的。我在这个话题中看到过一些人的类似言论，非常愚蠢。苹果开发这项技术并不是为了让你更难获取 torrent apps* ；他们要解决的是更大的问题。
*：或者是现在人们越狱的目的
也就是说，除非我们将系统和服务巴尔干化。
> 除非我们将系统和服务巴尔干化_________________________________________。
……一直回到纸笔上
什么是 WEI？
谷歌在 2023 年提出将其作为网页 DRM。在一片哗然之后，它被无情地撤回了。
我确信苹果/ARM 的模式要复杂得多，但略微浏览一下，我就想到了伯勒斯的大型系统内存标记架构： https://en.wikipedia.org/wiki/Burroughs_large_systems_descri…
>EMTE 的存在使 Spectre V1 成为攻击者可用来帮助引导其攻击的最后途径之一，因此我们设计了一种全新的缓解措施，以几乎为零的 CPU 成本限制 Spectre V1 泄密的有效范围，并迫使攻击者与类型隔离作斗争。这种缓解措施使攻击者使用 Spectre V1 变得不切实际，因为他们通常需要 25 个或更多的 V1 序列才能达到 95% 以上的可利用率–除非其中一个序列与被利用的漏洞相关，这与我们的 kalloc_type 分析的推理类似。
他们解释过这种缓解措施的作用吗？
https://mastodon.online/@ezhes_/115175838087995856
没有。我不明白为什么仅仅在猜测过程中检查标签就不能阻止 Spectre V1，至少在交叉类型访问方面？我的意思是，事情没那么简单，因为如果推测的标签不匹配，你的程序就不会崩溃。也就是说，你可以尝试无数次，直到你走运为止。但这肯定不是 “完全新颖的缓解方法”，所以我肯定漏掉了什么显而易见的东西。
也许真正的问题在于，你可以使用猜测来扫描大量内存以查找匹配的标记，其中一些标记会是不同类型的，所以你需要一些东西来处理这个问题？
(我说的都是屁话)
我想你的思路是对的。你在一分钟内发表的评论中的 mastodon 链接提供了更多细节：
听起来内核分配可能只使用一个标签(？) 所以，如果你进入了那里，就中奖了，对吗？不用处理标签。
因此，他们使用特殊的编译器标志将所有偏移量限制在 4 GB 以下。然后，他们将内核的不同部分放置在地址空间中，相隔很远，并有 4 GB 的未映射区。
因此，如果你能把自己的指针放在已分配内核内存中可利用的地方，那么它就无法指向内核内存的任何其他 “部分”。只能在那个 “区域 ”内。
这大概意味着，如果利用图形驱动程序中的问题，就无法提供指向 Secure Enclave 接口代码的指针。或者类似的意思。
我的理解并不完全正确。
> 听起来内核分配可能只使用一个标记
博文中是怎么建议的？
“……为包括内核在内的关键攻击面提供始终在线的内存安全保护……”
"……始终在线的内存安全保护覆盖关键攻击面–包括内核和 70 多个用户态进程–建立在增强内存标记扩展(EMTE)之上，并由安全类型化分配器和标记保密保护提供支持…… "
我认为内核分配器使用了与用户空间分配器类似的标记策略。
> Arm 于 2019 年发布了内存标记扩展(MTE)规范，作为帮助查找内存损坏 bug 的硬件工具。MTE 的核心是内存标记和标记检查系统，其中每个内存分配都标记了一个秘密；硬件保证，只有当请求包含正确的秘密时，才会批准以后访问内存的请求。如果密文不匹配，应用程序就会崩溃，事件也会被记录下来。这样，开发人员就能在内存损坏错误发生时立即识别出来。
>谷歌去年迈出了伟大的第一步，他们为那些选择加入其针对高危用户的计划的用户提供了 MTE。但是，即使对于那些开启了 MTE 的用户来说，Android 上 MTE 的有效性也受到了限制，因为它缺乏与操作系统的深度集成，而这正是内存完整性执法与其在苹果芯片上使用 EMTE 的区别所在。
>随着 iPhone 17 系列和 iPhone Air 的推出，我们很高兴能够提供内存完整性保护：这是业界首个全面、始终在线的内存安全保护，覆盖了关键的攻击面，包括内核和 70 多个用户态进程，它基于增强内存标记扩展 (EMTE)，并由安全类型化分配器和标记保密保护提供支持。
当然，看到GrapheneOS在实施(1)和提高认识(2)方面的努力没有得到其他人的认可有点令人失望，但看到苹果在这方面做出了认真的努力还是非常令人鼓舞的。希望这能激励谷歌在 Pixel OS 中也这样做。它还应该让人们相信，GrapheneOS 是创建一个能够保护设备所有者免受未知威胁的系统的领军者之一。
[1] https://grapheneos.org/releases#2023103000 [2] https://xcancel.com/GrapheneOS/status/1716946325277909087#m
苹果公司多年来一直在研究这个问题。他们并不是在丹尼尔决定在 GrapheneOS 中打开内存标签时才开始考虑这个问题的。
GrapheneOS 为 hardened_malloc 集成了我们自己的 MTE，并在这方面做了大量工作。这不仅仅是我们开启的功能。ARM 设计并构建了该功能，并在 Cortex 内核中提供。谷歌的 Tensor 使用标准的 Cortex 内核，因此与高通不同，他们不需要自己实现。谷歌将其集成到了安卓系统中，并做了一些工作使其能够在 Pixels 上使用，同时还修复了发现的许多错误，但绝对不是全部。我们不得不修复许多问题。由于苹果公司拥有自己的内核，因此他们必须自己实现硬件功能，而高通公司最终也完成了这项工作。
Pixels 不再是唯一采用 MTE 的 Android 设备，而且有一段时间没有采用了。我们曾在三星平板电脑上试用过，如果三星允许并在更新方面做得更好，我们也希望能支持它。
GrapheneOS 不是一个人的项目，也不是一个业余项目。我不是为 hardened_malloc 实现 MTE 的人，也没有完成其中的大部分工作。这项工作主要是由 Dmitry Muhomor 完成的，他是 GrapheneOS 的首席开发者，在操作系统上做的开发工作比我多得多。多年来一直如此。GrapheneOS 并不是我的个人项目。
我们做了大量工作，包括修复 Linux、AOSP 和许多第三方应用程序的错误。我们的用户正在使用 MTE 对安卓应用程序进行广泛测试，并向开发人员报告问题。我们为它集成了一个特定的崩溃报告系统，以帮助用户向应用程序开发人员提供可用信息。最困难的部分是让应用程序处理内存损坏问题，最终谷歌将需要通过在新的目标 API 层级默认启用堆 MTE 来实现这一目标。理想情况下，堆栈分配 MTE 也会被使用，但其成本远高于堆 MTE，苹果和谷歌不太可能将其引入生产应用。
安卓应用程序历来主要使用 Java 编写，这意味着它们的内存损坏 bug 要比桌面软件少得多，而且 MTE 的部署也要比桌面软件容易得多。尽管如此，安卓仍有很多原生库，某些类型的应用程序(如拥有更多原生代码的 AAA 级游戏)在使用 MTE 时会遇到更大的问题。
这些都没有错，但这些都不会对苹果的决定产生任何影响。事实上，正如他们在博文中所描述的，苹果非常明确地选择不朝这个方向发展。
侧信道修复和新的 MTE 指令功能并非苹果公司特有。苹果公司的博文存在一些严重的误导和遗漏。这是一篇营销材料，而不是一篇真正的技术文章，不存在严重的偏见。其目的是贬低现有的 MTE 部署，夸大他们所做的工作，甚至淡化事实证明正在发生的对苹果设备的广泛利用。如果他们不知道利用其设备的行为有多普遍，包括低级执法人员利用广泛可用的工具进行利用，那就太奇怪了。
我认为你必须把苹果的 “广泛的恶意软件攻击 ”理解为一个艺术术语；它是企业形象的一部分，可以追溯到 iPhone 诞生之初，而且(我认为可能)与一些政策相关，而这些政策对他们来说现在非常突出。我认为 SEAR 非常清楚现实世界中对 iPhone 的利用是什么样子的。不过，你永远不可能在这样的公开博文中看到他们未经过滤的观点。
> 我认为你必须把苹果文中的 “广泛的恶意软件攻击 ”理解为一个艺术术语
世界各地的许多政府、公司等都在广泛利用苹果设备。苹果和谷歌对此轻描淡写。这些攻击往往没有任何针对性，而是你访问了一个涉及特定政治运动(如加泰罗尼亚独立)的网页，并通过 Safari 或 Chrome 浏览器受到攻击。这并不是一种针对性很强的攻击，也是这些漏洞如何被部署的一个典型例子。认为这些漏洞只针对政府锁定的特定个人的想法是不正确的。苹果和谷歌都知道情况并非如此，但却引导人们相信事实并非如此，从而将其产品宣传得比实际情况更加安全。
> 我认为 SEAR 非常清楚现实世界中利用 iPhone 的情况。
根据他们与 Citizen Lab 和其他公司的互动，似乎并非如此。
我理解你之前提出的观点，并没有反驳。不过，我认为你对 SEAR 的态势感知判断有误。你认识那里的很多人吗？如果不认识，我会很惊讶。平台安全是一个不伦不类的领域。
我们经常与谷歌的许多人在该领域保持联系，而与整个苹果公司的任何人几乎都没有联系。有时，我们认识的人到苹果公司工作后，几乎对任何技术问题都保持沉默。
通常都是外部人士发现漏洞被广泛使用，然后报告给苹果和谷歌。公民实验室、国际特赦组织等。
我们经常收到在开发漏洞的公司工作或曾经在这些公司工作过的人，特别是使用这些漏洞的组织的人提供的信息。我们的很多观点都是基于长期积累的能力文档、技术文档等。有时，我们甚至能接触到过时的漏洞利用代码。重大版本的发布带来了大量的代码更新、组件替换和新的缓解措施，这似乎经常会破坏漏洞，而不是安全补丁。很多漏洞持续存在多年，然后被利用的组件突然被重写，从而不再起作用。他们定期开发新漏洞的压力并没有人们想象的那么大。
我并不是想暗示苹果(和谷歌)没有与 Arm 合作，在多年的努力中率先开发出这款产品。我只是想说，如果能在生产中使用它，哪怕只是顺便评论一下，也会很好。
作为局外人，我对这些公司正在考虑的安全开发项目一无所知，也不知道这些项目何时会因折衷而无法投入生产。因此，我无法理解苹果公司为达到这一阶段所做的努力的规模，而对于 GrapheneOS，我知道他们在隐私/安全两方面都很均衡。我将此作为一个微弱的信号，来衡量苹果/谷歌/微软在实现这些目标方面的决心。
ARM 在很大程度上是自己构建并交付的。Cortex 内核是第一个实际应用。推动 ARM 将其作为一项安全功能，而不仅仅是一项错误查找功能，苹果和谷歌可能要为此负责。制作 MTE 的 Android 设备并非只有 Pixels，但 Pixels 是首款通过实际设置并提供 CPU 支持来利用它的设备。现在也有其他 Android 设备在这样做。
高通公司(Qualcomm)必须自行实施，这大大推迟了普及时间。不过，Exynos 和联发科已经实现了这一功能。
就我个人而言，我根本不知道有人已经实现了这一功能。我知道有 MTE，但不知道有 EMTE。
很高兴听到它已经以某种形式投入使用。
当然，如果新款 iPhone 采用这种技术，那么很明显，它将会采用 M5 或 M6 芯片。
ARM 将其作为 Cortex 内核的标准功能，在其作为 ISA 扩展功能加入后，ARM 将其作为 Cortex 内核的标准功能。联发科和 Exynos 提供了该功能，Snapdragon 也即将推出该功能。
谷歌在 Pixel 上设置了这一功能，后来三星和其他公司也开始使用。Pixel 8 是第一个真正可以使用并达到生产质量的设备。在 Pixel 8 上推出后，GrapheneOS 几乎立即开始在生产中使用它。
所以苹果做了研究，而丹尼尔只是 “打开了它”？我说的不是硬件部分，即使是硬件部分，你也有偏见，对他人的努力不屑一顾。
这是迄今为止新系列设备的最佳卖点。
全称是 “内存完整性执行”： 苹果设备内存安全的完整愿景
从苹果的生产方式来看，这更像是 “制造商完整性执行”。
对普通用户/大功率用户来说，真正的好处是什么？
目前仅适用于 iPhone 17 吗？
适用于今天发布的所有机型：Air 和 17/17 Pro(A19 芯片及以上)。
大概是未来的 M5 型 Mac 和 iPad。
我也希望如此，但我认为它可能会出现在 M6 中。
202X M 系列并不总是与 A 系列拥有相同的内核版本。有时它们是基于 202X-1 的内核。
考虑到这是一个非常好的功能，我当然希望它能出现在 M5 中。
1988打来电话，希望恢复内存标记https://www.devever.net/~hl/ppcas ！
不过，IBM 在很长一段时间里都在支持这项功能。很高兴看到它越来越普及。
PowerPC AS 标记的问题在于它完全依赖于陷阱指令。如果你能控制执行，你就可以跳过陷阱指令，而它什么也做不了。根据我的理解，这种实现方式实质上是在每次加载和存储后添加同步陷阱指令，从而建立了一个真正的安全边界(即使与 Android MTE 相比也是如此，后者在读取时会触发陷阱，但写入时只在下一次上下文切换时进行检查)。
这似乎是一种阻止 “无效 ”访问的实际安全机制，而标记内存扩展仅提供指针元数据，由操作系统来执行不变性。
> 扩展不提供安全性。标记内存扩展并不能阻止你做任何事情。
SPARC ADI 是 ARM MTE 的前身。ARM MTE 已经上市并在生产中使用了好几年。ADI 也是 4 位，但粒度是 64 字节而不是 16 字节。
吹毛求疵： 1988 年的 AS/400 并没有使用 PowerPC。我相信它有自己的专有内存，包括标记位。
第一台带有 PowerPC AS 扩展的 RS-64 于 1995 年问世。
标记机制让我想起了代索引，比如 https://floooh.github.io/2018/06/17/handles-vs-pointers.html，但我还不太懂
这与 CHERI 相比如何？
复杂程度大大降低，因此实际使用起来可能要容易得多。
CHERI-Morello 使用 129 位能力对象来标记操作，具有并行能力堆栈和能力指针，并要求微体系结构支持标记存储内存。基本上，使用 CHERI-Morello，你的内存操作也需要提供一个指向存储在能力存储区的能力对象的指针。所有触及内存的操作都会指向你的能力，它告诉处理器你能用内存做什么，以及你能触及内存的范围。能力存储区实际上是一个独立的总线和内存，程序无法访问，因此没有秘密可言：即使你泄露了指向能力的指针，也没有关系，因为它不在 “用户代码 ”可以触及的地方。这在理论上没有问题，但在实践中却非常昂贵。
MIE 的概念要简单得多，它似乎使用 N 位(可能是 4 位)标签来保护堆分配，并使用 SPTM 来保护标签空间不被内核破坏。如果完全按照文章所述：堆分配获得一个标签。对堆的任何加载/存储操作都需要在指针中提供分配时使用的标签。内核分配器使用的标签存储空间受 SPTM 保护，因此不能直接转储标签。
如果将 MIE、SPTM 和 PAC 结合起来，就能得到接近于 CHERI 的结果，但需要独立的构建模块。它的鲁棒性较差，但也是一个粒度较小、开销较少的系统。
MIE 既是概率性的(熵的 N 位)，又受到稍弱的硬件保护(SPTM，我的理解是总线防火墙，而不是单独的总线)。虽然现有的缓解措施可以保护堆栈和执行流，但它也只能保护堆分配。
根据帖子中非常有限的信息，我天真地认为这里最大的漏洞是标签碰撞。如果你用足够多的堆喷洒尝试足够多的次数，或者可以反复梳理堆，那么你很可能会与系统中存在的任意多位熵发生标签碰撞。但是，由于模型是同步的，在此之前的每一次都会出现总线故障，这与 MTE 不同，所以你会被抓住，这对民族国家攻击者来说是个大问题。
有一点我不太清楚：CHERI 在专利方面是自由和透明的，还是说人们已经伸出了双手，想要获得类似 MPEG 的许可红利？如果是后者，那么这可能与采用 CHERI 的纯技术障碍一样重要。
https://saaramar.github.io/memory_safety_blogpost_2022/是一篇很好的文章，它深入探讨了过去 MTE 的这一主题。
值得注意的是，Apple 的实现基本上强制执行了作者演讲中记录的不变式：
* 使用同步异常(“精确模式”)，这意味着故障指令不能退行并造成损坏
* 在释放时重新标记分配
不知道这些保护措施是否也适用于 macOS。
目前还没有相应的硬件，但我认为新的 Mac 出货时就会启用。
一旦硬件到位，我就不明白他们为什么不启用它了。
我认为黑客们还没有准备好接受 “无法破解的硬件 ”可能真的存在的事实。这种硬件永远不会有一天被发现漏洞，永远不会被越狱，永远不会有盗版，也许除了民族国家的攻击。
2012 年的 Xbox One？从未被黑
任天堂 Switch 2，2025 年？根据逆向工程师的说法… 在 Switch 1 代的基础上构建了_完美_安全的微内核和安全监视器。与此同时，英伟达的启动代码这次也通过了正式验证，它是用核反应堆和飞机使用的同一种语言(ADA SPARK)在定制的 RISC-V 芯片上编写的。
iPhone? iOS 17 和 18 从未越狱过；现在我们介绍 MIE。
我强烈反对将公开漏洞的可用性作为安全的证据。这是一个坏主意，因为数以百计的市场因素和随机的盲目运气对公开漏洞可利用性的影响要大于开发漏洞链的难度。
在减少漏洞方面，苹果公司无疑是做得最好的公司。然而，我们仍然可以看到在漏洞链中被标记为野外使用的 CVE 掉落，所以我们知道有人还在做，而且还在成功。
说到 Xbox One，这是一项令人钦佩的工作，这在很大程度上是因为许多来自 Xbox 360 的最聪明的漏洞利用开发者受雇设计和构建 Xbox One 安全模型。但即便如此，即使在公开场合，它的接缝处仍有一些小裂缝： https://xboxoneresearch.github.io/games/2024/05/15/xbox-dump…
我认为这个场景的性质发生了变化，漏洞利用和越狱被保留给了小团体、个人或被出售。
例如，我可能知道一个与我无关的漏洞，因为我不想让它被修复，而且到目前为止它还没有被修复。
我认为现在的风气已经变成了 “当对手犯错时不要纠正”，而不是老一辈的发布影响力文化。
说 “永不 ”太大胆了。但这肯定会变得非常困难。
除了内存不安全之外，还有很多其他缺陷可以利用。我怀疑在很长一段时间内，我们都无法看到像这样经过正式验证的主流操作系统。
没错。但如果开发一个漏洞需要 15 年，而设备的平均寿命是 5 年，那么在某种程度上，这实际上就是完美的。
设备的限制越多，这些漏洞就越难攻破。
这要看情况。如果 “限制 ”意味着 “复杂性”，那么最终可能会出现 BlastDoor 漏洞(如强制)这样的情况。
>Xbox One，2012 年？从未被黑。
没有公开:)
> iPhone? iOS 17 和 18 从未越狱；现在我们介绍 MIE。
据你所知。把它们称为零日漏洞是有原因的。
以色列的公司和机构一定会找到办法的。即使软件/硬件可能真的无法破解，但人们似乎永远不会被破解。
随着遥控硬件不可破解能力的提高，能够制造这种硬件的人与不能制造这种硬件的大众之间的力量不对称将急剧增加。对于普通人来说，尤其是西方国家的普通人来说，这种平衡会产生怎样的影响，我把这个问题留给观众去思考，因为在西方国家，之前的平衡是完全不同的。
这看起来太棒了，我迫不及待地想看看攻击者是如何支点的。
https://xkcd.com/538/
我讨厌这幅漫画，因为它实在是太_疯狂_了，我讨厌人们用它来敷衍有意义的安全进步。
用扳手打人会留下痕迹，可以让媒体和真相与和解委员会看到。对持不同政见者进行 “湿法 ”和 “黑法 ”会留下记录：培训、行动、事后证据。而且，这几乎不会产生影响–不管当权者想让你怎么想，我认为历史表明，休-汤普森(Hugh Thompsons)比奥斯卡-迪尔勒旺格(Oskar Dirlewangers)更多，即使需要几年时间才能认识到他们的所作所为。
如果我们在安全方面的改进足以让我们的对手不敢动用扳手，那就是非常有意义的改进！
好吧，当然，但你其实不需要扩大规模，只要找到一个你想要的拥有 500,000,000 美元 BTC 的人，然后打击他就可以了。
又是懒惰！
是的：如果你有 5 亿美元的 BTC，当然 – 你是扳手的受害者，无论是私人的还是公共的。如果你是恐怖分子的主谋，你很可能会被关进关塔那摩监狱，并被一些卑鄙的人置于数个压力位置，直到你说出他们想听的话为止。
极端高价值目标过去和将来都很容易受到定向攻击。但这些改进对所有不是高价值目标的人来说都意义重大，比如我，还有(可能还有)你！
在我有生之年，政府已经从 “联邦调查局可以获得搜查令，录下我用自己的声音与任何人通话的内容”，变成了 “哦，他使用的是(e2e 加密平台)–如果我们能破解它，那将会增加大量工作”。这就意味着，可以成为目标的人群范围比以前大大缩小了。
举例说明：如果有 whisper.cpp 和没有 e2e 加密电话，考虑一下美国国家安全局现在能做什么。
如果我们在运行时检查每个指针，这只狗怎么会不慢呢？
芯片会在进行其他操作的同时自行检查。
试着读一下 TFA，它不是这样工作的。
这与趣味计算恰恰相反。这是商业计算，唯一的用途就是确保人们能安全地通过电脑发送/接收金钱。我喜欢偷窥/窥探我的进程内存，或修补可执行文件的内存。在苹果的锁定系统中，这一切听起来都是不可能的。
它们不再是通用计算机，而是被锁定的银行终端。
这一切都很有趣，直到有人修补了你设备的 RAM，把你的钱从你的账户里转走。
更有趣的是如何跟踪和调试这种 CPU 上的代码。因为调试器通常要做的正是在 RAM 中打补丁，窥视和窥探内部的可执行文件等。如果存在这样的接口，我想知道它是如何保护的；是否需要像 JTAG 那样的额外物理线？如果不需要，又如何对目标硬件上运行的程序进行故障诊断呢？
你可以禁用这些进程的缓解措施。
我认为如果你想摆弄硬件，就不应该买苹果。它是为那些把它作为达到目的的手段的人设计的，我认为这对大多数人(包括我)来说是件好事。我希望我的银行硬件是安全可靠的。不过，在玩游戏的时候自建一个 Linux 操作系统也没什么不好。
如果你喜欢使用调试器，别担心，MTE 会为你提供更多使用调试器的机会，因为它会发现更多崩溃情况。只要类型正确，它不会阻止你写入内存。
PAC 可能会阻止您更改值–或者至少您必须运行代码才能更改它们。
中奖了。这一切都不是为了用户。苹果莫名其妙地戴上了尊重用户的营销面具，而他们至少和其他人一样辱骂用户。
https://www.theguardian.com/news/2022/jan/17/two-female-acti…
与此同时，谷歌却在竭尽所能地削弱安卓系统的安全性，扣留图片和补丁，也未能将应用程序完全隔离。证据链接如下：
(1) AOSP 未死，但 Google 刚刚给了定制 ROM 开发者一记重击： https://www.androidauthority.com/google-not-killing-aosp-356…
(2) 注重隐私的 GrapheneOS 警告 Google 正在封锁 Android：https://cyberinsider.com/privacy-focused-grapheneos-warns-go…
(3) GrapheneOS揭露谷歌对安卓安全更新的空洞承诺：… https://piunikaweb.com/2025/09/08/grapheneos-google-security…
听着，我是一名 iOS 用户，但这在我看来就像是没有任何技术细节的火焰诱饵。多年来，我在谷歌博客上看到过很多关于安全改进的文章，因此，如果你不打算支持它，这似乎是一个非常笼统的断言。
我没有读过发布的文章(我也不知道 piunikaweb 和 cyberinsider 的可信度有多高)，但以下是来自 GrapheneOS 的第一手信息：https://grapheneos.social/@GrapheneOS/115164133992525834
> … 谷歌最近对 Android 安全更新进行了令人难以置信的错误修改。为了方便 OEM 厂商，Android 安全补丁(现在)几乎完全按季度更新，而不是按月更新。他们为 OEM 提供了 3-4 个月的提前访问权。谷歌现有的向 OEM 厂商分发安全补丁的系统已经存在很多问题。将 1 个月的提前使用权延长至 4 个月简直是残暴。这适用于公告中的所有补丁。
> … 现有系统本应缩短补丁的广泛披露时间，而不是 30 天。反其道而行之，提前 4 个月开放是非常不负责任的。……他们的 3-4 个月禁售期对只发布二进制补丁有明确的例外规定。我们完全可以在本月发布 2025 年 12 月的补丁，但不能发布源代码。
> 几乎所有的 OEM 都没有发布每月安全补丁的后补程序，尽管它是如此简单明了。仅仅是反向移植，甚至都不是特别完整的补丁。它们只是高度和严重程度的 Android 补丁，以及 Linux 内核等外部补丁的一小部分。要获得完整的安卓补丁，需要最新的稳定版本。
最近关于安全更新 90 天禁用期的讨论，https://news.ycombinator.com/item?id=45158523
这可能很有意义，但我注意到石墨烯明确拒绝了这一框架：
https://xcancel.com/GrapheneOS/status/1964757878910136346
虽然这可能有所帮助，但真正的恶意软件是你安装的应用程序、你的互联网服务提供商和苹果的 iOS 本身。