LynxSecure：静态分离内核 / 该恢复什么 / 边界怎么找

这是一个**极端的静态分离**设计，而且**没有中央管理内核**：

boot 时定义、不可变的硬件分区
不可变的硬件强制隔离（从加电到断电持续保持）
内核空间功能仅限：资源分区、控制分区之间的数据流、调解对系统状态变更函数的访问
I/O 与应用支持【全部导出到用户态 guest】

于是最反直觉的一条是：

运行态找不到完整的"VM 配置器 / 动态 MMU 配置引擎"
  → 与该模型自洽
  → 不要得出"固件被裁剪 / 被破坏"

</CORE RULE>

说明：该系统多数实现细节不公开。下面区分两类内容——【官方表述】（可直接引用）与**【该恢复什么】**（方法论，用于指导分析，不是对实现的断言）。

一、官方表述（判断"缺什么算正常"的依据）

boot 时定义、不可变的硬件分区；不可变的硬件强制隔离，从加电到断电持续保持
最小特权：内核空间功能有限——资源分区、控制分区之间的数据流、调解对系统状态变更函数的访问
按开发者要求，把 I/O 与应用支持全部导出到用户态 guest——内核里没有驱动、I/O 栈与应用 API
运行期约束（官方列举）：
- 没有 hypervisor/管理控制台登录
- 没有动态系统修改
- 一个 guest 不能访问另一个 guest 的资源
- hypervisor 自身也不能访问 guest 的资源
- 可 DMA 设备不能访问 guest 资源

（说明：公开资料未直接证实"用于初始配置的特权 setup code 随后被丢弃"这一具体机制；上面列的是官方明确表述的部分——判断"缺什么算正常"用它们即可。）

二、该恢复什么（逆向工作台层）

1. 配置是最重要的 artifact，优先于代码

资源在 boot 时被规定成固定、不可变的划分。所以第一优先级是恢复"谁拥有什么"：

CPU 核归属 / 内存区归属 / I/O 与设备归属

做法：配置本身（如果拿得到）是最高价值；拿不到就从各 guest 可见的资源范围反推——把每个 guest 能看到的物理范围并起来，缺口就是别的分区，重叠就是可疑点。

2. 启动阶段是唯一能看到"配置生效"的窗口

因为运行期没有动态系统修改，映射与归属都是启动期建立的：

追映射、追资源分配 → 在启动阶段做
运行期只应看到"已经确定"的状态

所以：如果运行期看到"某资源在动态重新分配"，先怀疑你看到的是别的东西（例如 guest 内部的分配），而不是内核在重配置。

3. 边界怎么找：从"三项职责"反查

官方把内核功能限定为三件事，这三件事出现在哪里，哪里就是分界：

职责	观察点
资源分区	谁在读/写"划分表"一类的结构
控制分区之间的数据流	跨分区的数据通路在哪被拦截/校验
调解对系统状态变更函数的访问	系统状态变更入口的守门代码

推论：内核里不应有驱动、I/O 栈与应用 API——所以

在一个映像里看到完整驱动/I/O 栈
  → 那一块大概率不是内核

4. 跨分区通信在内存里长什么样

设计上是无共享内存的：硬件强制的隔离意味着不存在"两个分区共享同一块物理内存"的常规通路
跨分区的数据流由内核控制——所以找的是受控通道（数据流被拦截/校验的路径），不是共享页
这与"共享内存 + 通知"型系统（见 re-hypervisor/xen、re-hypervisor/hyperv-vmbus）方向相反：先找控制点，再找数据通路

5. IOMMU / 设备归属怎么验证

官方约束可以直接当验证判据：可 DMA 设备不能访问 guest 资源、hypervisor 自身不能访问 guest 资源。

于是：

拿一条 DMA 通路问：它的源与目标分别属于哪个分区？
若答案是"跨了不该跨的边界" → 与模型矛盾，值得深挖
若答案是"同一分区内" → 与模型自洽

6. fault path 与"8 MB 里哪一段是 monitor"

最小内核意味着异常入口很窄：找"分区被 violated 之后控制权交给谁"，那一段就是核心
结合第 3 节的三项职责定位：读划分表 / 拦数据流 / 守系统状态变更入口的代码块属于内核；周围的驱动与 I/O 栈属于 guest

决策树

拿到一份静态分离内核的映像
├─ 先问：配置拿得到吗
│    ├─ 拿得到 → 据它恢复 CPU/内存/I/O 归属，再解释代码
│    └─ 拿不到 → 从各 guest 可见范围反推，缺口=别的分区
├─ 找不到"VM 配置器/动态重配置"
│    └─ 与"静态配置 + 无动态系统修改 + 无管理登录"自洽
├─ 要追映射
│    └─ 在启动阶段追；运行期不应有重配置
├─ 要定位内核本体
│    ├─ 找三项职责：读划分表 / 跨分区数据流拦截 / 系统状态变更守门
│    └─ 内核里不该有驱动与 I/O 栈 → 有驱动的块大概率不是内核
├─ 跨分区通信
│    └─ 找受控通道，不是共享页（与共享内存型系统方向相反）
├─ 验证隔离
│    └─ 用官方约束当判据：DMA 设备 / hypervisor 自身都不应触及 guest 资源
└─ 运行期看到"资源被重新分配"
     └─ 先怀疑那是 guest 内部行为，内核本不该做这件事

工具与验证

配置：CPU/内存/设备归属的静态划分（配置本身或从 guest 可见范围反推）
启动：启动阶段建立映射与归属的过程（唯一能看到"配置生效"的窗口）
边界：三项职责的落点；驱动/I/O 栈的存在与否
通信：受控通道而非共享页
验证：能同时说清「谁拥有哪块资源 + 这段代码属于内核还是 guest + 这条数据流是否跨了分区」

该平台的坑（汇总）

把"缺少集中管理代码"当代码被裁剪：静态配置模型本来就如此
在运行期找"重配置"逻辑：没有动态系统修改；该在启动阶段找
把 guest 内部的资源分配当成内核在重配
在内核区域里期待驱动：I/O 与应用支持被导出到 guest
按"共享内存 + 通知"找跨分区通信：这里是受控通道、无共享内存
拿"hypervisor 能读 guest 内存"当默认假设做取证：官方明确相反
把可 DMA 设备的中介缺失当漏洞：隔离模型要求它不能触及 guest 资源
以为有管理控制台入口：官方明确没有

6.6 KiB Raw Blame History Unescape Escape