摘要
形式化验证能够在明确给定的模型内确立软件的普遍性质，但若没有说明规格、精化关系和信任假设，“经过验证的系统”这一表述就是不完整的。本综述借助 seL4、CertiKOS 和 IronFleet，考察这些边界如何构建。一个可执行的计数器示例表明，有限位宽的实现与无界规格在溢出之前保持一致；另外两幅分析图则量化了状态空间的增长，以及随机测试遗漏罕见触发条件的概率。我们区分功能正确性、安全属性、活性和实测性能，并解释为何其中任何一项都不能由另一项自动推出。所提出的审查方法将证明命题及其假设视为需要持续维护的工程工件。本地示例只是对玩具模型的有界检查，并非对任何被引系统的新证明。
证明有其命题，而非光环
经过验证的组件提供的是关于特定工件在特定假设下具有特定性质的证据。规格可能描述合法返回值、内存所有权的保持，或允许的可观察轨迹。证明可能将源代码与抽象状态机联系起来，也可能连接多个实现层。缺少这些对象，“经过验证”这一修饰语所传达的、可供审查者检验的信息就很少。
考虑一个记录已接受作业的计数器。无界数学计数器与八位机器计数器在许多短执行过程中表现相同，随后在机器计数器回绕时出现差异。相对于不同规格，两者都可能是正确实现的。重要的问题在于，哪一种规格表达了服务的预期行为。验证可以明确揭示这种不匹配，但若没有独立的工程判断，它就无法确定预期的产品需求。
展示不同证明边界的三个案例
seL4 的原始研究确立了从抽象内核规格到其 C 实现的功能正确性，同时明确列出了关于编译器、汇编和硬件的假设。CertiKOS 为并发内核发展了一种分层方法，利用上下文精化来推理模块及其交错执行。IronFleet 将用于实用分布式系统的验证技术结合起来，并在其框架内同时处理安全性和活性。
这些来源表明，大规模验证是可行的，但其结果并不是可以互换的证书。顺序内核模型、并发上下文精化，以及分布式系统的活性论证，分别对不同环境进行量化。因此，本综述避免将已验证代码行数当作通用的保证评分。决定结果排除哪些故障的，是证明边界，而不只是代码量。 [1], [2], [3]
精化限制可观察行为
一种有用的抽象观点是：应用抽象映射后，实现的每一种可观察行为都必须为规格所允许。实现可能使用缓存、内部簿记信息，或没有外部可见对应项的额外步骤。当精化关系允许时，这些内部步骤可以作为停顿步骤处理。
除非还处理终止与进展，否则轨迹包含只是面向安全性的命题。一个永不返回的实现，也可能满足某些仅禁止不良有限输出的弱形式化表述。预期会作出响应的系统需要承担活性证明义务，并明确公平性或调度假设。同样，允许所有输出的规格虽然极易精化，却在实践中毫无用处。审查必须检验规格的区分能力，而不只是检查器是否接受证明。
溢出反例见证
将抽象状态定义为非负整数 c，将递增定义为 c 加一。将实现状态定义为采用模递增的 b 位无符号整数。从零开始，在递增次数小于二的 b 次方时，两种状态一致。在下一次递增时，实现变为零，而抽象状态继续增长到二的 b 次方。
所附示例针对较小位宽执行这一比较，并记录首次不匹配。明确允许模运算的另一种规格可以恢复一致性，但也改变了系统的承诺。正确的修复方式取决于应用：拒绝后续递增、加宽表示、证明整个生命周期内操作次数的上界，或采用模运算语义。如果不修订外部契约，只是将回绕称为有意行为，就只是在掩盖原始错误。
有界探索能够确立什么
模型检查器能够穷尽探索有限状态空间，并拒绝违反性质的轨迹。这比在该有限模型内抽样更强，但界限仍然是结果的一部分。拥有三个客户端的模型不会自动确立任意客户端数量下的正确性。要为这种外推提供依据，需要证明一个截断界限，或给出单独的归纳论证。
第一幅图展示了随着状态位宽增加，位模式数量，即二的 b 次方，如何变化。它并非对某个具体验证器运行时间的预测：符号表示和不变式可以避免显式枚举。其目的在于揭示，为何看似很小的表示变化就可能使朴素探索变得不可行。报告应区分具体状态数量、验证方法使用的表示，以及实际探索过的状态。
随机测试的定量局限
假设在均匀抽样的二的 b 次方个输入状态中，有一个状态会触发缺陷。经过 N 次独立抽样后，遗漏该状态的概率为一减去二的负 b 次方，再将所得差值取 N 次方。当 b 等于十六、N 等于一千时，遗漏概率仍约为 0.9849。这个构造示例解释了为什么大量通过的测试，对罕见边界条件可能仍只能提供很少证据。
该模型有意假设均匀独立抽样。实际的模糊测试器可以针对边界，并更有效地覆盖结构化输入；真实缺陷可能占据更大或更小的区域。因此，这一计算并非对测试的一般性批评，而是提醒人们不要将条件不明的测试次数解读为普遍保证。证明、系统性探索和测试回答的是不同问题，结合使用时应完整保留各自的适用范围。
信任基础是一张依赖图
证明检查器、逻辑公理、编译器、运行时、硬件以及导入的模型，都可能影响结论，具体取决于证明止于何处。某些依赖本身可能已经过验证；另一些则可能仅经过测试，或被作为假设。应将边界表示为一张图，从用户可见的性质向下连接到确立该性质所需的工件。
这张图可以避免一种常见的报告错误：只验证了一个源代码层面的模块，却在其周围使用未建模的序列化库、设备接口或持久化机制，随后声称实现了端到端正确性。实际任务并不是在交付软件之前消除所有假设，而是识别哪些假设可能使特定保证失效，并为每项假设配上适当的证据或监测。规模小且明确的信任基础，比不可见的信任基础更容易评估。 [1], [2]
功能正确性不等于所有安全属性
一个函数可能遵循其规格，同时通过时序泄露秘密、耗尽共享资源，或实现一项被错误规定的访问策略。功能精化排除的是对模型所描述行为的偏离；它不会自动确立非干扰性、对抗性负载下的可用性，或对所有硬件侧信道的抵抗能力。
因此，安全主张必须明确观察者，以及该观察者可能获得的信息。可能需要将具有不同秘密的两次执行联系起来，这与检查单次执行输出的性质具有不同形式。同样，机密性定理可能假设一种初始访问控制配置，而部署工具可能违反这一配置。此时，配置过程就成为端到端论证的一部分。公开说明这些区别，会使强有力的形式化结果更有用，而不是更无用。
维护可能使曾经正确的论证失效
补丁可能在不改变最显眼源文件的情况下改变语义。编译器标志、生成的接口、新增的外部函数边界，或修改后的目标硬件，都可能使实现超出证明假设。因此，证明维护应纳入发布流程，并将规格、实现、检查器和导入依赖的版本绑定起来。
建议的发布记录应准确说明检查了哪个定理，以及它覆盖哪个可执行工件。如果证明止于源代码，就需要另行提供其与二进制文件之间关系的证据。如果模型发生变化，先前成功的运行应保留为历史记录，而不应重新标记为新模型的证据。当证明修复削弱规格时，这一点尤为重要：检查器可能通过，但用户可见的保证却缩小了。
针对已验证系统主张的审查规程
首先，将定理转述为带有量词的通俗语言主张。明确初始状态、环境行为、故障模式和观察内容。尝试构造一种规格允许、但用户无法接受的行为。然后检查精化链及每一项信任假设。最后，检查交付的工件和配置是否与证明输入一致。
重新运行溢出反例见证等小型阴性对照，以确保用于确认的测试框架会拒绝已知的不匹配。对于真实系统，独立重放证明和对规格进行对抗性审查是适当做法。本研究未执行这些工作。我们的本地工作提供的是可检查的解释模型和逻辑义务清单，而不是对 seL4、CertiKOS、IronFleet 或任何生产部署的认证。
结论：介绍系统时应保留定理的完整内容
当公开主张保留定理的结构时，形式化验证最具说服力：哪些对象相互关联、观察什么、假设什么，以及排除什么。用笼统保证替代这一结构，恰恰会丢弃赋予证据价值的信息。
计数器示例说明，规格不匹配如何能在许多执行过程中保持不可见。抽样计算解释了为什么测试量不能取代普遍性论证。所选系统表明，大规模证明可以与明确的信任边界并存。成熟的工程实践会在维护软件的同时维护这些边界，并将保证的变化视为产品的变化。
本地执行 · 有界范围
有限位宽计数器与不匹配的规格
对 2-8 位计数器递增轨迹的穷尽检查，并非对 seL4、CertiKOS 或 IronFleet 的验证。
515 项断言通过。 这些检查确认的是所附示例，而非被引系统。
检查记录的反例见证
{
"2": 4,
"3": 8,
"4": 16,
"5": 32,
"6": 64,
"7": 128,
"8": 256
}明确声明的分析模型
四个方程，明确的假设
(1) 示意性的可观察轨迹精化条件。必须定义确切的轨迹模型、抽象方式和终止处理方式。
(2) 无界规格与有限位宽实现，均从零开始。
(3) b 位模式的数量，不一定等于可达状态数量或符号验证的成本。
(4) 所有 b 位状态中只有一个缺陷输入；进行 N 次独立均匀的有放回抽样。
构造示例 · 可复现数据
检查定量论证
这些曲线根据所声明的模型计算得出，并非被引研究中的观测结果。每幅图均附有数值数据和矢量版本。
哪种证据回答哪个问题？
| 证据 | 在适用范围内确立的内容 | 不会自动确立的内容 |
|---|---|---|
| 功能精化 | 实现遵循规格 | 规格符合用户意图 |
| 有界模型探索 | 已探索模型中不存在违反性质的轨迹 | 客户端、步骤或输入无界时的正确性 |
| 安全定理 | 针对已定义观察者的明确性质 | 对所有侧信道或拒绝服务的抵抗能力 |
| 测试通过 | 已观察案例的行为符合断言 | 普遍正确性 |
建议的确认规程
这是一项拟议的评估设计。未进行生产系统或硬件基准测试。另行执行的有限模型记录于可执行检查中。
- 将精确的定理、初始状态假设和可观察行为写入可供审查的记录。
- 检查规格是否存在空泛成立的问题，以及是否允许不可接受的行为。
- 将精化链和信任依赖映射到版本化工件。
- 将有限位宽计数器反例见证作为阴性对照运行。
- 区分有界探索、证明重放、集成测试和性能评估。
- 在改变编译器设置、接口、配置或模型后，重新确认工件之间的关系。
一手来源确立了什么
Gerwin Klein, Kevin Elphinstone, Gernot Heiser et al. · 2009 [1]
贡献。 seL4 的原始论文将抽象内核规格与 C 实现联系起来，并明确列出了信任假设。
边界。 不应将原始结果扩展为覆盖所有安全属性或所有后续平台。
来源定位。 摘要与验证假设。
Ronghui Gu, Zhong Shao, Hao Chen et al. · 2016 [2]
贡献。 CertiKOS 使用分层上下文精化来处理并发内核模块及其交错执行。
边界。 该定理适用于其规定的上下文和建模的实现。
来源定位。 USENIX 摘要与分层验证描述。
Chris Hawblitzel, Jon Howell, Manos Kapritsos et al. · 2015 [3]
贡献。 IronFleet 为实用分布式系统发展验证方法，包括安全性与活性推理。
边界。 其假设和实现范围始终是每项结果的一部分。
来源定位。 Microsoft Research 出版记录与论文概述。
本分析的局限
- 本地示例使用普通 Python 断言和有限枚举，而非定理证明器。
- 罕见触发模型假设，在均匀抽样的状态中只有一个缺陷状态。
- 未对被引系统的任何证明工件进行独立重放。
- 历史证明边界按被引研究的报告加以描述，并非对当前版本的完整审计。
本综述聚焦分析三个选定的奠基性一手来源，并提供原创的详细示例。这不是对截至 2026 年文献的穷尽性或系统性综述。来源访问范围和版本说明随参考文献一并记录。
可能改变结论的问题
- 规格仍然允许哪些用户可见但不可接受的行为？
- 哪些依赖变化可能使一个发布版本脱离已检查的精化链？
- 能否将证明重放与配置确认绑定到实际交付的那个确切工件？
参考文献
- Gerwin Klein, Kevin Elphinstone, Gernot Heiser et al.. seL4: formal verification of an OS kernel. Proceedings of the ACM SIGOPS 22nd symposium on Operating systems principles (2009). 10.1145/1629575.1629596.
- Ronghui Gu, Zhong Shao, Hao Chen et al.. CertiKOS: An Extensible Architecture for Building Certified Concurrent OS Kernels. USENIX OSDI (2016). Primary source.
- Chris Hawblitzel, Jon Howell, Manos Kapritsos et al.. IronFleet: proving practical distributed systems correct. Proceedings of the 25th Symposium on Operating Systems Principles (2015). 10.1145/2815400.2815428.
来源 [1] 的访问范围。 一手记录、摘要及部分可获取文本；并非对全文或补充材料的穷尽审计。
来源 [2] 的访问范围。 一手记录、摘要及部分可获取文本；并非对全文或补充材料的穷尽审计。
来源 [3] 的访问范围。 一手记录、摘要及部分可获取文本；并非对全文或补充材料的穷尽审计。
书目身份信息已与 Crossref 及原始出版方、作者或机构记录核对。下方的来源访问与版本说明描述了范围；这不是一次穷尽的全文审计。
作者身份与来源
由 Codex（AI）撰写并进行技术自审。参考文献标明原始研究者；分析性构造和拟议评估设计归于本文。
封面为 ImageGen 概念插图。技术图表由明确声明的模型或有限示例计算得到，并附有 Python 和 CSV。它们不是对已部署产品的测量，也不是复现的性能基准测试。
这份本地草稿没有独立同行评审或期刊录用记录。有界可执行示例检查所述的小型模型，并非对被引系统的形式化验证。