前两篇文章覆盖了威胁模型和 seccomp 沙箱。这篇讲更进一步：一个基于 WebAssembly 的执行环境，安全属性来自编译目标本身，而不是 OS 级别的过滤器。

为什么 WASM 的安全模型不同

用 seccomp，我们写了一个 62 条目的阻断列表。当新的危险 syscall 出现（比如 io_uring），就往列表里加。这个安全模型是"阻断坏的东西"。

上周我们发布了 sandbox_exec——一个用 seccomp-bpf 隔离学生代码的 224 行 C 程序。当时的诚实答案是："WASM 的安全模型更干净，但 Python 生态还没准备好。"

这周我们量化了"还没准备好"到底意味着多少毫秒。答案比预想的更有意思。

测试环境

• 运行时：Wasmtime v42.0.1
• 平台：macOS arm64
• 方法：每个场景 50 次运行，5 次预热，取均值
• 对比基准：sandbox_exec 包装 Python 3.x

上周我们上线了 sandbox_exec——一个用 224 行 C 代码编写的程序，利用 seccomp-bpf 在 AWS Lambda 里隔离学生代码。当时的诚实回答是：「WASM 更干净，但 Python 生态系统还没准备好。」

这周我们精确地测量了「Python 生态系统还没准备好」在毫秒层面的代价。答案比预期的更加微妙。

测试环境

• 运行时：Wasmtime v42.0.1
• 平台：macOS arm64
• 方法：每个场景 50 次运行，5 次预热，取平均值
• 对比基准：包裹 Python 3.x 的 sandbox_exec

今天我的 MSc 毕业项目正式启动。需求听起来简单：在 AWS Lambda 里安全地运行学生提交的代码。约束让这件事变得有趣。

问题

Lambda Feedback 是 Imperial College 用于学生在线提交和评测代码的平台，底层使用 serverless functions 执行代码。

为了性能，Lambda 会复用容器。五分钟前处理过 A 同学提交的实例，下一个请求可能是 B 同学的。同一个文件系统，同一个进程内存，同一个 /tmp。

今天我的 MSc 项目正式启动。前提听起来很简单：在 AWS Lambda 里安全地运行学生代码。约束条件让它变得有趣。

问题

Lambda Feedback 是一个平台，学生在这里提交代码并实时得到评测。后端使用 Serverless 函数——AWS Lambda 启动一个容器，运行代码，返回结果。

为了性能，Lambda 会复用容器。五分钟前处理了学生 A 提交的函数，可能会处理学生 B 的下一个请求。同一个文件系统，同一个进程内存，同一个 /tmp。