Spin项目在macOS上签名后崩溃问题的技术分析

背景介绍

Spin是一个由Fermyon开发的轻量级WebAssembly应用框架，它允许开发者快速构建和部署基于WebAssembly的应用程序。近期在macOS平台上发现了一个与代码签名相关的严重问题：当Spin的可执行文件被签名后，spin up命令会在客户端连接时崩溃。

问题现象

当Spin二进制文件被macOS的代码签名工具签名后，执行spin up命令时会出现以下异常情况：

1. 命令最初能够正常启动
2. 但当客户端尝试连接到应用时（如访问localhost:3000）
3. 进程会立即崩溃，并产生EXC_BAD_ACCESS错误
4. 错误类型显示为"SIGKILL (Code Signature Invalid)"

根本原因分析

经过深入调查，发现问题与macOS的"强化运行时"(Hardened Runtime)安全机制有关：

1. Spin在运行时会重新执行自身作为触发器执行框架的一部分
2. Wasmtime运行时需要执行未签名的代码（WebAssembly模块）
3. 当启用强化运行时后，系统会阻止这种未签名代码的执行
4. 这导致了当Wasmtime尝试执行WebAssembly模块时，系统强制终止了进程

解决方案

通过实验验证，确定了以下几种可行的解决方案：

1. 不启用强化运行时：最简单的解决方案是在签名时不启用强化运行时，但这会影响应用的安全性评级和分发能力

2. 添加特定权限：更优的解决方案是保持强化运行时，但添加com.apple.security.cs.allow-unsigned-executable-memory权限，明确允许执行未签名的可执行内存

3. 使用JIT权限：尝试使用com.apple.security.cs.allow-jit权限，但发现Spin/Wasmtime并不使用标准的JIT编译机制，因此此方案无效

技术细节

macOS的强化运行时是一组安全功能，旨在防止代码注入、动态库劫持等攻击。当启用后，它会严格限制以下行为：

• 动态加载未签名代码
• 修改可执行内存页
• 某些系统调用

Wasmtime作为WebAssembly运行时，其工作方式类似于"即时AOT编译"：

1. 在加载WebAssembly模块时进行编译
2. 生成原生机器代码
3. 直接执行这些代码

这种模式需要动态创建和执行原生代码，因此与强化运行时的限制产生了冲突。

实施建议

对于需要在macOS上分发Spin应用的开发者，建议：

1. 如果必须签名应用，确保包含com.apple.security.cs.allow-unsigned-executable-memory权限

2. 在签名命令中添加相应参数，例如：

   codesign --options runtime --entitlements spin.entitlements -s "Developer ID" spin
   

   其中spin.entitlements文件包含所需权限

3. 考虑在应用包中提供签名和未签名两个版本的二进制文件，根据需要使用

总结

这个问题展示了现代安全机制与动态代码执行需求之间的典型冲突。通过理解macOS的强化运行时机制和Spin/Wasmtime的工作原理，我们找到了既保持安全性又满足功能需求的平衡方案。这也提醒开发者在跨平台开发时需要考虑不同操作系统的安全模型差异。