企业官网建设流程全解析

导读

本文是 Astrid 原生内核（astrid-native-kernel）架构决策记录的完整技术解读。Astrid 是一个便携、基于能力安全（capability-secure）的操作系统，其原生内核是一个能力微内核，唯一的产品是在相互不信任的保护域之间强制边界。本文以仓库中的 docs/astrid-kernel-adrs.md 为主体骨架，系统讲解 Milestone 0 退出前必须落地的七项机制决策——保护域、能力对象表示、句柄转移、撤销、故障端点、调度、审计排序——并辅以 内核宪章、威胁模型、需求到证据矩阵 与仓库源码佐证。读完本文，你将理解每一项 ADR 的上下文、决策、被否决的替代方案与后果，掌握 Astrid 内核"少量机制承载多属性"的设计哲学，以及这些决策如何映射为可验证的 REQ 证据条目。

一、ADR 文档的定位：约束内的具体选择

Astrid 内核有一套分层文档体系，各有分工：

• 内核宪章（Charter）设定不变量（invariants）：哪些东西永远不许进入 ring 0，ring 0 必须提供什么；
• 威胁模型（Threat Model）说明防御对象：我们对抗什么、不宣称防御什么；
• 需求到证据矩阵（Evidence Matrix）说明每个声明如何被证伪：一条属性没有可执行证据就不算持有；
• 原生内核范围（Native Kernel Scope）界定首台机器契约与执行计划；
• AI 原生 OS 工作计划（Workplan）将上述文档转为带证据与退出条件的工作项，其中明确要求"记录保护域、能力对象表示、句柄转移、撤销、故障端点、调度、审计排序的 ADR"。

而ADR（架构决策记录）记录的是"生活在这些约束内部的、具体的机制选择"——即多个设计都能满足宪章、必须二选一的地方。每一份记录都写明上下文、决策、被权衡过的替代方案和后果，让后来的读者不仅看到"选了什么"，还看到"否掉了什么、为什么"。

记录约定

• 七个决策分别编号为ADR-K1至ADR-K7，从 ABI 草图和证据矩阵行中引用；
• ADR 只能通过宪章的修订程序（charter §10）变更：替代它的 ADR 必须指名被替换的记录，以及迫使变更的证据；
• 采用单一决策日志（一份文件而非每条记录一个文件），因为七项决策强耦合，审阅者需要连在一起读；若未来积累大量独立决策，拆分为"一记录一文件"这件事本身也要走一次 ADR。

与工作计划的对应关系

工作计划的"架构契约与可追溯性"章节明确标记了以下交付物已完成（[x]）：

• 记录原生内核范围与显式非目标；
• 编写简明内核宪章（Astrid Kernel Charter）；
• 编写覆盖固件/虚拟机监控器/设备固件/恶意原生域/运行时宿主沦陷/恶意胶囊/恶意驱动/DMA/恢复基础设施的系统威胁模型（Astrid Kernel Threat Model）；
• 为每个声称的安全属性创建需求到证据矩阵（Astrid Kernel Requirement-to-Evidence Matrix）；
• 记录本篇文章主题的七项 ADR。

二、ADR-K1：保护域（Protection domains）

上下文

宪章（§3）规定：一个域拥有页表、任务、能力表、预算和一个故障端点；（§2）规定域比 POSIX 进程更小——没有 fork、用户、文件描述符或全局命名空间。首台机器是单 CPU（范围文档 §6.2）。仍待决定的是域的具体形态以及域是否嵌套。

决策

保护域是隔离与权力的单位，由一个固定布局的内核对象表示，持有：

• 页表根（page-table root）；
• 能力表（ADR-K2）；
• 调度上下文（ADR-K6）；
• 单个故障端点（ADR-K5）；
• 池计费账户（pool-charge account，charter §6）。

v0 内核中的域是单线程的——一个任务、一条指令流——这与单 CPU 机器契约吻合，也与 Realm actor 模型"单线程客户边界足以支撑第一套系统"的既有验证一致。域不嵌套：不存在"父拥有子地址空间"的包含关系。监督（supervision）是一种能力关系（ADR-K5），而非结构关系。init/恢复域只是普通域，仅由测量引导计划（measured boot plan）赋予它的授权（charter §7）加以区分。

被否决的替代方案

后果

• 对象定长、池分配（对应证据REQ-MEM-1）；
• 单线程域使能力表和故障处理在 v0 中无域内竞态；
• 未来多线程是对本 ADR 的增量修改而非重写——因为这里的单线程假设只在执行模型，不在权力模型；
• 证据：REQ-CAP-4（清单声明永不是权力）、REQ-MEM-4（W^X 对全部域映射成立）。

三、ADR-K2：能力对象表示（Capability object representation）

上下文

宪章要求：不可伪造的每域句柄，携带权限掩码（rights mask）与来源（provenance），转移时只允许收缩，并同时支持范围撤销（scoped）与完整撤销（complete）（charter §4、§7）。两个成熟设计朝不同方向拉扯：

• seL4 的 CNode + 能力派生树（CDT）：撤销通过遍历树实现；
• EROS 的对象版本/分配计数：计数加一即可 O(1) 使所有未决能力失效，无需遍历。

决策

能力是域的定长能力表中的一个条目：

{ object handle, rights mask, derivation link }

被引用的内核对象携带一个代计数器（generation counter）。能力条目仅当其记录代与被引用对象当前代相等时才有效——这是 EROS 洞见，通过代递增（generation bump）实现 O(1) 的批量失效。对于范围撤销（撤销派生自某能力的一切、但不销毁对象），派生链接串联一条父→子图，在僵尸/抢占点纪律（ADR-K4）下增量遍历。

表索引不可伪造，因为它永不是指针、永不离开内核：用户空间只用表槽位（table slot）命名能力，内核解析 slot→entry→代校验对象。

被否决的替代方案

后果

• 每次能力使用付出一次代比较（廉价），每条目保留一个派生链接（一个池槽）；
• 域/对象死亡的批量失效为O(1)；范围撤销是有界的遍历；
• 表本身就是可读性表面导出的基础关系（charter §3）：所有者域、对象、权限、来源——无需独立存储（REQ-LEG-1）；
• 证据：REQ-CAP-1（句柄是不可伪造的每域表索引）、REQ-CAP-2（句柄转移只窄化权限）、REQ-FAULT-2（撤销完备性）。

四、ADR-K3：句柄转移（Handle transfer）

上下文

能力通过 IPC 在域之间移动（charter §4.2）：权限只许收缩，转移必须显式且有界，结果必须在序列化后依然有效（charter §4.5），使同一机制能跨未来的网络跳。

决策

转移是一个显式操作，携带在有界、类型化的 IPC 消息中，消息指名源槽位与权限掩码。内核在接收方表中创建新条目，其权限为requested ∩ source（绝不更多），对象句柄与代复制自源，派生链接指向源条目——扩展 ADR-K2 的图，使被转移能力既可被对象代递增撤销，也可被其祖先的范围撤销撤销。

关键约束：

• 没有环境式或隐式转移：消息未指名的能力不会被转移；域不能转移它不持有的能力；
• 转移是派生（derivation）而非移动（move）：源保留其能力，除非它显式撤销自己的（即 Realm 的 spawn 记录已在用的 "dup 后关父"形态）。

被否决的替代方案

后果

• 所有转移都是可审计的派生图边——这正是"这个域何时、从谁那里得到这项权力"可查询的原因（charter identity；审计排序见 ADR-K7）；
• 序列化干净：消息指名槽与掩码而非地址（REQ-ABI-5）；
• 证据：REQ-CAP-2。

五、ADR-K4：撤销（Revocation）

上下文

宪章（§7）要求撤销外部原子、内部可抢占，自引用撤销不可表示，且只在终态报告完成。机制必须做到这一点，同时避开 seL4 文档化的病理：中途撤销自己的权力会留下部分状态。

决策

撤销有两条路径，均来自 ADR-K2：

1. 批量失效（对象或域死亡）：递增对象代；引用旧代的每个能力在下次使用时立即失效，O(1)。对象的池槽随后由增量清扫回收，在抢占点下运行（seL4 僵尸纪律），期间对象处于显式dying状态——不可调用、不可被观察为存活、也尚未报告完成。

2. 范围撤销（撤销子委托、保住对象）：从指名能力出发遍历派生子树，增量且可抢占地使每个条目失效，对象与无关委托保持完整。

两条路径共同点：

• 完成以终态为门：死亡记录（ADR-K5）或 revoke-complete 返回只在清扫结束后发出；
• 自引用不可表示：拆除一个域的权力的唯一来源是测量引导计划（charter §7），且它永不是该域自身表中的能力——域无法持有、因此也无法撤销用于销毁它自己的权力。

被否决的替代方案

后果

• 失效即时（无陈旧权力窗口）；回收有界且可抢占（不对 hart 造成 DoS）；部分状态永不可观察（REQ-FAULT-1）；自撤销不可能发生（REQ-FAULT-3）；
• 代递增/派生遍历的拆分正是 ADR-K2 混合机制兑现收益之处；
• 证据：REQ-FAULT-1、REQ-FAULT-2、REQ-FAULT-3。

六、ADR-K5：故障端点（Fault endpoints）

上下文

宪章（§7）要求每个域终止产生恰好一条死亡记录，投递给监督者（supervisor），投递槽在域创建时预留，若监督者已死则重亲到看门狗。威胁模型标记的开放子问题：故障域应该阻塞（seL4 同步会合，无缓冲可溢出）还是排队（Erlang 异步，但我们负担不起无界邮箱）？

决策

每个域有一个故障端点（内核对象）。其监督者持有对该端点的接收能力，由测量引导计划或显式监督授权建立（绝不自持——见 ADR-K4）。死亡投递是异步进入单个预留槽：

• 域创建时，从恢复池铸一枚死亡记录槽，绑定到故障端点；
• 因此投递永不分配、永不因容量不足失败（charter §6、§7）。

这是"同步 vs 异步"问题的预留槽解决方案：取异步模型的非阻塞属性（垂死域不等活着的监督者），却没有无界邮箱——因为邮箱恰好一个槽，而且它已经存在。若记录到达时监督者已死，记录连同监督者自己的死亡记录沿监督链向上重亲，终止于看门狗；看门狗由引导计划保证存活。

被否决的替代方案

后果

• 恰好一次投递是结构性的：一个槽、铸一次、消费一次（REQ-FAULT-4、REQ-FAULT-5）；
• 拆除活性独立于监督者活性；
• 看门狗是保证的终端监督者——这正是引导计划必须预留它的原因；
• 证据：REQ-FAULT-4、REQ-FAULT-5、REQ-MEM-3（恢复容量预留，全局耗尽下拆除+死亡报告+监督者重启仍能完成）。

七、ADR-K6：调度（Scheduling）

上下文

宪章要求抢占式调度、有界工作、显式每域预算；首台机器单 CPU（范围 §6.2）。Realm 程序已把客户工作量按燃料（fuel）计量，而预留容量规则（charter §6）意味着 CPU 与内存一样必须是可问责资源。

决策

CPU 时间是一种能力：调度上下文对象（周期 + 预算），域必须持有它才能运行——形态由 seL4 的 MCS 内核验证。调度器是单 hart、抢占式、按优先级排序并强制预算：

• 域在其调度上下文有预算时运行；
• 预算耗尽将其抢占，并引发其监督者可观察的有界超时条件；
• 可能长时间运行的内核操作（撤销清扫，ADR-K4）正是预算所约束的可抢占工作——同一批抢占点同时服务调度与撤销；
• 预留：恢复域与看门狗域持有的调度上下文保证它们在争用下仍获得 CPU，镜像预留内存池。

被否决的替代方案

后果

• CPU 与其他权力完全一样可委托、可衰减——子调度上下文是更短预算，绝不是更长（宪章的递归衰减原则）；
• 预算耗尽是有界、可观察事件（对应 MCS 超时异常设计）；
• 现在单 hart；SMP 是本 ADR 的 scope-M7 变更；
• 证据：REQ-MEM-3（为恢复预留 CPU）、REQ-FAULT-6（无限循环 → 有界拆除）。

八、ADR-K7：审计排序（Audit ordering）

上下文

宪章（§3、§7）要求 ring 0 锚定一个序列或根哈希，且永不解释记录；现有 Astrid 审计链是用户空间构建的BLAKE3 密封、ed25519 签名链。待决策的是：ring 0 提供什么排序保证，密码链放在哪里。

决策

ring 0 对可审计的跨域事件（能力派生、域生命周期、故障记录）盖上单调全序——通过单个内核持有的序列计数器；并通过维护**运行中的根（running root）**锚定完整性：每个盖章事件推进一个哈希累加器，其当前值 ring 0 会证明（attest）但永不解析。

密码链本身在用户空间构建：由审计系统宿主域（威胁模型中的 T3）读取有序事件流，用 BLAKE3 密封每条目（哈希前一条），用 ed25519 签名——与现有 Astrid 审计设计完全不变。职责划分：

• ring 0 保证：顺序与无缺口（每个序列号都被记账）；
• 用户空间保证：防篡改与真实性。

二者组合：验证者对照 ring-0 证明的根检查用户空间链，因此被攻破的审计域不能静默丢弃或重排事件而不使根发散。

仓库佐证：现有用户空间审计链实现在 crates/astrid-audit 中。其 README 说明每条AuditEntry含动作/授权证明/结果、链接前一条目的 BLAKE3previous_hash（创世条目使用ContentHash::zero()）、签名该条目的运行时 ed25519 公钥与签名；验证按会话检查三条不变量（有效创世、有效签名、链接不断），每条失败是类型化ChainIssue。具体字段在 src/entry.rs 中：previous_hash: ContentHash、runtime_key: PublicKey、signature: Signature。链的密封序号与prior_receipt_hash的 BLAKE3 校验在 src/storage/prune_chain.rs 中可见。这正是 ADR-K7 "ring 0 锚定、用户空间建链"分工下，用户空间侧已有工程基础。

被否决的替代方案

后果

• ring 0 的审计表面是一个计数器 + 一个哈希累加器——TCB 极小，无记录解析（charter §2）；
• 现有用户空间链整体复用；
• "系统何时从谁那里学到 X"与"证明审计日志无缺口"都可核查——这是内核事实与用户空间推理者/表述者的接缝：有序、有根的事件流正是后来的推理者当作事实读取的东西；
• 证据：REQ-LEG-1（单一事实来源）以及现有审计测试承载的审计链符合性。

九、跨切面后果：一条脊柱，三个机制

七项决策共享一条脊柱：

这是刻意的：少量机制承载大量属性，比"一个属性一个机制"更易验证、更易模糊测试。v0 ABI 草图（下一工作计划项）恰好只暴露这些：域、能力表槽、调度上下文、故障端点、审计有序事件表面——除此之外不暴露任何需要路径、字符串主体或环境式句柄的东西（对应宪章 §2 的"字符串即权力"禁令与REQ-CAP-3：ABI 表面审查 + 编译期检查无任何 syscall 接受路径/URI 参数）。

与证据矩阵的映射速查

矩阵（docs/astrid-kernel-evidence-matrix.md）规定"属性未到测试失败即证明丢失之前不算持有"，并区分host、qemu、fuzz、build证据种类与 M1–M6 门槛。七项 ADR 直接引用的关键行：

• 能力与句柄完整性：REQ-CAP-1（伪造索引被拒，qemu/M2）、REQ-CAP-2（加宽权限被拒，qemu/M2）、REQ-CAP-3（无字符串主体，build/M1）、REQ-CAP-4（清单声明不是权力，qemu/M3）；
• 内存与池纪律：REQ-MEM-1（定长槽、不可碎片化饿死，host+qemu/M2）、REQ-MEM-2（每次铸币可失败可归因，qemu/M2）、REQ-MEM-3（恢复容量预留，qemu/M2）、REQ-MEM-4（W^X，qemu/M2）；
• 撤销与故障语义：REQ-FAULT-1（外部原子）、REQ-FAULT-2（撤销完备）、REQ-FAULT-3（自引用撤销不可表示）、REQ-FAULT-4（恰好一条死亡记录）、REQ-FAULT-5（投递不因容量失败）、REQ-FAULT-6（组件陷阱留在 Wasmtime 内，qemu/M3）；
• ABI 与解析器边界：REQ-ABI-1（全操作全函数）、REQ-ABI-2（边界处恰好一次复制校验）、REQ-ABI-3（解析器抗对抗输入，fuzz）、REQ-ABI-4（无无界长度消息，host/M1）、REQ-ABI-5（序列化下语义保持，host/M2）；
• 可读性与信道：REQ-LEG-1（内核状态单一事实来源，无镜像事实库）、REQ-LEG-2（每关系能力门控、仅域可见）、REQ-LEG-3（时序相关关系限流与量化）。

十、结语：为什么"被否决的方案"与"被选择的方案"同等重要

从表面看，七项 ADR 回答了"域长什么样、能力怎么表示、句柄怎么转移、怎么撤销、故障怎么投递、CPU 怎么调度、审计怎么排序"七个问题。但这份文档的深层价值在于记录约束如何参与决策：

1. 契约（covenant）先行：POSIX 进程形态、信号处理器式故障处理、ring 0 内建密码链——都不是因为"难"而被否决，而是因为宪章 §2 永久排除了它们；
2. 威胁模型参与否决：惰性回收被否决是因为它重开威胁模型 §6 关闭的陈旧引用窗口；协作调度被否决是因为它无法约束永不让出的恶意域；
3. 机制复用优先：代递增与派生遍历的混合（ADR-K2/K4）、预留槽同时解决投递容量与调度预算（ADR-K5/K6）、一个序列计数器加哈希累加器完成审计排序（ADR-K7）——少量机制承载多属性，是这份决策日志贯穿始终的主线；
4. 每条决策都锚定证据：从REQ-CAP-1到REQ-LEG-1，每个后果都有对应的可执行检查、证据种类与里程碑门槛，保证这些架构选择不只是文档中的漂亮段落，而是可被测试证伪的工程承诺。

对于想深入代码的读者，可从 crates/astrid-audit（ADR-K7 的用户空间链侧）与 crates/astrid-crypto（BLAKE3 哈希与 ed25519 签名原语）继续追踪；而内核本身的骨架与 ABI 草图，则在工作计划中列为后续里程碑，其证据逐项挂在 证据矩阵 上等待兑现。