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

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

```
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 资源
- **以为有管理控制台入口**：官方明确没有