主要观点：

• CHERI 和安全语言并非解决相同问题，它们可相互补充，CHERI 能使安全语言代码与不安全或不同安全级别的代码安全交互，两者结合比单独使用更强大。
• 单个内存安全漏洞可能导致严重后果，如 WannaCry 和 CrowdStrike 事件，CHERI 可通过细粒度的内存安全原语和粗粒度的沙箱化来解决这一问题。
• 重写大型代码库并非解决安全问题的正确答案，存在机会成本高、可能引入新漏洞、并非所有代码都可重写以及需要专业技能等问题。
• CHERI 不能为代码修复内存安全错误，只是在内存安全错误发生时触发陷阱，但其能与消除其他类别的错误相结合。
• 供应链可能存在内存安全问题，即使是类型安全的语言也可能存在漏洞，CHERI 没有复杂的类型系统问题，能提供强运行时保证。
• 未来应是在 CHERI 上使用安全语言，CHERI 便于与不可信代码安全交互，安全语言使可信代码更值得信赖，且已有将 Rust 和 Ada 移植到 CHERI 的工作。

关键信息和重要细节：

• CHERI 提供语言无关的内存安全原语，编译器可生成或人工编写利用这些原语的汇编代码来捕获和执行源级对象的内存安全，其开关器在 CHERIOT 系统中特权最高，用汇编编写，受内存安全规则约束，不能访问调用者和被调用者之外的任何分区或内存。
• 单个内存安全漏洞可能使攻击者获得任意代码执行漏洞，重写 99%的程序为安全语言但留下一个内存安全漏洞仍无法防止大规模恶意软件部署，CHERI 可在硬件中强制实施内存安全保证，使安全语言代码能调用不安全或不同安全级别的代码并仍能执行源级属性。
• 重写大型代码库成本高，会占用写新代码的时间，可能引入新漏洞，并非所有代码都可重写，且需要专业技能，而写新的安全语言代码通常是更好的选择。
• CHERI 不能保证代码无内存安全错误，只是在错误发生时触发陷阱，但其能与消除其他类别的错误相结合，降低维护成本，如 Rust 和现代 C++可在编译时检查很多东西并强制实施类型属性。
• 供应链中即使是类型安全的语言也可能存在漏洞，如 Rust 的 cargo crates 中存在 264 个内存安全漏洞，Go 的切片类型存在竞争条件导致越界访问，Java VM 也存在安全漏洞，而 CHERI 的安全属性简单且可形式验证，能在使用恶意第三方代码时提供强运行时保证，cheriot-audit工具可审计 CHERIOT 固件图像中分区的行为。
• 已有将 Rust 和 Ada 移植到 CHERI 的工作，CHERIOT 还带有保留 JavaScript 类型安全属性的 JavaScript 解释器，使用 CHERI 可基于安全语言的优势进行过渡，而不是因为 C 的缺点。