reverse-skills-max: initial public release (restored, redacted, hardened)

vendor-new/rev-skills/.claude/skills/re-hypervisor/references/lynxsecure.md

@@ -0,0 +1,140 @@
+# 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 资源
+- **以为有管理控制台入口**：官方明确没有