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

• 轴 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 标志）：

   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 内调试）：

   # 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]]）