跨系统运行模型与误判总表

用途：任何"现象看起来异常"的时刻，先过这张表。它的价值不在于介绍系统，而在于阻止把某个系统的正常机制判成 bug / hook / dead code / 恶意。

前置：本文件假设你已经知道"这是哪个系统"。认不出目标时先走 system-fingerprints（载体格式 → 家族 → 系统 → 易混淆对 → 负判据）。两者配合使用：先定身份，再查该身份允许哪些"正常异常"。

判定顺序（本文件的核心主张）：

观察异常现象
  → 识别目标的运行模型（哪个系统、哪个构建、哪个阶段）
  → 判断该模型允许哪些"正常异常现象"
  → cross-view / 配置核对 / 运行时验证
  → 最后才判定：损坏、恶意，或真的是 bug

一、十类高频误判（先怀疑，再排除）

观察到的现象	不要直接推断	必须先排除
函数 0 xref	dead code	linker set、generated registry、callback、IPC dispatch、RTE、init table、AST、exception table
地址变化	hook / 不同 binary	KASLR、KARL、relocation、PAC、GPA/HPA、local handle
同一个整数	同一个对象	CPtr、Zircon handle、endpoint、fid、grant ref、event port、capability name
driver 没有 syscall / IRP handler	没有 I/O	framework callback、user-space driver、miniport、resource manager、DDF、scheme
thread READY 却不运行	scheduler bug	partition window、budget、SC、safety class、上层 scheduler、调度器被禁用
文件存在但代码没运行	loader bug	activation state、AuxKC、Function Group、module load stage、按需发现
disk code ≠ runtime code	rootkit	livepatch、ftrace、jump labels、kernel collection、runtime relocation、init 段已释放
IPC 没有 syscall trace	没发生通信	shared-memory channel、local transport、co-located driver、VMBus、grant table
memory access fault	内存坏了	MPU zone、capability rights、cell/partition 归属、IOMMU、当前特权级
服务突然换 PID / endpoint	劫持	restart / live update / reincarnation / 按需加载

二、共同规律 A：本地句柄 ≠ 全局标识

跨进程、跨分区、跨域建图之前，必须先恢复 本地标识 → 命名空间/表 → 真实对象，再谈关系。

系统	本地标识	恢复方式
seL4	CPtr	各自的 CSpace 映射 → kernel object
Fuchsia/Zircon	handle 整数	进程 handle 表 → 对象 + rights
MINIX 3	endpoint / grant ID	label 解析、grant 表条目 + 序列号
Genode	capability 局部名	PD 局部命名 → session/对象
Plan 9	9P fid	连接 + walk 历史 + qid
Xen	grant ref / event port	grant 表条目；`shared_info` 位掩码（远端端口才稳定）
Bao	——	共享对象 identity 是配置里的 `shmem_id`，不是地址
ACRN / Jailhouse	——	共享区归属由配置/前缀（`dm:/` vs `hv:/`）决定

三、共同规律 B：ready 不是"有资格现在占用 CPU"的充分条件

分区/安全系统（ARINC 653、PikeOS、INTEGRITY、Deos、XtratuM、LynxSecure、Jailhouse、Bao、Quest-V）共用一条经验：

资源资格（budget/quota）
  → 分区/域资格（当前窗口、调度计划、CPU 归属、safety mode）
  → 本地调度器资格
  → 线程优先级

不能简化为"最高优先级 READY 者运行"。 分析时先对齐分区级时间线，再看线程级。

四、共同规律 C：没有内核入口 ≠ 没有 I/O

用户态驱动/服务形态各异，但结论相同——在 kernel 里找不到 dispatch 是常态：

resource manager（QNX）、DriverKit/System Extension（macOS）、driver host（Fuchsia）、DDF（HelenOS）、scheme（Redox）、user-space service + RS（MINIX 3）、user-space file server（Plan 9）。

五、共同规律 D：没有 CFG 边 / 没有 syscall ≠ 没发生

注册式：linker set（FreeBSD set_*）、iterable section + SYS_INIT（Zephyr）、generated RTE（AUTOSAR）、配置生成的 task/handler（TOPPERS、RTEMS）、autoconf（OpenBSD）、按需 autoload（NetBSD）
回调式：framework callback（Windows 各模型）、SDK callback（VxWorks io-pkt、nw_pthread_create）
异步控制流：AST（OpenVMS）、SRB（z/OS）、fault handler（seL4）
异常边：__ex_table（Linux exception fixup）
共享内存式：PV ring（Xen）、driver runtime local transport（Fuchsia）、grant（MINIX）、VMBus（Hyper-V）、VirtIO/共享页

六、共同规律 E：信任边界不能从指令形态推导

在 capability / 沙箱 / 多版本 / live-update 型驱动系统里（覆盖 seL4、Genode、Fuchsia、多内核系统、分区 hypervisor、用户态驱动 OS 等）：

不从 CPL、地址、直接调用或 MMIO 指令推导信任边界

先恢复 domain、capability、mapping、device ownership、version、lifecycle topology，再解释控制流。四条推论：

看起来像	实际可能是
直接 call	跨逻辑组件的调用（同地址空间 ≠ 同组件；同组件也可能跨隔离域）
直接 MMIO	被授权的设备映射（"能访问 MMIO" ≠ "有整机内核权限"）
同特权级	靠 MMU 隔离的独立域（Ring 0 → 全内核可寻址在这类系统上是 invalid assumption）
整数句柄	capability / 共享页偏移 / domain-local 标识（跨域比较无意义）

配套要求：内存取证要区分 VA / PA / backing frame / capability / owner domain / mapped domain；共享内存指针要带域语义（{domain, cap, mapping, offset, length, rights}），否则数据流分析会把合法跨域流错误合并。具体系统分支见 re-kernel/hic、re-kernel/sel4-kernel、re-kernel/zircon-kernel、re-kernel/genode。

七、共同规律 F：磁盘上的 ≠ 正在跑的

livepatch / ftrace / jump label（Linux）、AuxKC 与 Kernel Collection（macOS）、runtime relocation 与 __init 释放（Linux）、live update（MINIX 3）、动态模块替换（Nucleus、OSE）、按需发现（Haiku）。

动手比较前先对齐三份身份：磁盘版本 / 加载集合中的版本 / 当前真正在跑的版本。

七、跨系统异常处理树

看到"异常"
│
├─ 函数没有 caller
│   ├─ callback registration
│   ├─ linker set
│   ├─ generated RTE / config
│   ├─ IPC dispatch
│   ├─ AST / SRB
│   ├─ exception table（__ex_table）
│   └─ init / iterable section
│
├─ 地址不一致
│   ├─ KASLR / KARL
│   ├─ PE / ELF relocation
│   ├─ PAC
│   ├─ GPA / HPA
│   ├─ local handle namespace
│   └─ runtime KC / image
│
├─ driver 没有内核入口
│   ├─ user-space driver
│   ├─ resource manager
│   ├─ DriverKit
│   ├─ Fuchsia driver host
│   ├─ Redox scheme
│   ├─ HelenOS DDF
│   └─ MINIX service
│
├─ thread 不执行
│   ├─ partition window
│   ├─ budget / quota
│   ├─ SC donation
│   ├─ safety class
│   ├─ Hwi/Swi scheduler 被禁用
│   ├─ partition mode（未进 NORMAL）
│   └─ 上层 scheduler
│
├─ IPC 没有 syscall
│   ├─ shared-memory ring
│   ├─ polling
│   ├─ co-located transport
│   ├─ VMBus / GPADL
│   ├─ grant table
│   └─ hypervisor channel
│
├─ memory access fault
│   ├─ capability rights
│   ├─ MPU zone
│   ├─ task isolation
│   ├─ cell / partition assignment
│   ├─ IOMMU
│   └─ runtime privilege level
│
├─ binary 存在但没运行
│   ├─ AUTOSAR Function Group / Machine State
│   ├─ System Extension activation
│   ├─ boot / module stage
│   ├─ partition mode
│   └─ on-demand driver discovery
│
└─ runtime 与 disk 不同
    ├─ livepatch
    ├─ jump-label / ftrace
    ├─ AuxKC / kernel collection
    ├─ dynamic module relocation
    ├─ init code 已释放
    └─ live update / restart

八、使用方式

现象命中上表任一行 → 先按"必须先排除"逐项核对，不要跳到结论
需要某个系统的细节 → 按 rerouting A 表或 capability-index 反查对应技能与分支
核对手段统一是三样：cross-view（多视图交叉）、configuration（配置/清单/计划文件）、runtime verification（运行时状态而非磁盘内容）
只有在排除完该模型允许的正常机制之后，才写"损坏 / 恶意 / bug"的结论——并在报告里写明排除了哪些可能性、依据是什么

九、异常速查表（按现象直查）

现象	优先考虑
AUTOSAR binary 存在但 process 不存在	Function Group State / Execution Manifest
AUTOSAR service 暂时发现不到	服务发现允许空结果 / 可用性回调生命周期
AUTOSAR process 无 crash 却重启	平台健康监控 → 状态管理
AUTOSAR 更新后仍旧数据 / 数据消失	Persistency 更新策略（keep / overwrite / delete）
分离内核里找不到 runtime 配置器	静态配置 + 无动态系统修改
guest 直接操作真实 MMIO / IRQ	静态 direct assignment（I/O 被导出到 guest）
分区 RTOS 里高优先级 READY 不执行	时间窗 / 调度域资格
分区 RTOS 多出 CPU 时间	slack 回收
分区 RTOS 的 major frame 起点缓慢漂移	外部时钟同步类机制（需在具体型号文档确认）
认证 RTOS 里同一地址权限不同	per-task MPU/MMU 区域
认证 RTOS 里句柄不像指针	间接对象 ID + 交叉引用表
ISR 唤醒了 task 却不切换	嵌套 ISR / ISR 退出协议 / 调度器锁
task 被唤醒但没有资源	中止等待路径（唤醒 ≠ 获取成功）
线性地址下仍存在隔离	线性映射 + entitlement（不是每进程独立 VA）
module 无 reboot 被替换	动态 reload / restart / update
遇到 "partition" 一词	先分：空间隔离域 vs 固定块内存池
高优先级 task READY 不跑（TI SYS/BIOS）	禁用 Swi 调度会连带禁用 Task 调度
Swi 的栈看起来像 ISR 栈	Swi 本就运行在系统/ISR 栈上
ISR 里调用的 API 效果延后	ISR FIFO 延迟队列
同一对象不同线程权限不同	Safety Class / MPU 保护域
plan switch 延迟生效	普通切换要等当前计划/MAF 结束
plan 瞬间切换	健康监控切维护计划
采样端口"丢中间值"	latest-value 覆盖语义
Service VM 里设备消失又回来	设备所有权移交给 post-launched VM
共享内存设备各自正常却互不相通	两种实现（dm-land / hv-land）不互通
小整数被当地址（Hyper-V）	GPADL 是句柄
删除 GPADL 时卡住	server 仍映射，阻塞直到解除
packet 回调返回但资源未释放	完成调用可延后
取外部数据返回"待决"	需要分页；稍后可能在不同 IRQL 再次回调
网络 VMBus 流量突然消失但网络正常	SR-IOV VF 直通路径切换
ring 更新却没有通知（Xen）	通知抑制（阈值未越过）
event unmask 行为奇怪	pending / masked / FIFO 语义
迁移后 domid / 端口变化	协议需要重新协商
同一 build 里事件记账布局不同	两套 ABI，解析器不能混用
0 xref 的 init 函数（Unikraft）	多级初始化表（构造/早期/平台/库/rootfs/系统/晚期）
同名 syscall 出现多个符号	libc 风格 / raw-error 风格 / shim 三层包装
缺 syscall 返回 ENOSYS 但应用照跑	可选 syscall 桩
同一源码的 I/O 完全不同（MirageOS）	构建目标决定 backend
全部"线程"一起卡死	协作式线程不让出（饿死事件循环）
后台任务异常没有直接杀系统	异步异常处理策略

十、版本与代际提示

按目标做版本指纹再套条目：规范与手册存在代际差异——例如某平台规范已推进到新版本而多数公开细节来自上一版；某 hypervisor 最完整的公开手册属于某一代（如 XM-4），不要无条件套到其他代际
同一系统的不同产品线（安全认证版与基础版）也不是同一份二进制/内核，机制可选项不同

12 KiB Raw Blame History Unescape Escape