Find a better alternative to run untrusted code

[marcoieni]

This was discussed at rust-lang/all-hands-2026#49

At the moment docs-rs uses https://github.com/rust-lang/rustwide to run untrusted code

What is Rustwide

Rustwide is a library similar to Cmd::new that allows to run Rust code in Docker containers.

It is used by crater and docs-rs. The playground uses another mechanism.

For every operation creates docker containers with certain configuration. There are 4 containers as part of the build:

• cargo fetch has network access
• next steps don't have network access
  • generate lock files
  • build the code
  • run the test (maybe docs-rs doesn't use this. Anyway, this is just to give a tldr of rustwide)

It has resource limits through dockers.
It uses a common docker images with a lot C dependencies.

Challenges of Rustwide

Rustwide requires access to the docker socket. So it can't run on AWS ECS. This is why the docs-rs builder needs to run on EC2 right now.

Problem with Rustwide

We can't rely on docker for isolation. There are vulnerabilities like https://copy.fail/ that can allow a docker container to get root access to the host.

Alternatives to rustwide

We need to find alternative ways to build docs that ensure better security.

General principles:

• minimal permissions: eg we could scope VMs to only upload to a certain s3 bucket paths
• recycle image builds every X hours. Eg spin up new EC2 instances regularly with the newest ubuntu images. Eg we can use packer to build AMIs.
  • We have a packer config for the gh actions runner. We can build packer in github actions with oidc roles.
  • Packer doesn't need virtualization, it just calls the aws api and ssh into it to configure it. It also works across any cloud provider (aws, gcp, oxide, etc).
  • Let's not run ansible in packer because ansible makes sense when there's the need to run the same script twice. Instead, in packer we just run scripts only once.
• networking proxying / firewall requirements?

AWS ECS

We need to be able to run some steps without network. Maybe we can only have an allow list of URLs that can be reached (eg crates-io access).

Autoscaling groups

Run docker in ec2 (or gcp vms) instances that are part of an autoscaling group.
The host runs separately (it can be anything, eg AWS ECS, because there is no need for the docker socket anymore).

Pro: EC2s are cheaper than ECS.

Running docker (via rustwide for example) in VMs will guarantee strong isolation.

We want to run one job for each EC2 instance (using rustwide and nginx proxy like things are now).
Either we ec2 image pulls for a job or the host assigns jobs (the exact mechanism is undecided).

Micro VMs

We could have an host running micro VMs like firecracker, because they provide a better security than docker

Con: we still need to patch the hypervisor for CVEs from time to time

It might not be cheaper than a network isolated vpc. But we might need a proxy to docs-rs and crates-io.

Lambda micro VMs

New feature to be investigated: https://aws.amazon.com/about-aws/whats-new/2026/06/aws-lambda-microvms/

Note that lambdas are maximum 15 gb so we can't use it for docs-rs and crater because the base docker image we use is larger than 15GB. (not sure if with this new feature it is different).

Also it might be better to stick with ec2 so that it's easier to move crater and docs-rs to different cloud providers.

[syphar]

Some initial notes, more the next days: generally this is also on my list, and I want to make everything more secure somehow.

One detail about rustwide is slightly wrong:

• some commands like cargo fetch we just run on the host / outside of the container
• all potentially malicious things run in one container (one docker create, one set of settings, multiple docker run for the necessary steps). This was an optimization I made for faster builds.

The main concern I have is the build capacity / build speed. If we choose a technique that adds much more time around the actual build, or makes i/o much slower, we have to plan for a big chunk of increased build capacity. After having had to fight queue length I would prefer a fast solution, or build capacity that is increased in the same factor that we slow down builds.

I feel like running full VMs (ec2) might be too slow, assuming we need to reset them after each build to prevent leaking. Same for ECS?

Options I had in mind, not knowing if they provide the right isolation / build speed:

• gvisor ( here a working prototype with rustwide )
• kata ( can also be used with the container shim, so no major change to rustwide needed)
• firecracker

kata / firecracker of course need KVM, so a bare metal ec2 machine type.

I would love to talk about this with someone with more experience.