container2wasm: Running Existing Linux Containers on WebAssembly#

Traditional Porting Limitations#

Porting applications to WebAssembly typically requires:

• Recompiling source code with WASM-compatible toolchains
• Reimplementing platform-dependent code
• Adapting to WASM’s sandboxed environment
• Dealing with missing kernel APIs
• Significant development time and effort

The container2wasm Solution#

Rather than requiring application modifications, container2wasm converts entire container images - including the Linux kernel - to run on WebAssembly. This approach enables:

• Zero modification of existing applications
• Support for any Linux-based container
• Preservation of existing workflows
• Immediate WebAssembly compatibility

Architecture Overview#

The converter creates a WASM image containing:

1. CPU Emulator: Bochs (x86_64) or TinyEMU (RISC-V) compiled to WebAssembly
2. Guest Linux Kernel: Full Linux kernel running on the emulated CPU
3. Container Runtime: runc for container management
4. Original Container: Unmodified container image and applications

Technical Stack#

Prerequisites#

• Docker with BuildKit support
• Docker Buildx v0.8+ (recommended)
• c2w command from official releases

Basic Usage#

1
$ c2w ubuntu:22.04 out.wasm
2
$ wasmtime out.wasm uname -a
3
Linux localhost 6.1.0 #1 Wed Feb 15 04:09:09 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

1
$ c2w riscv64/ubuntu:22.04 out.wasm
2
$ wasmtime out.wasm uname -a
3
Linux localhost 6.1.0 #1 Wed Feb 15 04:09:09 UTC 2023 riscv64 riscv64 riscv64 GNU/Linux

1
$ mkdir -p /tmp/share/ && echo "Hello from host" > /tmp/share/greeting
2
$ wasmtime --mapdir /container/share::/tmp/share -- out.wasm \
3
    --entrypoint=cat -- /container/share/greeting
4
Hello from host

1
$ c2w --to-js ubuntu:22.04 /tmp/out-js/htdocs/

1
$ cp -R ./examples/emscripten/* /tmp/out-js/
2
$ docker run --rm -p 8080:80 \
3
    -v "/tmp/out-js/htdocs:/usr/local/apache2/htdocs/:ro" \
4
    -v "/tmp/out-js/xterm-pty.conf:/usr/local/apache2/conf/extra/xterm-pty.conf:ro" \
5
    --entrypoint=/bin/sh httpd -c \
6
    'echo "Include conf/extra/xterm-pty.conf" >> /usr/local/apache2/conf/httpd.conf && httpd-foreground'

Development Environments#

Run full development stacks in the browser:

1
# Python development environment
2
$ c2w python:3.11-alpine python-dev.wasm
3
$ wasmtime python-dev.wasm python --version
4
Python 3.11.x
5

6
# Node.js environment
7
$ c2w node:18-alpine node-dev.wasm
8
$ wasmtime node-dev.wasm node --version
9
v18.x.x

Legacy Application Support#

Run legacy applications without modification:

1
# Legacy database tools
2
$ c2w legacy/mysql-client:5.6 mysql-tools.wasm
3

4
# Old build environments
5
$ c2w centos:6 legacy-build.wasm

Educational Use Cases#

Provide safe, sandboxed Linux environments:

1
# Linux learning environment
2
$ c2w alpine:latest learn-linux.wasm
3
$ wasmtime learn-linux.wasm sh
4
/ # ls /proc
5
/ # ps aux

Architecture Impact#

Performance varies significantly by architecture:

• x86_64: Native performance with Bochs emulation
• RISC-V: Good performance with TinyEMU
• Other architectures: Additional QEMU layer impacts performance

Optimization Strategies#

1. Choose appropriate base images:

   • Prefer x86_64 or RISC-V base images
   • Use minimal distributions (Alpine, distroless)

2. Pre-initialization with wizer:

   • Reduces startup time
   • Available for WASI targets only

3. Image size optimization:

   • Remove unnecessary packages
   • Use multi-stage builds
   • Minimize filesystem layers

Typical Image Sizes#

• Alpine-based: 70-90MB
• Debian slim: 130-200MB
• Ubuntu: 200-300MB
• Full development environments: 300-500MB

container2wasm#

Approach: CPU emulation with full Linux kernel Advantages:

• Run any existing container without modification
• Support multiple architectures
• Mature container ecosystem compatibility
• Standard container workflows

Disadvantages:

• Performance overhead from emulation
• Larger binary sizes
• Additional abstraction layers

WasmLinux#

Approach: Native WebAssembly compilation Advantages:

• No CPU emulation overhead
• Smaller binary sizes
• Direct WebAssembly execution
• Better theoretical performance

Disadvantages:

• Requires application recompilation
• Limited to compatible applications
• Currently only BusyBox support
• Many missing features

When to Use Each#

Use container2wasm when:

• You have existing containers to run
• Application source isn’t available
• You need full Linux compatibility
• Development time is limited

Use WasmLinux when:

• Building new WASM-native applications
• Performance is critical
• You control the full stack
• Exploring WASM-native OS concepts

Sandboxing Layers#

container2wasm provides multiple security boundaries:

1. WASM sandbox: Limited host access
2. CPU emulation: Additional isolation
3. Container runtime: Process separation
4. Linux kernel: Standard security features

Trust Boundaries#

• Host system remains protected by WASM sandbox
• Containers see only emulated hardware
• No direct system call access to host
• Network isolation by default

Planned Improvements#

1. Performance optimizations:

   • JIT compilation for emulators
   • Improved memory management
   • Faster startup times

2. Feature additions:

   • GPU acceleration support
   • Advanced networking features
   • Persistent storage options

3. Platform expansion:

   • More architecture support
   • Cloud runtime integration
   • Edge computing scenarios

Community Development#

The project is open source and actively seeking contributions:

• Performance improvements
• Architecture support
• Tool integrations
• Use case documentation

1. CI/CD Pipelines#

Run build environments in WebAssembly:

1
$ c2w golang:1.20 go-builder.wasm
2
# Use in CI without installing Go

2. Security Research#

Analyze malware in isolated environments:

1
$ c2w malware-analysis:latest sandbox.wasm
2
# Safe execution without host risk

3. Application Distribution#

Ship applications with dependencies:

1
$ c2w myapp:latest portable-app.wasm
2
# Single file distribution

4. Cloud Functions#

Deploy containers as WebAssembly functions:

1
$ c2w microservice:latest function.wasm
2
# Deploy to WASM-enabled FaaS

Current Limitations#

1. Performance overhead: CPU emulation impacts speed
2. Image size: Larger than native WASM applications
3. Startup time: Initial boot can be slow
4. Resource usage: Higher memory consumption

Best Practices#

1. Container optimization:

   • Use minimal base images
   • Remove unnecessary services
   • Optimize for single-process containers

2. Architecture selection:

   • Prefer x86_64 or RISC-V
   • Avoid multi-architecture builds

3. Resource planning:

   • Allocate sufficient memory
   • Consider startup time in workflows
   • Plan for larger file sizes