1. 从一个真实需求说起为什么要在 ESP32 上谈“沙箱”很多人第一次听到“ESP32 沙箱”这个词反应都是一个几十块钱的 MCU跑的是裸机或者 FreeRTOS连 MMU 都没有谈什么沙箱这个反应其实是对的——ESP32 上确实没有 Linux 那种进程隔离、地址空间隔离、系统调用过滤的沙箱机制。但问题在于没有进程沙箱不等于不能做权限约束。我接触这个问题的起点很具体手上有几个基于 ESP32 的小项目需要让第三方或者非核心团队写一些“小应用”跑在设备上比如某个传感器采集逻辑、某个屏幕显示逻辑、某个简单的控制策略。这些应用不能碰 Wi-Fi 配置、不能碰 NVS 里的密钥、不能随便调用 GPIO、更不能把整个固件搞崩。但 ESP32 的资源摆在那里几百 KB 的 RAM没有 MMU没有独立的用户态所有代码都在同一个地址空间里跑。这种情况下怎么限制一个“小应用”能做什么这个问题的本质不是“怎么在 ESP32 上实现 Linux 沙箱”而是在资源极度受限、没有硬件隔离的 MCU 上如何通过软件架构和运行时约束把一段不可信或者半可信代码的能力边界划清楚。它涉及几个层面的东西代码怎么加载、能调用哪些接口、内存怎么管、崩溃了怎么办、权限怎么声明和检查。下面我按自己实际踩过的路子把这件事拆开讲。1.1 先明确“小应用”到底指什么在 ESP32 语境下“小应用”通常不是指一个完整的独立固件而是指一段可以被主固件动态加载或者静态集成、但逻辑上独立的代码单元。它可能是一段用 C 写的业务逻辑函数编译成静态库链接进主固件一段用 C 写的代码编译成位置无关的二进制运行时加载到指定内存区域一段用 WebAssembly 编译出来的字节码由主固件里的 WASM 运行时解释执行一段用脚本语言如 MicroPython、Lua写的脚本由主固件里的解释器执行。这四种形态的隔离能力完全不同。静态链接的 C 代码基本没有隔离它和主固件共享一切位置无关二进制稍微好一点至少加载地址可控WASM 和脚本语言则天然带一层运行时边界因为它们不直接操作硬件所有能力都得通过宿主暴露的接口。所以谈“限制小应用能做什么”第一步是选形态。形态选错了后面做再多权限检查都是补丁摞补丁。1.2 为什么 WebAssembly 会被反复提起热搜词里出现了 WebAssembly这不是偶然。WASM 的设计目标之一就是在不可信代码和宿主之间建立一层可控的执行边界。它的内存模型是线性的、独立的代码不能直接访问宿主内存它只能调用宿主显式导入的函数。这两点放在 ESP32 上就很有价值小应用跑在 WASM 运行时里它想点个灯不能直接写 GPIO 寄存器只能调用宿主提供的gpio_set_level导入函数它想读 NVS也只能调用宿主提供的接口。宿主在提供这些导入函数的时候就可以做权限检查。但 WASM 在 ESP32 上不是没有代价。一个 WASM 运行时本身要占几十到上百 KB 的 Flash 和 RAM解释执行或者 JIT 的性能也比原生 C 差不少。对于一颗 240MHz 的 Xtensa 核心来说这个开销必须算清楚。我后面会专门讲选型和资源账。2. 没有 MMU 的情况下隔离到底靠什么2.1 硬件隔离的缺失意味着什么Linux 沙箱的底气来自硬件每个进程有独立的虚拟地址空间MMU 负责把虚拟地址翻译成物理地址内核通过页表把不同进程的物理内存隔开。一个进程想访问另一个进程的内存硬件直接触发异常。ESP32 没有 MMU只有 MPUMemory Protection Unit在某些型号上可用而且 ESP32 经典款和 ESP32-S3 的情况还不一样。没有 MMU 意味着所有代码共享同一个物理地址空间一段恶意代码理论上可以读写任何它知道地址的内存。所以 ESP32 上的“沙箱”必须换一个思路不追求内存的硬隔离而是追求能力的软约束。也就是说我不指望阻止小应用去读某块内存而是让小应用根本没有机会执行任意内存访问——因为它跑在一个受控的运行时里它写的每一行代码都只能通过运行时提供的接口来产生副作用。2.2 能力约束的三个层次我把实际能做的约束分成三层从弱到强第一层是编译期约束。小应用在编译时就被限制只能链接特定的头文件和库不能直接包含driver/gpio.h、nvs.h这些底层头文件。它只能包含宿主提供的 API 头文件。这一层靠构建系统来保证比如用独立的 CMake 目标、独立的 include 路径、独立的链接脚本。优点是零运行时开销缺点是只能约束“正规写法”防不住故意绕过。第二层是运行时接口约束。小应用运行在一个运行时里运行时只暴露有限的导入函数。小应用想产生任何副作用都必须经过这些函数。宿主在这些函数里做权限检查、参数校验、频率限制。这一层是核心WASM 和脚本语言天然支持原生 C 代码则需要自己搭一套函数表。第三层是资源配额约束。给小应用分配固定的内存池、固定的栈、固定的执行时间片、固定的调用次数。超出配额就终止它。这一层防的是“小应用虽然没干坏事但把资源吃光了导致主系统崩溃”。三层叠起来才能在没有 MMU 的情况下做到“小应用能做什么”是可控的、可预期的。2.3 一个常见的误区把权限检查写在业务代码里我见过一些实现权限检查是散落在各个业务函数里的比如if (app_has_permission(GPIO)) { gpio_set_level(...) }。这种写法的问题是只要有一个地方漏了检查整个约束就破了。而且随着接口变多检查逻辑会越来越难维护。更稳的做法是把权限检查收敛到宿主导入函数的入口。小应用永远拿不到裸的gpio_set_level它拿到的是宿主包装过的host_gpio_set_level这个包装函数第一件事就是查当前小应用的权限表。这样权限检查只有一个地方要做漏检的概率大大降低。3. 用 WebAssembly 做运行时边界的实操拆解3.1 运行时选型WAMR、wasm3 还是别的在 ESP32 上跑 WASM目前社区里比较常见的选择是 WAMRWebAssembly Micro Runtime和 wasm3。两者定位不太一样运行时解释/JIT典型内存占用适合场景wasm3解释执行约 30-60KB资源极紧、逻辑简单WAMR 解释模式解释执行约 80-150KB需要较完整 WASM 特性WAMR AOT预编译更大性能敏感、Flash 充足我自己的选择逻辑是如果小应用逻辑简单、调用频率低wasm3 够用省下来的 RAM 可以留给业务如果小应用需要较完整的 WASM 特性比如浮点、较复杂的控制流或者未来可能换 AOTWAMR 更稳。ESP32 经典款 RAM 紧张我一般优先 wasm3ESP32-S3 带 PSRAM 的话WAMR 也可以考虑。注意WASM 运行时本身也是代码它自己如果有漏洞小应用可能通过构造恶意字节码来逃逸。所以运行时要选维护活跃、有安全审计的版本不要用几年没更新的 fork。3.2 宿主导入函数的设计WASM 小应用能做什么完全取决于宿主导入了哪些函数。设计导入函数时我遵循几个原则最小暴露只导入小应用真正需要的函数不要图省事把整个驱动层都导进去。语义清晰导入函数应该是业务语义的比如set_led_state而不是write_gpio_register。前者宿主可以检查“这个应用有没有点灯的权限”后者基本等于把硬件交出去了。参数校验所有参数都要校验范围。比如set_led_state(index, state)index 必须在合法范围内state 只能是 0 或 1。频率限制对可能被滥用的接口做调用频率限制比如每秒最多调用 N 次防止小应用死循环刷接口拖垮系统。一个典型的导入函数表大概长这样static const wasm_import_t imports[] { { env, log_info, host_log_info, NULL }, { env, set_led, host_set_led, NULL }, { env, read_temp, host_read_temp, NULL }, { env, get_time_ms,host_get_time_ms,NULL }, };每个host_*函数内部第一件事就是取当前小应用的上下文查权限位图然后做参数校验和频率检查。3.3 权限声明与检查的实现权限怎么声明我一般用一个位图或者一个结构体数组。位图简单省空间适合权限项固定的场景结构体数组灵活适合权限项可能扩展的场景。以位图为例定义一组权限位#define PERM_LED (1 0) #define PERM_TEMP_READ (1 1) #define PERM_LOG (1 2) #define PERM_NVS_READ (1 3)每个小应用在加载时带一个权限掩码比如PERM_LED | PERM_LOG。宿主导入函数检查时static bool check_perm(uint32_t perm) { app_ctx_t *ctx get_current_app(); return (ctx-perms perm) ! 0; }host_set_led里就是int host_set_led(int index, int state) { if (!check_perm(PERM_LED)) return -EPERM; if (index 0 || index LED_COUNT) return -EINVAL; if (state ! 0 state ! 1) return -EINVAL; if (!rate_limit_ok()) return -EBUSY; led_set(index, state); return 0; }这套东西不复杂但关键是所有导入函数都要走这个模式不能有例外。3.4 内存与栈的配额WASM 实例有自己的线性内存宿主在创建实例时指定大小。这个大小就是小应用能用的堆上限。栈的话WASM 运行时一般有自己的栈管理宿主可以配置栈大小。我一般给小应用的线性内存 16KB 到 64KB栈 4KB 到 8KB具体看应用复杂度。执行时间片这块WASM 运行时通常支持指令计数或者超时中断。wasm3 可以通过在导入函数里检查时间来实现粗粒度的超时WAMR 有更细的机制。我的做法是在宿主的主循环里给小应用一个时间预算比如单次调用最多跑 50ms超了就终止这个实例并记录日志。4. 如果不用 WASM原生 C 小应用怎么约束4.1 静态链接形态下的约束有些场景下WASM 的开销不可接受小应用必须是原生 C。这时候隔离能力会弱很多但也不是完全没办法。静态链接形态下小应用和主固件在同一个地址空间理论上它能调用任何它链接到的函数。约束主要靠构建系统给小应用独立的 CMake 目标只允许它 include 宿主提供的 API 头文件目录小应用的源文件里禁止直接 include 底层驱动头文件这个可以用脚本做静态检查链接时只把宿主 API 库链接给小应用底层驱动库不暴露给小应用目标。这套东西防的是“无意越界”防不住“故意越界”。如果小应用来源完全不可信静态链接形态不适合。4.2 函数表形态的约束比静态链接好一点的做法是小应用不直接链接宿主函数而是通过一个函数表来调用。宿主在初始化时把允许小应用调用的函数指针填进一个结构体小应用只能通过这个结构体来产生副作用。typedef struct { int (*set_led)(int index, int state); int (*read_temp)(float *out); void (*log)(const char *msg); } app_api_t;小应用的入口函数接收这个结构体指针void app_main(const app_api_t *api) { api-set_led(0, 1); api-log(hello); }宿主在填充函数表时可以根据权限决定填哪些、不填哪些。没填的函数指针是 NULL小应用调用就会崩——但至少它崩的是自己宿主可以在调用小应用入口时加保护。这种形态下小应用仍然可以通过其他方式拿到宿主地址比如扫描内存但门槛比直接链接高了不少。对于半可信的小应用这个方案在资源开销和隔离强度之间是个不错的平衡。4.3 崩溃隔离与恢复不管哪种形态小应用崩溃不能拖垮主系统。ESP32 上可以用几种手段如果小应用跑在独立任务里任务崩溃可以用看门狗或者任务级异常处理来捕获然后重启这个任务如果小应用是同步调用的宿主可以在调用前后做栈保护检查、堆完整性检查对于 WASM 形态运行时本身会捕获小应用的异常宿主只需要处理运行时返回的错误码。我一般会给小应用单独开一个任务任务里跑一个循环从队列取调用请求执行返回结果。任务崩溃了宿主检测到之后重新创建任务并把这个小应用标记为“异常”必要时降级或者禁用。5. 常见问题与排查实录5.1 小应用加载后系统重启这是最常见的问题。原因通常有几类线性内存给太小小应用一跑就越界运行时没处理好就崩了栈给太小递归或者深调用把栈打穿导入函数里有 bug比如空指针解引用小应用字节码本身有问题运行时校验没拦住。排查顺序先看串口日志里崩溃前的最后一条信息定位是加载阶段还是执行阶段然后逐步放大内存和栈看是否还崩再用最小化的测试小应用只调用一个 log验证运行时本身是否正常。5.2 权限检查没生效有时候明明配了权限小应用还是能调用某个接口。常见原因导入函数表里某个函数忘了加检查权限掩码在加载时被覆盖或者没正确传递有多个路径可以到达同一个底层函数只堵了一条。我的做法是给每个导入函数写单元测试用一个没有权限的小应用去调用确认返回-EPERM。这个测试要覆盖所有导入函数不能漏。5.3 性能不达预期WASM 解释执行的性能大概是原生 C 的十分之一到五分之一具体看运行时和代码特征。如果小应用里有密集计算解释执行会明显拖慢。这时候可以考虑把密集计算移到宿主侧小应用只做逻辑编排换 AOT 模式如果 Flash 和 RAM 允许降低小应用调用频率把批量处理放到宿主。5.4 常见问题速查表现象可能原因排查方向加载即崩内存/栈不足、字节码非法放大配额、校验字节码调用返回 -EPERM权限未配置或检查逻辑错查权限掩码、查导入函数系统变慢解释执行开销、死循环看时间片、看调用频率小应用崩溃影响主系统未做任务隔离独立任务、异常捕获内存逐渐减少小应用泄漏、宿主未释放查实例销毁、查堆监控6. 一些实操心得第一不要追求“绝对安全”。ESP32 上没有 MMU任何软件层面的隔离都有被绕过的可能。目标应该是“让越界的成本和难度足够高让无意越界基本不可能让故意越界需要相当的专业能力”。对于大多数产品场景这个强度就够了。第二权限设计要从业务出发不要从硬件出发。不要问“这个应用能不能访问 GPIO”要问“这个应用需不需要点灯”。前者太底层后者才是业务语义。业务语义的权限更容易检查也更容易向非技术方解释。第三小应用的入口要简单。我一般只给小应用一个入口函数参数是 API 结构体指针返回值是错误码。小应用内部怎么组织是它自己的事但和宿主的交互面越小越好。第四日志要能区分来源。小应用打的日志要带上应用标识不然出了问题根本分不清是宿主还是小应用干的。这个在调试阶段特别有用。第五配额要留余量。给小应用的内存、栈、时间片不要卡着理论值给要留 30% 到 50% 的余量。MCU 上的内存碎片、运行时开销、中断抢占都会吃掉额外资源卡太紧容易出玄学问题。第六版本要能回滚。小应用更新后如果出问题要能快速回滚到上一个版本。这个在 OTA 场景下尤其重要NVS 里存两份启动时选可用的那份。这套东西我在几个项目里跑过从最简单的函数表形态到 WASM 形态都试过。选哪种最终还是看小应用的可信程度、资源预算和团队的技术栈。没有银弹只有权衡。