W 加 X 与 JIT 可写内存 ACL

【踩坑实录】W 加 X 与 JIT 可写内存 ACL

▍现象
虚拟机工程把客户机系统跑起来后，一切正常；换成带即时编译负载的场景（脚本引擎、浏览器内核的 JIT），进程被系统处决——日志显示可执行内存违规。代码里明明申请了内存并跳转执行，为什么被杀。

▍定位过程
第一步怀疑申请姿势：换了多种内存申请接口，全部同样命运。第二步做探针：写一个最小化的代码生成执行用例，在应用上下文里跑——探针报告不可执行。团队一度得出结论：这个环境里 JIT 不可用，浏览器引擎方案要放弃。

第三步翻案：用真实引擎直接跑（不经探针），JIT 正常工作。探针阴性是假象——受控探针上下文里，可执行内存的策略判定与真实工作负载不同，探针在特定上下文可能被特殊处理给假阴性。同类虚拟机工程也实测过：运行时可执行类判定，探针结论不可信，必须真引擎直跑实证。

▍根因
可写可执行内存（W 加 X）受系统安全策略管：需要权限声明（受限 ACL，工程在打包阶段申请了 JIT 权限并通过）。策略本身允许 JIT 存在，但边界行为（哪些分配形态放行）在上下文间有差异，探针的测试形态恰好落在被拒的形态里。

▍对策
三件套落地：权限正道申请（打包期声明加 ACL 材料说明用途——虚拟机工程的 JIT 受限 ACL 是自动申请通道下来的）；验证方法纠正（能力判定一律真实工作负载直跑，探针结论只作参考）；降级链兜底（真不可用的环境：解释执行与 AOT 预编译两档降级）。

▍方法论沉淀
两条：探针阴性不等于能力不可用——受控上下文的判定会骗人；工程权限要走正道申请，别用伪装形态绕（绕过去的姿势正是探针翻车的原因）。

完整过程在虚拟机工程适配全记录里有逐步记录，欢迎到 apps 板块对照阅读。