Native CPU 特性分派如何避免在旧设备执行非法指令

ABI 是二进制契约，不是处理器能力清单

Android 的 ABI 名称首先回答二进制如何调用：参数放在哪些寄存器、栈怎样对齐、目标文件使用什么机器类型、共享库位于哪个打包目录。它能帮助系统选择可装载的 so，却没有承诺某台设备实现了应用想用的每一项可选指令。把 arm64-v8a 直接翻译为某个密码、校验或向量扩展可用，会把部署类别误当成运行时事实。

同一 ABI 下可能存在不同代际的 CPU、不同内核暴露方式和不同虚拟化环境。编译器也可能因为全局参数、内联或链接期优化，在看似普通的初始化函数中生成更高指令集代码。此时崩溃发生在分派判断之前，业务日志还没有建立，表面现象只是 SIGILL 或极早期退出，排查很容易误指向加固、加载器或设备厂商。

可维护的做法是建立四层清单：ABI 决定产物族，编译目标决定对象文件允许出现的指令，运行时探测决定当前进程看见的能力，分派策略决定调用哪个实现。四层中任何一层缺失都不能放行优化分支。这个约束同样适用于自研代码、预编译第三方库、静态归档和被链接器抽取的对象文件。

先隔离基线对象文件，再谈优化实现

基线实现要按该 ABI 约定的最低可部署指令集编译，并放在独立翻译单元中。分派器、能力读取、错误处理和基线算法也必须属于基线编译域，因为它们是任何设备都会经过的路径。若工程只给某个函数添加属性，却仍让包含它的文件接受全局架构参数，内联、常量折叠或公共头文件中的模板代码仍可能把优化指令带到基线路径。

优化实现应按能力逐类拆分，而不是建立一个包含所有高级指令的巨大对象文件。例如密码扩展和向量扩展应有各自的能力条件、实现标识和回退入口；多个条件共同成立的组合实现还要声明合取关系。这样审计人员才能从构建图追到具体对象，确认一项能力被禁用时没有顺带调用另一个更强的实现。

CMake 目标属性、源文件属性和导入库元数据需要分别审查。自编译源可以看到参数，预编译 so 或静态库的内部指令却不能从当前 CMakeLists 推断。对外部二进制应保存供应方版本、目标 ABI、声明的最低能力和静态检查结果；若这些信息不可得，应把它视为独立兼容风险，而不是默认纳入基线。

运行时探测要输出证据，不只返回布尔值

能力探测的输入应来自平台认可的运行时机制，并转换成内部稳定字段。原始位图、系统属性或库函数返回值不宜散落在业务代码中，否则不同模块会对未知值作出相反解释。检测层应区分 present、absent、unknown 和 error；只有明确 present 才允许进入对应优化路径，其余状态都落到基线。

分派决定至少要包含 ABI、候选实现、所需能力集合、检测结果、最终实现、回退原因和 policyVersion。记录这些字段不是为了收集设备隐私，而是让一次 SIGILL、结果差异或性能退化能回到当时的选择依据。设备型号等环境信息应按最小化原则进入测试回执，不应把完整硬件指纹写入普通业务日志。

初始化期间可以计算一次只读分派表，但缓存必须绑定进程和策略版本。热更新配置、动态模块或重新装载库若改变实现集合，就不能继续复用旧函数指针。更稳妥的接口返回带实现标识的不可变对象，调用点只持有该对象；卸载、重建或策略切换时先阻止新调用，再等待旧调用退出。

回退实现必须真的可装载、可调用、语义等价

写下 fallback 名称不等于存在回退。基线符号要随目标 ABI 进入最终产物，依赖的 Native API 不得高于应用允许的最低平台边界，初始化也不能先调用优化库。若基线函数依赖一个只在新系统存在的符号，旧设备会在装载阶段失败，根本没有机会执行 CPU 能力判断。

稳定 API 与 CPU 特性是两条独立轴。前者回答某个系统版本能否链接或动态解析接口，后者回答处理器能否执行某类机器指令。一个实现可能满足 CPU 条件却引用了高版本 API，也可能系统 API 可用但 CPU 能力不足。分派表应分别声明 minApi 和 requiredFeatures，门禁逐项验证，不能把任一条件折叠到 ABI 字段。

语义等价需要针对输入、输出、错误码、溢出规则、并发约束和边界数据比较。优化路径与基线路径若使用不同舍入、不同字节序或不同未定义行为，正常样例可能一致，极端输入却分叉。发布证据应保存同一候选产物上两条路径的差分结果；没有这样的项目回执时，只能说明设计满足静态约束，不能声称兼容已经通过。

并发、缓存和库生命周期会放大分派错误

高频算法通常把选定实现缓存为函数指针，以避免每次读取能力。性能动机合理，但发布顺序必须明确：构造完整决策对象，验证函数地址属于仍然装载的模块，再以原子方式公开。若先公开指针、后补充上下文，其他线程可能在回退字段未初始化时调用错误实现，偶发问题会被误认为 CPU 兼容差异。

分派表刷新也需要代际控制。策略版本、动态功能模块或 Native 库版本变化时，新调用读取新 generation，旧调用保留对旧实现的安全引用直至退出。不能在仍有调用执行时卸载包含旧函数的库，也不能仅替换实现名称而保留旧地址。对不需要动态卸载的 App，保持库常驻通常比追求卸载更容易证明正确。

信号处理器不是修复非法指令分派的常规回退机制。尝试捕获 SIGILL 后跳回基线会面对指令边界、寄存器状态、异步信号安全和并发线程等复杂条件，且可能掩盖真实构建错误。正确路径是在执行前完成能力门禁；崩溃信息用于定位遗漏的分支和对象文件，不用于把一次危险试探包装成能力检测。

真实设备矩阵要覆盖能力边界，不只覆盖热门型号

测试矩阵应从分派表反推，而不是从市场份额列表随意抽样。每个优化实现至少需要一类明确具备目标能力的环境验证被选择，一类缺少目标能力的环境验证回退，一类能力组合处在边界的环境验证不会误入组合优化。每条回执绑定候选包哈希、ABI、系统版本、设备标识、探测值、最终实现和结果摘要。

设备农场能扩大型号和系统覆盖，但目录会变化，队列容量和设备稳定性也不是固定承诺。测试计划应在执行时保存实际分配的型号与系统，不使用计划中的设备名称代替回执。云端设备没有覆盖的旧 CPU、定制系统或业务关键硬件，仍需自有真机补齐，并使用相同的采集格式合并证据。

instrumented test 适合触发应用上下文中的 Native 调用、生命周期切换和结果断言。它不能自动证明机器码只包含基线指令，因此还要结合对象级静态检查和启动阶段回归。单台新设备通过优化路径，只证明该候选包在该环境的观察结果；没有覆盖的 ABI、系统和能力组合继续标记为未验证。

用机器可读清单阻止没有回退和回执的优化分支

人工评审容易漏掉新增实现的配套项。可以把分派规则写成公开安全的 JSON 清单，每条记录只包含实现标识、ABI、能力条件、基线回退和测试回执标识，不包含客户数据、设备序列号或内部地址。门禁脚本读取清单，拒绝缺少能力条件、回退不存在、基线自引用或没有对应回执的优化项。

下面的 Python 校验器直接读取命令行指定的清单文件，先检查顶层结构和标识唯一性，再验证每条优化记录。失败路径由输入内容触发并返回非零状态，适合放进构建门禁；它不探测本机 CPU，也不执行任何优化函数，因此不会把构建机能力误当成目标设备能力，更不会形成可运行的攻击链。

这类清单门禁验证的是证据完整性，不是运行正确性。测试回执标识必须由另一条受控流程生成，并绑定真实候选产物与设备执行结果；如果只是手工填入一个字符串，结构门禁仍可能通过。发布审查应继续核对回执文件存在、哈希匹配、分支结果符合预期，并抽查静态对象没有越界指令。

import json
import sys
from pathlib import Path

def fail(message):
    print(f"dispatch gate failed: {message}", file=sys.stderr)
    raise SystemExit(2)

def load_manifest(path_text):
    path = Path(path_text)
    if not path.is_file():
        print("dispatch gate failed: manifest file does not exist", file=sys.stderr)
        raise SystemExit(2)
    try:
        return json.loads(path.read_text(encoding="utf-8"))
    except (OSError, json.JSONDecodeError) as exc:
        fail(f"cannot read manifest: {exc}")

def validate(data):
    rules = data.get("rules")
    receipts = set(data.get("receipts", []))
    if not isinstance(rules, list) or not rules:
        fail("rules must be a non-empty list")
    identifiers = {item.get("id") for item in rules}
    if None in identifiers or len(identifiers) != len(rules):
        fail("rule ids must be present and unique")
    baselines = {item.get("id") for item in rules if item.get("kind") == "baseline"}
    if not baselines:
        fail("at least one baseline rule is required")
    for item in rules:
        rule_id = item.get("id")
        if not item.get("abi"):
            fail(f"{rule_id} has no ABI")
        if item.get("kind") == "baseline":
            if item.get("requiredFeatures"):
                fail(f"{rule_id} baseline requires optional features")
            continue
        features = item.get("requiredFeatures")
        fallback = item.get("fallback")
        receipt = item.get("testReceipt")
        if not isinstance(features, list) or not features:
            fail(f"{rule_id} has no capability condition")
        if fallback not in baselines or fallback == rule_id:
            fail(f"{rule_id} has no valid baseline fallback")
        if receipt not in receipts:
            fail(f"{rule_id} has no matching device receipt")
    print(f"dispatch gate passed: {len(rules)} rules")

if __name__ == "__main__":
    if len(sys.argv) != 2:
        fail("usage: validate_dispatch.py manifest.json")
    validate(load_manifest(sys.argv[1]))

发布门禁要绑定最终机器码和同一候选产物

最终门禁应从产物而不是源码推断。先列出 APK 或 AAB 实际包含的 ABI 和 Native 库，再把每个库的构建来源映射到基线或优化对象，检查分派器及启动路径保持最低指令集。对于链接期优化、内联汇编和预编译归档，源码参数不足以说明最终结果，应保存针对最终 so 的反汇编或指令分类摘要。

加固、符号裁剪、重链接和依赖升级可能改变对象布局、初始化顺序或编译选项。只要候选产物哈希变化，旧设备回执就不能直接作为新产物的完成证明。团队可以复用测试设计、设备池和采集脚本，但需要让新的执行结果重新绑定产物哈希；失败时保留分派决策、退出原因和对应符号信息。

评审完成后，站内的 Native 库装载生命周期文章可帮助继续检查函数指针与卸载边界；准备评估商业 App 的 Native 加固范围时，可通过页面行动按钮进入御盾中央平台提交候选包、目标 ABI 和设备矩阵需求。提交动作只启动评估流程，具体兼容结论仍以同一候选产物的实际回执为准。

• 确认每个 ABI 都有最低指令集基线对象和可解析入口。
• 确认优化编译参数只作用于对应翻译单元，没有泄漏到分派器。
• 确认每项能力条件来自明确运行时探测，unknown 一律回退。
• 确认 minApi、CPU 能力、实现语义和生命周期分别通过门禁。
• 确认设备回执绑定候选哈希、型号、系统、探测值与最终实现。
• 确认加固或重链接后重新检查最终机器码并重跑关键矩阵。