从一次依赖安装看 Agent 的隔离边界

pip install 可能在业务脚本运行前就执行依赖包的构建代码。Agent 原本只想读取 /input/orders.csv、复现一个计算错误，安装步骤却已经获得了读取文件、创建进程和发起网络请求的机会。这个依赖安装场景要求隔离从准备环境时就生效。锁定依赖版本能够固定选择结果，无法使恶意构建脚本变得可信。

假设执行平台提供一个接口：提交命令、输入目录和权限，返回退出状态、日志及产物。接口内部可以使用普通容器、gVisor 或虚拟机，调用方看到的参数未必有变化。区别藏在命令执行之后：open 由谁处理，安装器能看见哪些文件，取消请求怎样终止工作负载，/output/report.csv 又在什么条件下交给可信服务读取。

这个任务允许客户提交原生二进制，仓库、依赖和输出都应视为不可信。需要保护的对象包括宿主、其他客户的数据、平台凭证与资源。攻击者也可能始终留在分配的环境里，读取主动挂载的源码，使用环境变量中的令牌，持续输出日志，或把数据发给一个允许连接的服务。内核隔离无法撤回执行接口已经授予的权限。

文件读取进入哪个内核

Python 读取 CSV，需要打开文件、取得文件描述符，再读取字节。系统调用，简称 syscall，是应用向操作系统请求服务的接口。open 或 openat 请求解析路径并打开对象，read 根据文件描述符读取数据，ioctl 则通过请求编号和参数访问对象特有的控制操作，设备驱动常通过它提供功能。

文件描述符是进程持有的内核对象引用。进程取得描述符之后，后续 read 无需重复解析原来的路径。这也使权限审查不能只盯着路径字符串：限制施加前，进程可能已经拿到了文件、终端或 socket。ioctl 又把许多不同操作放进同一个调用入口，仅统计允许多少种 syscall，无法表达实际开放了多少设备能力。

普通 Linux 容器中的应用直接调用宿主 Linux。宿主内核处理文件、网络和进程操作，也负责执行隔离规则。Firecracker 论文分析的容器路径保留了这个关系：容器可以收紧内核接口，不同工作负载仍共享内核实现，以及页缓存等内核设施。应用可见的环境经过分隔，承接请求的内核没有随容器复制。

命名空间 namespaces 隔开资源的可见视图，例如进程编号、挂载树和网络接口。控制组 cgroups 负责资源核算与限制。seccomp，即安全计算模式，可以按系统调用及部分参数缩减入口。Landlock 是允许普通进程主动削减环境权限的 Linux 安全模块，可对受支持的文件、网络和进程间交互施加限制。

这些机制约束不同的对象。网络命名空间提供独立网络视图，是否允许访问包源仍需网络策略。内存限额约束消耗，无法修复允许调用中的漏洞。seccomp 能拒绝一个调用入口，Landlock 能在支持的访问路径上检查资源权限，二者都依赖宿主内核正确执行。安装器要求开放更多接口时，共享内核承接的攻击面也会变化。

Landlock 官方文档中的规则集需要声明“处理哪些权限”，再为资源添加允许规则。只有声明处理的动作才进入相应的默认拒绝范围，跨目录引用权限 REFER 有特殊规则。规则集只声明读取限制，不能据此推断写入、元数据操作和设备控制全部被拒绝。“默认拒绝”必须连同权限集合一起理解。

Landlock 只能增加限制，无法授予其他权限检查已经拒绝的能力。多层策略共同生效，访问需要通过各层及原有访问控制。文件读写权限主要在打开时检查，已有描述符需要单独处置，继承的终端也可能携带控制能力。启动器若把敏感文件描述符传进沙箱，事后收紧路径权限并不能自动收回它。

线程也是施策对象。默认不能假设现存兄弟线程自动受到新限制，跨线程同步需要对应接口支持。ABI，即应用二进制接口，在这里表示内核与用户程序之间可依赖的接口约定。部署程序需要查询运行中内核支持的 Landlock ABI，不能把最新文档当成本机能力。

这份 Landlock 文档标注 Linux 7.4.0-rc1，包含较晚加入的 UDP 等限制；Sandlock 原型使用的接口范围更早。较新内核具备的能力不能倒灌进旧原型。端口规则也只表达端口权限，无法直接表达域名或 HTTP 路径授权。执行接口若承诺“只能访问指定包源”，仍需解释域名、地址和应用层请求怎样对应。

批准 connect 时，批准的是哪份参数

依赖安装需要连接包源，测试阶段可能完全不需要网络。执行接口若按阶段收紧权限，就要把阶段变化转成可执行规则。Sandlock把静态文件与端口权限交给 Landlock，无条件拒绝交给 seccomp，需要运行时判断的请求交给父进程监督器。它保留共享宿主内核，增加了一个能观察和代办操作的可信进程。

seccomp user notification 会把选定调用通知给监督器，让目标线程等待处理。困难在调用参数中的指针。线程发起 connect 时，参数指向用户内存里的目的地址；监督器读出地址并批准，内核继续执行时可能重新读取该内存。共享地址空间的其他线程可以在两次读取之间替换地址。

这类问题称为 TOCTOU，即检查时与使用时之间的竞态。暂停发起调用的线程，并未暂停共享内存的全部写入者。监督器把地址复制到日志里，也不能保证内核使用日志中的副本。执行接口声称“批准了这个地址”时，必须说明真正执行连接的代码使用哪份数据。

Sandlock 的网络代办路径通过 pidfd_getfd 取得目标 socket 的引用，复制并验证地址或消息参数，再用监督器持有的副本执行操作。原始调用不会继续，内核无须回头重读原来的参数指针。处理期间还要验证通知身份，拒绝任务退出或状态变化后留下的失效请求。

复制解决问题的条件，是检查和执行使用同一份数据。代办还要求监督器取得正确对象，并保持操作语义；代理无法安全完成操作时，仅批准原调用继续执行仍有竞态。监督器需要协调它观察到的文件状态与实际内核状态，代办代码自身也进入可信范围。

execve 的参数数组同样位于用户内存。Sandlock 检查 argv 前，会冻结可能共享地址空间的任务，并追踪进程创建事件，使新任务在执行用户代码前完成登记。ptrace 冻结或创建追踪不可用时，原型拒绝操作。这比暂停一个线程要求更严格，也引入权限条件和额外切换。

命令参数仍只能作为观察和收紧策略的信号。攻击者可以重命名 curl，也可以自己实现网络客户端，实际约束来自文件、调用和网络规则。通过管道连接权限不同的阶段，也只隔开各阶段拥有的能力。管道里的字节仍可能由攻击者构造，下游权限较少不代表输入可信。

Sandlock 信任宿主内核、监督器和嵌入它的 Agent 运行时，不覆盖内核漏洞或故意耗尽全局内核资源。用户态资源核算不能替代 cgroups 级对抗性限制。写时复制工作区能够保留或丢弃文件变更，已经完成的网络请求不会随文件回滚撤销。执行接口中的“回滚”需要写清作用对象。

给安装器一套独立内核

完整工具链会持续提出兼容性要求：安装器创建进程，编译器使用文件系统，测试程序还可能访问特殊接口。独立客体内核，即 guest kernel，让这些应用继续向 Linux 请求服务，同时由虚拟化层限制客体能够控制的资源。宿主不再直接承接安装器构造的每个 Linux 系统调用请求。

Popek 与 Goldberg 的经典论文为虚拟机监控器提出等价性、资源控制和效率要求。等价性要求程序执行效果与真实机器基本一致，允许时间和资源可用性存在差异；资源控制要求监控器掌握分配的资源；效率要求大量无害指令可以直接由硬件执行。这些要求描述了虚拟化希望提供的机器抽象。

论文把敏感指令与特权指令分开。敏感指令影响或依赖机器控制状态，特权指令在非特权模式执行时会陷入监控器。在论文机器模型下，敏感指令集合包含于特权指令集合，足以构造 VMM。论文明确限定逆命题并不普遍成立，不能把充分条件写成所有虚拟化实现必须满足的条件。

这个模型排除了 I/O 和中断，也采用较早的处理器与存储保护假设，不能直接用于裁定现代 VT-x 的能力。形式论证还依赖正确的状态映射、资源分配与解释例程。实际设备实现错误、管理服务授权错误和硬件侧信道，都无法靠满足这组抽象要求自动排除。

2003 年的 Xen面对传统 IA-32 中部分敏感操作降权后难以捕获的问题，采用半虚拟化：修改客体操作系统，让它通过 hypercall 请求受控操作。hypercall 是客体向虚拟化层提出请求的接口，例如提交一批页表更新。应用 ABI 得以保留，既有应用二进制无需随内核移植一起修改。

Xen 的客体内核降低硬件特权级，应用仍保持原有调用关系。经验证的快速系统调用入口允许应用直接进入客体操作系统，无须每次绕经 Xen。页表更新则需要验证，防止客体映射其他域的内存，或取得可写页表映射。“修改了内核”不等于“应用必须重写”，“使用虚拟化”也不意味着每个 syscall 都交给监控器。

资源控制还依赖管理组件。Xen 的特权管理域 Dom0 拥有创建、销毁和配置资源等能力，必须进入安全分析。可信计算基 TCB 指安全保证依赖其正确工作的软硬件集合。监控器代码较少，只能说明其中一个组件的规模，不能代表整个执行平台的 TCB。

同一个 read 的三条路径

执行接口仍提交同一条 Python 命令，应用面前的 Linux 服务可以来自不同实现。

gVisor 的 Sentry是用户态应用内核，独立实现受支持的 Linux 系统接口。应用发出 read，Sentry 解释其语义并管理应用可见状态。部分请求在内部完成，部分转为受限宿主操作。读取宿主支持的文件最终可能产生宿主 read，这不表示应用参数原样直达宿主内核。

使用 ptrace 的执行平台也保留这条边界：Sentry 处理调用，写回寄存器结果，应用恢复到用户态执行。它与检查调用后直接放行的监督器有不同语义。应用需要的内核功能必须有 Sentry 实现，特殊 ioctl、设备和模块接口可能缺失。执行接口需要用真实工具链验证兼容性，不能只确认 Python 能启动。

文件路径取决于配置。Gofer 是为沙箱提供获准文件访问能力的辅助进程，可以提供文件描述符或代办操作。启用 Directfs 时，Sentry 可以在获准目录树内执行受限文件操作，减少逐次访问 Gofer 的通信。“每次文件操作都经过 Gofer”与“Sentry 从不打开宿主文件”都无法覆盖这些配置差异。

HotCloud 2019 的 gVisor 案例研究当时的 Gofer、9P 通信和执行平台，适合解释跨进程通信怎样放大文件元数据操作的成本。它不能提供当前 Directfs 配置的性能结论。依赖安装会大量创建和打开文件，测试记录需要保留 runsc 构建、执行平台与 Directfs 配置，才能辨认成本来自哪条路径。

gVisor 也能使用 KVM 执行平台。这里借用处理器虚拟化设施进行拦截与地址空间隔离，应用 syscall 仍由 Sentry 实现，没有启动一套 Firecracker 式的普通 Linux 客体。看到 /dev/kvm，只能确认某种虚拟化设施进入执行路径，尚不足以判断应用面对哪套内核。

KVM 是 Linux 内核中的虚拟化设施；VMM，即虚拟机监控器，负责配置虚拟处理器、内存和设备。Firecracker、Cloud Hypervisor 属于用户态 VMM 层。使用普通 Linux 客体时，open 在客体内解析路径，read 可能命中客体页缓存，需要读取虚拟磁盘时才涉及设备请求及宿主处理。

VM exit 指处理器从客体执行退出到虚拟化处理路径，触发条件取决于硬件、操作和配置。系统调用进入客体内核，不必每次触发 VM exit。应用 syscall 数量无法直接换算成 VMM 请求数量，虚拟磁盘请求数量也无法直接换算成宿主实际读取次数。

Firecracker 的设计中，每台 microVM 对应一个 Firecracker VMM 进程，客体内部可以运行多个应用进程。论文明确其替换对象是 QEMU。它通过精简虚拟设备缩小实现范围，保留客体所支持的 Linux 软件能力，但无法承诺任意内核、设备与操作系统都能运行。论文版本缺少 BIOS、传统 PCI 等完整机器功能，这也限定了兼容性。

Kata Containers位于容器运行时集成层，兼容 OCI，即开放容器倡议的运行时规范。宿主上的 Kata shim 接收 containerd 等容器管理器的生命周期请求，启动配置好的虚拟化后端，通过通信协议联系客体内的 kata-agent，由后者创建容器环境并管理工作负载。

Kata shim 留在宿主，kata-agent 留在客体，应用使用客体内核。Kata 不承担 Kubernetes 控制面，也不充当 VMM，使用范围包含 Kubernetes 之外的容器工作流。它与 Firecracker 可以处在同一系统的不同层，具体组合仍需核对版本与支持范围。同一 Pod 的多个容器也可能共享一台 VM，容器数量不能代表独立内核边界数量。

客体失陷之后仍要约束 VMM

Firecracker 把客体内核视为不可信组件，宿主安全应允许它完全被攻击者控制。这个威胁模型没有规定逃逸必须经过固定阶梯。应用可能利用合法设备请求触发问题，也可能攻击共享文件服务或管理协议。错误挂载甚至会直接交出宿主文件，无需攻击者取得客体内核控制权。

jailer 与生产宿主建议给 VMM 增加宿主进程约束。jailer 完成需要较高权限的资源设置，限制文件系统视图，应用命名空间与 cgroups，降权后运行 Firecracker。seccomp 继续收窄宿主调用。攻击者取得 VMM 代码执行之后，仍应受到这些进程权限限制。

约束是否有效依赖部署细节。jailer 输入路径及父目录不能由不可信用户改写，磁盘和管理接口权限需要匹配实例归属。逐实例使用独立 UID、GID，可以限制一个实例访问其他实例资源。KVM、宿主内核、VMM 和处理器微码仍需维护，进程权限限制也无法消除硬件侧信道。

Firecracker 把网络包送往宿主 TAP 设备，不自动实施出口过滤。允许访问包源与允许访问任意公网是不同授权，合法服务也可能接收外传数据。凭证代理能够把长期密钥留在沙箱外，代理仍需按目标和操作授权，否则攻击者可以让代理代它完成有害请求。

日志同样占用宿主资源。客体能够影响串口输出和 VMM 日志量，限制客体内存不会阻止宿主日志增长。生产指南也指出，部分 KVM 后台内核线程的资源归属需要额外处理。核算要覆盖客体工作集、页缓存、VMM、管理进程及后台工作；租户总并发仍需调度层约束，多个守住单任务限额的实例也可能共同占满节点。

创建请求为何仍然很慢

执行接口收到创建请求后，还要准备磁盘、网络和管理状态。LightVM缩小客体后发现，Xen 工具栈成为显著成本。XenStore 交换配置与设备信息，消息及确认会引起中断和跨域切换；实例增加后，名称检查、事务重试与日志轮转也影响创建延迟。

LightVM 用 noxs 设备信息页和事件通道替代创建、启动过程中的 XenStore 交互。设备页对客体只读，由 Dom0 请求修改，客体也需配合修改。管理路径改用 chaos/libchaos，并让常驻 xendevd 处理设备设置，避免每次启动 bash 脚本。优化对象已经延伸到虚拟机外的控制流程。

创建过程被拆成 prepare 与 execute。后台 prepare 提前生成 VM 壳、分配资源并准备可复用部分，请求到来时 execute 解析配置，取合适的壳，加载镜像并完成设备初始化。请求路径缩短，后台池仍需要容量和补充工作。“启动快”的描述必须交代多少工作已经提前完成。

作者在 Xen 4.8、四核 Xeon E5-1630 v3、128GB 内存机器上，使用无设备 noop unikernel 与全部优化，报告创建并启动的最低时间为 2.3 毫秒。unikernel 将应用与所需操作系统功能链接在同一执行环境中；该 noop 客体没有运行通用安装器所需的工具链。Mini-OS 路径也没有用户与内核分离，缺少完整进程与 fork 模型。

基于 Linux 的 Tinyx 保留更多应用能力，同时承担更多内存和后台工作。最快 VM 启动数字无法回答 pip install 多久完成，安装器需要文件系统、网络、进程与语言运行时。Firecracker 的精简客体启动、VMM 内存开销和完整任务成本也有不同口径。论文当时的块设备写入测试还受缺少 flush-to-disk 的持久性语义影响，吞吐必须连同“完成写入”的含义一起阅读。

云虚机里再运行一台虚机

云部署通常把最底层平台称为 L0，租户云虚机称为 L1，内部沙箱虚机称为 L2。传统硬件嵌套虚拟化需要外层暴露相应能力，L1 才能使用合适的 KVM 后端。Simon Willison 的 smolvm 研究记录中，最初环境本身是 Firecracker 客体，缺少 /dev/kvm 与虚拟化标志，无法运行那次方案。这个结果只约束该环境。

嵌套还影响地址转换。L2 应用虚拟地址需要映射到 L2 物理地址，再到 L1 物理地址，最终到 L0 管理的真实物理地址。传统实现会合并或维护这些映射，页表更新与缺页可能引起多次状态切换。成本受内存访问、进程创建和并发影响，无法只凭层数推断整个 Agent 任务慢多少。

PVM把 L2 应用和内核都降到硬件用户态，通过不同页表隔离。L1 维护影子页表，将 L2 虚拟地址映射到 L1 物理地址，外层以论文讨论的 EPT 完成到真实物理地址的转换。switcher 是跨地址空间切换的短代码，在多个地址空间映射于相同虚拟地址，负责保存状态、切换页表和进入目标环境。

普通 syscall 可经 direct switch 进入 L2 内核，绕过 PVM 主处理路径，返回使用配套 hypercall。敏感操作由修改后的客体内核协作处理。PVM 需要专用宿主 kvm.ko、kvm-pvm.ko 和配套 guest；保留 KVM 接口，不代表任意没有 KVM 的机器都能原样运行 Firecracker。

PVM 免去的是 L0 暴露嵌套 VMX 的要求，L0 与 L1 之间仍使用硬件虚拟化，中断和外层缺页仍可能涉及 L0。影子页表也需要维护，fork 与大量小内存分配可能增加页表和缺页工作。CubeSandbox 的部署实践安装了支持 PVM 的宿主内核和客体，补丁维护属于部署条件，不能从说明中省略。

CKI尝试取消两阶段地址转换，让应用 syscall 和页故障直接进入独立容器内核。客体内核留在硬件内核态，PKS，即监督态内存保护键，用来隔开部分内存访问；每容器的内核安全监控器 KSM 验证页表声明与更新。

普通 PKS 无法阻止恶意内核执行危险特权指令，CKI 还需要新的硬件检查、切换门及中断返回语义。论文发表时部分扩展尚不可用，实机用 wrpkru 模拟部分机制，新增检查使用 Gem5 评估。它说明了地址转换和切换可以怎样重新设计，也保留着硬件实现条件，不能当作现成后端部署。

健康检查通过，任务准备好了吗

Plori 的嵌套 Firecracker 记录明确区分了计时终点：Ubuntu 24.04、节点内核 6.8、AMD 嵌套 KVM、Firecracker 1.17.0、guest 内核 6.18.44，生产 guest 配置为 2 vCPU、1 GiB。305 次冷启动中，请求到 Agent 健康的中位数为 1.38 秒，配置调用开始到 InstanceStart 的中位数只有 10 毫秒。

API 可响应之后仍要配置 VM，InstanceStart 之后仍要初始化并启动 Agent。用户需要等待依赖可用和产物完成，计时终点还会向后移动。Plori 没有验证更高并发下的启动表现，这批样本无法承诺高密度同时创建。执行接口至少需要区分已创建、可通信和能接受任务，避免把一个管理状态当成全部准备工作完成。

恢复会引入时钟状态。Plori 的嵌套节点使用 kvm-clock，其环境中恢复时推进墙上时钟的 clock_realtime 与 KVM PTP 路径不可用，改由节点提供 NTP。测试中恢复旧快照后仍有数秒旧时间窗口。健康检查成功，只能证明检查路径工作，尚不能确认时间相关令牌和请求判断已经使用正确时钟。

任务若只做受控数据转换，也可以缩减所需执行模型。MicroPython 与 Wasm 实践把解释器编译为 WebAssembly，在 wasmtime 中运行。Wasm 是供运行时执行的二进制指令格式，这里的 Python 通过显式宿主函数获得外部能力，没有完整原生 Linux 进程接口。

持久会话通过线程和请求、回复队列传送代码，解释器调用宿主函数等待任务。wasmtime 提供内存限制，fuel 提供 Wasm 操作预算。fuel 不能直接换算成精确 CPU 秒数，也没有证据表明它覆盖阻塞宿主回调。回调若开放任意文件或网络访问，权限就会经回调重新进入环境；MicroPython 的标准库和原生扩展兼容性也无法等同完整 CPython。

本地编码任务通常需要更多宿主交互。SideKernel在 macOS 上用 Apple Virtualization 框架和 Swift VMM 运行 Linux，借用 Kata 提供的内核，没有运行 Kata runtime。当前目录通过 VirtioFS 双向挂载，客体内 PID 1 通过 vsock 协调终端和端口等服务。Linux 应用调用仍由客体内核处理。

双向挂载允许 Agent 读取、编辑或破坏该目录；自动端口转发也会向宿主暴露恶意客体服务。凭证代理减少密钥直接暴露，首次在客体认证仍有原文注明的例外。网络 kill-switch 保留 Claude API 通道，不能称为完全断网。该原型仅在特定 M1、M4 与 macOS Tahoe 26.2 环境测试，未经正式安全审查，也不适合据此推断原生 macOS 应用测试能力。

模板保留了什么，销毁又删除了什么

执行接口希望复用预装依赖的环境，需要把模板、磁盘状态和运行现场分开。模板只是可复用起点的泛称，可能来自磁盘镜像，也可能来自预启动 VM 的快照。这个名称本身不能说明实例会重新启动哪些进程，更不能承诺恢复任意执行时点的完整现场。

磁盘快照保留文件系统状态，不保留运行进程的内存与寄存器。包含内存、寄存器和设备状态的快照才涉及运行现场恢复，仍需协调磁盘一致性和外部服务状态。执行接口若只暴露一个 snapshot 方法，调用方仍需知道它覆盖哪些对象，以及保存过程中哪些写入已被确认。

SideKernel 的 save 保存 OverlayFS 磁盘变更，CubeSandbox 上述实践中的 snapshot 也仅保存文件系统。二者都不能承诺继续运行原来的浏览器或进程树。Marc Brooker 的 Firecracker 回顾介绍了 DSQL 的另一种路径：预启动 Linux、PostgreSQL 和管理组件，保存内存、寄存器及设备状态，多次恢复为查询处理实例。

这些克隆共享未修改的干净页，发生写入时各自取得页面副本，避免共享可写内存。这是具体系统的设计，不能推广为所有 VMM 都具有相同共享页机制、克隆 API 或热迁移能力。快照也复制初始化状态，随机数和令牌唯一性需要额外处理，共享干净页的说明无法替代侧信道审计。

DSQL 定期终止查询处理 VM 以回收累积缓存，前提是连接处理、缓存和并发控制等状态已安排在 VM 外。Agent 会话销毁也只结束实例内状态，显式 Memory、外部工具和已经完成的网络写入仍然存在。恢复一个较早的磁盘状态，无法撤销沙箱已经提交给外部服务的操作。

/output/report.csv 何时可以发布

任务结束后，可信导入器若检查路径再重新打开，攻击者可能在间隙替换符号链接。导入器跟随链接时，甚至可能读取宿主文件。即使路径解析安全，仍存活的写进程也能在验证之后修改文件内容。文件描述符减少重复路径解析，不能自动使文件内容不可变。

相关工程分析要求产物发布使用稳定视图：阻止继续写入并确认执行停止，取得沙箱无法修改的快照或受控副本。导入器在这个视图上验证文件类型、路径、数量和字节预算，读取已打开的对象，并把结果关联到正确客户和任务。产物跨越边界时，导入器本身就是需要授权与限额的组件。

取消请求也必须进入发布协议。面向模型的工具返回超时，只表示调用方停止等待。控制器仍要确认实例终止，拒绝旧执行代次的迟到日志和产物，收回临时网络与工具权限。执行代次用来区分同一任务标识下的不同尝试，避免旧实例在重试之后继续提交结果。

停止状态不明时，工作目录不能立即交给新任务，资源预算也不能提前释放。旧写入者可能仍在运行，新任务看到的目录便没有稳定归属。控制器需要验证失联实例怎样失去写入和发布权限；恢复后的时钟尚未校正时，凭证代理是否仍会接受过期请求，也需要在具体部署中验证。

文中机制与测试结果来自链接中的公开资料，未独立复现实验。性能结果保留原作者报告的环境与计时边界。

本文由 AI 辅助整理