苹果安全内核研究被推翻：一次诚实的自我纠错

一个被推翻的结论

今年二月，Antid0te发表了一篇关于苹果安全内核的研究，当时看起来像是找到了绕过路径。文章说普通Exclave里的代码，可以在可写内存里放一个假的能力值，调用它，让安全内核的指令流越过对象类型表跳出去。作者后来在纠错文章里承认，那个实验似乎证明了这件事，但结论是错的。原文还挂着，纠错链接就在上面。来源：Antid0te

错在环境。当时用的GLx Runner还在模拟苹果的安全机制，PAN被禁用了，SPRR权限寄存器的处理方式也不够忠实。作者承认，他们测试的是移除保护之后的情况，却把结果描述成保护还在。二月那个实验环境，跟真实设备差着一层。来源：Antid0te

环境与边界

这个边界是苹果安全设计的一部分。安全内核cL4跑在GL1，Exclave程序跑在GL0。SK接收的能力值不应该是Exclave能写入的任意内存块。SK要能读取真正的能力存储，不能把普通用户内存当成内核对象。这个边界靠PAN和SPRR维持。来源：Antid0te

PAN在设置时阻止特权数据访问普通用户可映射区，除非内核故意允许。只盯着页表权限位不够，SPRR会改变有效访问权限，SK在guarded world用特定权限配置。GLx Runner模拟得不完整，漏掉了这两层。来源：Antid0te

作者重复了测试。这次用的是iPhone Duo 27.1固件，build 24A94425，M5芯片上的原生guarded execution。调用者还是schedulerAddrSpace。测试写假头到该调用者可写的页，在GL0读回，执行SVC 0。harness没有改变PAN、SPRR、页权限，也没有改SK的代码。环境是真实的，不是模拟的。来源：Antid0te

修正后的结果

结果跟想象的不一样。未检查的调度没有消失，但也不是对所有Exclave都有效。普通Exclave得到error 4，roottask可以到达dispatch，前提是它已经持有更强的frame rights。这个区分，作者说他们之前漏掉了。重复测试没有让未检查的调度消失，而是暴露了一个条件：安全检查还在，生效范围比想象中窄。来源：Antid0te

检查没有消失，只是它的存在依赖上下文。修正后的结果指向一个更细的机制：安全检查还在，生效条件取决于Exclave类型和已持有的frame rights。这个反直觉的发现，跟二月的结论方向相反。二月的文章描述了一个普遍存在的绕过，修正后的图景是：普通Exclave被拒，roottask有条件通过。来源：Antid0te

苹果从未公开或私下指出这个问题。作者说他们自己发现的，纠正它是正确的事。来源：Antid0te

沉默与教训

HN上这个帖子只有1分，0评论。讨论是冷的，但原始博客上的技术修正很详细。我不确定HN的冷清意味着什么，可能是大家对这类纠错见怪不怪，也可能是没人细看。博客本身的技术细节，HN上没有对应讨论，深度分析还是得回到原文。来源：HN

教训是什么？安全实验必须完整模拟硬件安全机制。PAN和SPRR不是可有可无的细节，它们直接决定了实验结论。如果模拟层漏掉了这些东西，就会产生虚假的发现。一个错误的实验结论，比没有结论更糟，因为它会误导后续研究。这次纠错的价值，在于它展示了模拟环境与真实硬件之间的差距，这个差距不是抽象的，是有具体案例的。来源：Antid0te

作者的做法值得注意。自己发现，自己纠正，不等人来拆台。这种诚实是稀缺的。在安全研究里，一个被自己推翻的结论，比一个从未被检验的结论更有价值，因为它留下了验证过的路径。来源：Antid0te

原文：

A Second Look at Apple's Secure Kernel · 来源：Hacker News

作者：itfan123 值班编辑 · 发布于 2026年10月28日