---
name: re-hypervisor
description: >
  虚拟化逆向：VT-x/SVM、hypervisor 检测、VMCS/EPT 分析，
  以及 Xen / QNX Hypervisor / Jailhouse / ACRN / Bao / Hyper-V·VMBus / XtratuM / LynxSecure / Quest-V 的分区与 vdev 语义。
  触发词：hypervisor、VT-x、SVM、虚拟化检测、EPT、Xen、grant table、event channel、
  Jailhouse、cell、ACRN、ivshmem、Bao、shmem_id、vdev、GPA/HPA、
  Hyper-V、VMBus、VSC、VSP、GPADL、SR-IOV、XtratuM、XM_CF、LynxSecure、Quest-V、sandbox kernel
capabilities: [hypervisor-analysis]
---

# 虚拟化逆向（VT-x / SVM / 分区 hypervisor）

<CORE RULE>
本域有两条互不相同的分析轴，先分清在哪一条上：

- **轴 A：分析 hypervisor 本身**（VT-x/SVM 指令、VMCS/VMCB、EPT/NPT）→ 本主文档
- **轴 B：目标处在某种虚拟化之下**，判断"看到的地址/设备/中断是不是虚拟化层造出来的"→ 见 [[xen]] / [[qnx-hypervisor]] / [[jailhouse]] / [[acrn]] / [[bao]]

轴 B 的共同坑是**把本地句柄当全局标识、把虚拟地址当物理地址**：

```
grant ref 是 grant table 的条目索引      ≠ 物理地址
event-channel port 是通知端口           ≠ IRQ 号
guest BAR / GPA                         ≠ 物理 BAR / HPA
shmem_id 才是共享对象 identity          ≠ 两个 VM 里的映射地址
```
</CORE RULE>

## 何时使用 / 何时不用

- 前置：**先判是哪一类虚拟化**（宿主厂商串 / 配置格式 / 结构性证据）→ [[re-analyze/system-fingerprints]] 的 Hypervisor 段
- 用：目标是 hypervisor / VMM 二进制或驱动（恶意 hypervisor、rootkit 虚拟化、VM-based 保护）
- 用：样本/程序检测自己是否运行在虚拟机或嵌套虚拟化中（CPUID 指纹、时序检测）
- 用：分析 VT-x（VMX）或 SVM 相关的启动代码、VMCS/VMCB 布局、EPT 相关操作
- 用：**目标跑在分区/嵌入式 hypervisor 之下**——PV 设备、静态分区、vdev、跨 VM 共享内存与虚拟中断（见下方分支）
- 不用：普通 Windows 驱动/rootkit（走 [[re-kernel]]）；只要识别"我在不在 VM 里"（快速判断走 [[re-triage]] 思路或 `virt-what`）
- 不用：无 CPU 虚拟化支持 / 无嵌套虚拟化环境时的动态验证（静态分析先行，见坑 1）
- 注意：动态实验（QEMU/KVM 嵌套）按 [[re-analyze/platform-tips]] 最高原则在沙箱内进行；hypervisor 样本具有高特权，只在与宿主隔离的实验环境运行

## 工具准备

静态分析（CPUID 检查 / 反编译）免沙箱；QEMU/KVM 动态实验属动态执行，默认沙箱 + 快照（[[re-analyze/platform-tips]] 最高原则）。

### CPUID 检查工具（hypervisor 识别）

- Linux 内置：`grep -E 'vmx|svm' /proc/cpuinfo`——VT-x/SVM 支持标志（零安装，先用它）
- `cpuid` 工具（dump 各 CPUID 叶子的完整输出）：
  - Debian/Ubuntu: `apt install cpuid`；Fedora: `dnf install cpuid`
  - Arch 无独立 cpuid 包 → 用 `kcpuid`（`pacman -S kcpuid`，linux-tools 组）或 libcpuid 附带的 `cpuid_tool`（`pacman -S libcpuid`）
  - 验证: `cpuid -1` 输出含各叶子详情；`cpuid -1 -l 0x40000000`（hypervisor 厂商字符串叶子）
- Windows 侧：WinDbg 内核调试下 `!cpuid`（[[re-windbg]] 扩展命令）

### QEMU / KVM —— 嵌套虚拟化实验环境

- Debian/Ubuntu: `apt install qemu-system-x86`（**Debian 12+ 已移除 qemu-kvm 过渡包**，直接装 qemu-system-x86 即含 `qemu-system-x86_64`；Ubuntu 的 qemu-kvm 过渡包仍存在，装了等价于 qemu-system-x86；Ubuntu 另加 `libvirt-daemon-system`）
- Fedora: `dnf install qemu-system-x86-core libvirt virt-install`（或 `dnf group install virtualization`）
- Arch: `pacman -S qemu-system-x86 libvirt virt-manager`（启用 `systemctl enable --now libvirtd`）
- macOS: `brew install qemu`（无 KVM，用 HVF）
- 验证: `qemu-system-x86_64 --version`；`ls /dev/kvm`（KVM 加速可用）；`kvm-ok`（Debian/Ubuntu 专用，来自 cpu-checker 包——先 `apt install cpu-checker`）

### 反编译工作台（[[re-ghidra]] / [[re-ida]]）

- [[re-ghidra]]（默认）/ [[re-ida]]：导入 hypervisor 二进制（内核模块 / 裸二进制）
- 验证: 导入后能反编译出 VMXON / VMPTRLD / VMREAD / VMWRITE 调用点

### Intel SDM / AMD APM（VMCS 字段编码参考，无安装）

- Intel SDM Volume 3C 附录 B（VMCS field encoding 表）；AMD APM Volume 2（VMCB 布局）
- 用途: VMREAD/VMWRITE 操作数解码、exit reason 编号对照（无独立包，官方文档）

## 操作步骤

按顺序执行，每步产物（CPUID 输出、VMCS 字段表、QEMU 配置）记录证据路径 + sha256（见 [[re-triage]]），供报告引用。

1. **hypervisor 识别（CPUID 叶子 / VMX 标志）**：
   ```sh
   grep -E 'vmx|svm' /proc/cpuinfo | head -1        # 宿主 CPU 虚拟化支持
   cpuid -1 -l 0x1 | grep -i -A1 'hypervisor'        # CPUID.1:ECX[31] hypervisor present bit
   cpuid -1 -l 0x40000000                            # 0x40000000 叶子的 hypervisor 厂商字符串
   #   "KVMKVMKVM" = KVM、"Microsoft Hv" = Hyper-V、"VMwareVMware" = VMware、"XenVMMXenVMM" = Xen
   ```
   - 检测要点：hypervisor present bit（CPUID.1:ECX[31]）→ 有 hypervisor；`0x40000000` 返回厂商字符串（12 字符按序分布在 EBX:ECX:EDX 各 4 字节，EAX 返回最大 hypervisor 叶子号）
   - 恶意样本常在启动早期做此检测决定后续行为（[[re-evasion]] 联动，见坑 5）
   - 记录：宿主支持情况（vmx/svm）、是否已在 VM 内（含嵌套，坑 4）

2. **VMCS 结构分析（VT-x）**：
   - 启动路径：`VMXON`（进入 VMX 操作模式）→ `VMPTRLD`（加载当前 VMCS）→ 配置 VMCS 字段 → `VMLAUNCH`/`VMRESUME`（进 guest）→ VM exit 后查 `VM_EXIT_REASON` 字段分派
   - 反编译定位：搜 `VMXON`/`VMPTRLD`/`VMWRITE`/`VMREAD`/`VMLAUNCH` 指令（Ghidra 反汇编直接可读）；VMCS 区域是内存块，先找 VMCS 缓冲区分配与初始化代码
   - **VMREAD/VMWRITE 的操作数是 VMCS 字段编码**（32 位，Intel SDM 附录 B 表 B-1~B-4）：**bit0 = 访问类型**（0=full field、1=high 32 bits）；**索引在 bits 9:1**（9 位，不是 bits 9:0）；类型在 bits 11:10（00=control、01=read-only、10=guest-state、11=host-state）；宽度在 bits 14:13（00=16 位、01=64 位、10=32 位、11=natural）；bit 12 与 bits 31:15 保留（必须为 0）。解码示例：0x400C=VM-exit controls（32 位，bits 14:13=10）、0x2000=I/O bitmap A（64 位，bits 14:13=01）、0x681E=GUEST_RIP（natural，bits 14:13=11）、0x681C=GUEST_RSP（natural）、0x4402=VM-exit reason（32 位 read-only）——即 `access=enc&1; index=(enc>>1)&0x1ff; type=(enc>>10)&3; width=(enc>>13)&3`，在 Ghidra/IDA 里建枚举/结构标注
   - 关注三块：guest-state（保存 guest 寄存器/CR3/RSP）、host-state（VM exit 后宿主现场）、control 字段（execution control 决定哪些事件触发 VM exit）
   - SVM 对应：VMCB（物理地址经 `VM_HSAVE_PA` MSR），字段是固定偏移——按 AMD APM 布局标注
   - 产物：VMCS 字段标注表（编码 → 字段名 → 作用）+ 初始化/exit 处理流程

3. **虚拟化技术检测对抗（EPT 隐藏内存）**：
   - EPT（Extended Page Tables）：guest 物理地址 → 宿主物理地址的第二层页表（VMM 控制）；恶意 hypervisor 可用 EPT 把同一 guest 页映射到不同宿主页、或在 EPT 层面修改页内容而 guest 页表看起来不变
   - 分析思路：反编译里找 EPT 相关操作——`INVEPT`/`INVVPID`（TLB 失效）使用点、EPT 指针字段（VMCS `EPTP`）赋值、EPT 页表构建函数（从 EPT 指针沿页表结构走）
   - 检测对抗的观察法：guest 内看到的内存内容与宿主侧直接读同一物理页不一致 → EPT 重映射证据（两个视图对照）；[[re-kernel]] 内核调试配合在宿主与 guest 两侧各 dump 同一页
   - **EPT Hook 双视图机制**（无痕 hook 核心）：同一 GPA 准备两个 HPA——原始页（RW/NX）与影子页（X-only 或补丁代码）——数据访问映射原始页、指令取指映射影子页；CPU 取指触发 Execute Violation（VM-exit reason 48）后在 VM-exit 里切影子页并 INVEPT 失效缓存；扫描器/CRC 读地址得到干净字节，执行却是补丁代码（读侧无痕）
   - **EPT 无痕 INT3**：只在影子页放 `0xCC`，原始数据页不变——读内存看到原指令、取指却断下；VMCS Exception Bitmap 拦截向量 3 后匹配地址用 `guest_rip - 1`（一字节 INT3 的 RIP 在断点字节之后）；处理完单步恢复再重新布断点；非本框架的 #BP 必须 reinject 回 guest（不能吞其他调试器/系统断点）
   - **MTF（Monitor Trap Flag）解决"读执行同页"**：影子页指令若读取同页常量（取指要影子页、数据要原始页冲突）→ 临时放开原始页执行并置 MTF，CPU 单步执行一条指令后在 MTF VM-exit 里收紧权限；MTF 是 VM-execution control，不动 guest RFLAGS.TF、不占 DR0-DR7
   - **EPT 监视 = 模拟无限硬件断点**：DR0-DR3 仅 4 槽，EPT 监视撤销目标页 R/W/X 权限让匹配访问 VM-exit，数量仅受内存/性能限制；硬件断点类需求（含与传统调试器互通，如 hook `SetThreadContext` 探测是否下硬件断点再转发到 EPT 监视）用这套替代
   - **VMCALL 无痕通信**：guest 执行 VMCALL 产生 VM-exit reason 18（不调用 guest 内任何地址），RAX 放协议标识、RCX 放操作号、其余寄存器传参，是 hypervisor 与 guest 的私有通信通道
   - 产物：EPT 构建/切换代码路径 + 内存视图差异证据

4. **嵌套虚拟化（VMM 内调试）**：
   ```sh
   # KVM 开启嵌套（宿主）——module_param 权限为 0444，sysfs 只读，echo 写入会失败
   sudo modprobe -r kvm_intel && sudo modprobe kvm_intel nested=1    # Intel（AMD 用 kvm_amd nested=1）
   # 持久化：/etc/modprobe.d/kvm.conf 写 `options kvm_intel nested=1`（重启后仍生效）
   cat /sys/module/kvm_intel/parameters/nested                       # 验证（Y/1 为已开启）
   # QEMU 启动带 VT-x 透传的嵌套 VM（`-cpu host` 暴露 vmx 标志）
   qemu-system-x86_64 -enable-kvm -cpu host,+vmx -m 4096 disk.img &
   # 嵌套 VM 内再验证: grep vmx /proc/cpuinfo 可见 → 可在此跑 hypervisor 样本
   ```
   - 用法：宿主上的调试器（gdb/lldb 或 [[re-windbg]] 内核调试）直接观察嵌套 VM 内 hypervisor 的执行——样本以为自己在最底层，实际仍在宿主调试视野内
   - VMware/Hyper-V 同理（虚拟机设置里开"虚拟化引擎/嵌套虚拟化"）
   - 产物：嵌套配置存档 + 调试会话记录

5. **反虚拟化绕过（[[re-evasion]] 联动）**：
   - 识别检测手段：CPUID 厂商字符串（步骤 1）、时序（RDTSC 指令耗时）、设备名（VM 虚拟设备）、固件/ACPI 特征
   - 按 [[re-evasion]] 的"规避识别→绕过点定位"框架：hook CPUID（cpuid 是**指令**而非导出符号，`findExportByName` 拿不到——改 hook libc 导出函数 `__get_cpuid`/`__get_cpuid_max` 改返回值，或 Stalker 指令级追踪拦截 cpuid 指令；内核侧 hook/patch 指令）、QEMU `-cpu` 参数伪造厂商字符串、设备名改名
   - 恶意样本"检测到 VM 就改变行为"（不执行恶意逻辑）也是常见对抗——记录检测点与分支
   - 产物：检测点清单 + 绕过方案（授权研究场景）

## 平台分支（references）

**轴 B**：目标是"跑在某种虚拟化之下的系统"，要判断哪些现象是虚拟化层造出来的正常机制。

- [[xen]] —— **PV 前后端四件套**（XenStore / grant table / shared ring / event channel）；**grant ref 是条目索引**（条目含 flags/domid/frame，且**映射期间不支持撤销**）；**event-channel port 不是 IRQ 号**（绑定到 `shared_info` 位掩码）；**迁移后本地端口会变、稳定的是 remote port**；shared ring 上"有数据流动却无 IPC 调用"属正常
- [[qnx-hypervisor]] —— **三层地址**（guest virtual → guest physical/IPA → host physical）；**vdev** 使 guest DT ≠ 板级 DT；**shmem vdev** 的工厂页（`name`/`size`/`shmem`/`vector`/`status`，写 `size` 触发创建，故 guest 启动顺序无关）与控制页（`status`/`idx`/`notify`/`detach`）；`intr pass` vs `intr vdev`；直通设备同一时刻只允许一个 resident
- [[jailhouse]] —— **配置比 inmate ELF 更重要**（CPU/内存/IRQ/PCI 归属）；越权访问 → **CPU 被 park**（不是 guest 崩溃）；**`JAILHOUSE_MEM_LOADABLE` 映射在 cell 启动时被撤销**（重装走 Cell Set Loadable）；**ivshmem 不维护 pending 语义**（MSI-X PBA 恒 0，事件状态从共享内存协议读）；hypervisor VA 里扫不到全部 VM 内存
- [[acrn]] —— **Service VM / pre-launched / post-launched** 三态与三种 I/O 服务路径；**guest BAR ≠ 物理 BAR**（EPT 映射，MSI-X 表页必须 trap）；posted interrupt 使 VM-exit 减少；**ivshmem 的 dm-land 与 hv-land 永不互通**（前缀 `dm:/` vs `hv:/`，且 dm-land 无 doorbell）
- [[bao]] —— **静态分区**（CPU/内存/中断独占，vCPU 与 pCPU 1:1，无调度器）；**共享对象 identity 是 `shmem_id` 而非地址**；IPC 的 `size ≤ 对应 shmem 大小`；**cache coloring** 抑制干扰但有代价（牺牲大页、增加 TLB 压力）且随平台颜色数截断
- [[hyperv-vmbus]] —— **VSC / VSP 经 VMBus**（双向通道 = 两个 ring buffer；高速设备可用多通道）；**GPADL 是缓冲区描述句柄不是地址**（共享总量有上限）；**SR-IOV 让数据面中途换路**（VF 直通绕开 VMBus 与 hypervisor，控制面仍在 VMBus）
- [[xtratum]] —— **XM_CF 配置驱动**（分区/内存/中断/端口/通道/调度全在配置里，运行期无动态对象）；**循环计划（MAF + 时间槽）与固定优先级计划**；**Plan 0 = 初始化、Plan 1 = 维护**，切换要等当前计划剩余槽跑完；**IPVI 每分区最多 8 个**
- [[lynxsecure]] —— **静态分离内核**：boot 时定义、不可变的硬件分区；内核功能仅限**资源分区 / 控制分区之间的数据流 / 调解系统状态变更入口**；**I/O 与应用支持全部导出到 guest**（内核里没有驱动与 I/O 栈）。含**逆向可操作层**：配置优先于代码、启动阶段是唯一能看到"配置生效"的窗口、**用三项职责反查内核边界**、跨分区找受控通道而非共享页、用官方约束验证 DMA/hypervisor 与 guest 的隔离
- [[questv]] —— **多内核 sandbox + 每 sandbox 一个 monitor**：monitor 只在引导/故障/影子页表/建通道时介入；EPT 用于**内存隔离**而非 CPU 虚拟化；中断直接投递 sandbox；**EPT violation → VM-exit 到对应 monitor**（必要时强制触发陷入）；本地/远程**在线恢复**；**无全局时钟**。含"哪一段是 monitor"的定位判据

## 跨域联合

- [[re-evasion]]：反虚拟化检测/绕过框架（CPUID hook、时序对抗）；恶意样本 VM 检测行为分析
- [[re-kernel]]：hypervisor 驱动/内核模块分析底座（DriverEntry、IRP、内核调试配合）
- [[re-windbg]]：Windows 宿主/guest 内核调试（`!cpuid` 查 CPUID 叶子、驱动加载观察）
- [[re-ghidra]] / [[re-ida]]：VMCS/VMCB 相关代码反编译与结构标注（SDM 附录 B 建枚举）
- [[re-sandbox]] / [[re-analyze/platform-tips]]：QEMU/KVM 实验环境隔离最高原则；嵌套 VM 是默认沙箱形态
- [[re-triage]]：初勘阶段"是否在 VM 内 / CPU 虚拟化能力"快速判断（`virt-what` 思路）

## 常见坑与陷阱

- **硬件虚拟化调试环境复杂**：现象——hypervisor 样本在普通 VM 里跑不起来/直接崩溃，调试器附加失败，样本检测到嵌套环境后行为异常；原因——嵌套虚拟化需要宿主 CPU 支持 + 显式开启（KVM nested / Hyper-V / VMware 选项），且样本会检测自己是否"真的在底层"；对策——先纯静态积累信息（步骤 1-2 的 CPUID 与 VMCS 分析不需要跑样本），动态前确认三层能力：宿主 vmx/svm 标志（`grep vmx /proc/cpuinfo`）→ 嵌套开关（`/sys/module/kvm_intel/parameters/nested`）→ QEMU `-cpu host` 透传；实验全部在隔离沙箱（[[re-analyze/platform-tips]] 最高原则）
- **VMCS 内核对象逆向门槛高**：现象——反编译里 VMREAD/VMWRITE 一堆魔数，不知道读写的是什么字段，VM exit 分派逻辑看不懂；原因——VMCS 是硬件定义格式（字段编码不是符号），且各 CPU 架构（VT-x vs SVM）布局完全不同；对策——把 Intel SDM 附录 B 的字段编码表建进反编译器（Ghidra 枚举/结构），VMREAD/VMWRITE 操作数逐一解码；按 guest-state / host-state / control 三块组织分析；AMD 目标改用 VMCB 固定偏移布局（APM Volume 2）
- **EPT 使内存断点失效**：现象——调试器在 guest 里下的内存断点/页保护断点不触发或触发后行为诡异（寄存器对不上）；原因——EPT 的访问位/脏位独立于 guest 页表，VMM 通过 EPT 控制 guest 看到的内存视图（含隐藏页），普通调试器断点基于 guest 页表视角；对策——区分 EPT violation（VM exit reason 48）与 guest page fault（reason 14）；要观察 EPT 层必须看 EPT 页表结构本身（沿 VMCS EPTP 字段展开）而不是 guest 页表；[[re-kernel]] 内核调试下对照宿主/guest 两侧内存视图
- **CPU 特性差异（VT-x vs SVM）**：现象——在 Intel 机器上整理的 VMCS 偏移/exit reason 编号拿到 AMD 机器全对不上，或相反；原因——VT-x 与 SVM 是两套独立实现：VMCS（VMREAD/VMWRITE 编码）vs VMCB（固定偏移），exit reason 编号体系不同；对策——先确认目标平台（CPUID vendor + vmx/svm 标志，步骤 1），按平台选对应手册（Intel SDM Vol 3C / AMD APM Vol 2），分析笔记标注目标平台与 CPU 型号，不跨平台复用字段表
- **样本检测 VM 后改变行为（影响结论）**：现象——静态分析很清晰的恶意逻辑，动态运行时完全看不到（样本"正常"运行）；原因——样本检测到自己在 VM/调试环境里会走"无害分支"（反沙箱/反调试常见手法）；对策——按步骤 1 先确定样本视角的虚拟化状态，动态验证必须与样本检测条件一致（或逐项绕过检测）；结论以"检测点还原 + 绕过后的行为"为准，单跑一遍就下结论不可信
- **AMD NPT 不能照搬 EPT 方案**：现象——Intel 上可用的"只执行页"技巧（影子页 X-only）在 AMD 平台失效；原因——NPT 与 EPT 是两套独立实现，**NPT 不能单独设置只执行属性**（读与执行位绑定）；对策——跨平台实现 hook/隐藏前先确认目标是 Intel（EPT）还是 AMD（NPT），AMD 需换用其他手段（如结合 NX + 数据视图）
- **"VT 无痕读写"是伪命题**：现象——以为 EPT 能无痕读写任意数据段；原因——影子页表只能无痕改写"代码段"（取指视图切换），数据段无法同时满足两侧视图（读原始 vs 写影子）；对策——无痕写仅限代码段场景（hook 场景）；数据段读取仍靠遍历四级页表（GVA→GPA→HPA 二阶段翻译）直读物理页，与普通驱动思路无本质区别
- **RDTSC 检测 VM-exit 开销可被补偿**：现象——样本用 `__rdtsc/__rdtscp` 测指令耗时差值识别 hypervisor；原因——VM-exit 有固定开销可测量；对策——VM-exit 汇编入口最早记录 `exit_tsc`，`ReadVirtualTsc` 用有界平滑估计补偿（不能把中断/调度长尾全当 exit 成本），并保证每 vCPU 单调（`max(value, last_guest_tsc+1)`）；原则：样本检测哪里，就在 VM-exit 里处理哪里
- **把跨 VM 的本地句柄当全局标识**：现象——trace 里同一个整数在两个域/VM 里出现，被当成同一个对象；原因——grant ref 是条目索引、event-channel port 是通知端口、shmem_id 才是共享对象 identity，本地端口在重连后还会变且可被重用；对策——按各自的表/配置对齐（grant table 条目、shared_info 位掩码、shmem_id），见 [[xen]] / [[bao]]
- **把虚拟地址当物理地址**：现象——guest 里的 MMIO 地址在真实硬件上找不到对应，就判驱动写错或抓错设备；原因——PV 设备没有寄存器窗口；分区 hypervisor 下 guest 的 BAR/GPA 与物理 BAR/HPA 之间隔着 EPT/NPT 或直通映射；vdev 的地址由配置制造；对策——先判"直通还是 vdev/模拟"，再谈地址是否一致，见 [[qnx-hypervisor]] / [[acrn]] / [[jailhouse]]
- **把 hypervisor 的保护动作当 guest 崩溃**：现象——程序在访问某地址后"突然停住"，却找不到常规缺页/总线错误证据；原因——静态分区 hypervisor 会把越权访问的 CPU/cell **park 掉**（Jailhouse）；对策——查 hypervisor 侧日志（Unhandled trap / Parking CPU），并对照 cell/VM 配置的资源归属（[[jailhouse]]）
- **跨 VM 共享内存通不了就往设备模型里找**：现象——两侧 ivshmem 都"正常"但完全无法通信；原因——ACRN 的 dm-land 与 hv-land 是两套实现，前缀（`dm:/` 与 `hv:/`）不同则永不互通，且 dm-land 没有 doorbell 通知；对策——先核对实现与前缀是否一致，再看数据面（[[acrn]]）
- **把 GPADL 之类的描述符当内存地址**：现象——trace 里的小整数被当地址或偏移参与推算；原因——GPADL 是"描述并映射一片客户机缓冲区"的句柄，且宿主对其共享总量有限制；对策——按句柄语义还原它指向的缓冲区（[[hyperv-vmbus]]）
- **网络流量中途"消失"却功能正常**：现象——一段时间 VMBus 很忙，之后抓不到包但网络仍通；原因——SR-IOV 下数据面可从合成路径切到 **VF 直通**（数据面绕开 VMBus 与 hypervisor，控制面仍在 VMBus）；对策——先判当前数据面走哪条路径（[[hyperv-vmbus]]）
- **没拿到配置文件就分析资源归属**：现象——找不到"为什么这个分区访问不到"的答案；原因——配置驱动的分离系统（XtratuM、LynxSecure、Jailhouse、Bao 等）把资源归属全放在配置里；对策——先取配置，再谈代码（[[xtratum]] / [[lynxsecure]]）
- **把"缺少集中管理代码/VM-exit 很少"当没有隔离**：现象——反汇编里找不到中央调度或重配置逻辑；原因——静态配置模型与多内核 sandbox 本来就不这么做；对策——按该系统的模型解释（[[lynxsecure]] / [[questv]]）
- **跨 sandbox 比较时间戳**：现象——同一次事件在两侧的时间对不上；原因——某些多内核设计**没有全局时钟**，各核用本地定时器与 TSC；对策——把时钟偏差算进去，别按单一时间线断言（[[questv]]）
- **在内核区域里期待驱动与 I/O 栈**：现象——某个映像块里应有尽有（驱动、I/O、应用 API），却被当作内核；原因——极端的静态分离设计把 **I/O 与应用支持全部导出到 guest**，内核只做资源分区/数据流控制/状态变更调解；对策——用这三项职责反查真正的内核边界（[[lynxsecure]]）
- **在运行期找"重配置"逻辑**：现象——找不到动态 MMU/资源重配置引擎；原因——静态配置模型下映射与归属都在启动期确定；对策——把追映射的工作放到启动阶段（[[lynxsecure]]）