dd

Ejecuta contenedores de Linux en macOS — sin VM.

¿Qué es dd?

dd ejecuta contenedores de Linux de forma nativa en macOS con Apple Silicon sin una máquina virtual. No hay núcleo de Linux ni hipervisor subyacente: un JIT traduce el código del contenedor y procesa sus llamadas al sistema de Linux en espacio de usuario (linaje gVisor / PRoot). El JIT es el núcleo de Linux del invitado: los namespaces, cgroups, capas de imágenes overlay y la red se mantienen como estado de espacio de usuario. Habla la API del Motor Docker, por lo que el CLI docker habitual lo maneja.

La computación del contenedor se ejecuta como instrucciones nativas de Apple Silicon; solo sus llamadas al sistema son interpretadas. Sin VM que arrancar, sin demonio en una VM, sin costo de virtualización.

Sitio web y documentación: https://ricccrd.github.io/dd/

make jit                                          # build.rs compila + firma los JITs
DD_IMAGES=/path/to/images cargo run -p dd-daemon  # inicia el demonio
export DOCKER_HOST=unix://$PWD/dd.sock
docker run -p 8080:80 -m 256m alpine sh -c 'echo hi from $(hostname)'

Características

• Sin máquina virtual. Sin hipervisor, sin núcleo de Linux, sin VM residente. Las instrucciones del invitado se ejecutan de forma nativa en arm64; solo el límite de llamadas al sistema es interceptado y procesado en espacio de usuario.
• Drop-in Docker. dd implementa la API del Motor Docker. Apunta DOCKER_HOST a su socket y tus comandos existentes docker run / ps / images / build funcionan sin cambios.
• El JIT es el núcleo. Namespaces, cgroups, capas de imágenes overlay y red son estado ordinario de espacio de usuario — un núcleo en espacio de usuario en el linaje de gVisor/PRoot, sin ningún costo de VM.
• Tres entornos de ejecución invitados, un motor. Imágenes nativas arm64 Linux; imágenes x86-64 Linux mediante un JIT (jit86) que decodifica x86, sintetiza sus flags y baja SSE/x87 a NEON (los binarios glibc funcionan); e invitados macOS arm64 (ddcli mac) — sin VM en ninguno de ellos.
• Aislamiento real de contenedores. Capas de imágenes overlay (copy-up / ocultación .wh., getdents fusionados), un VFS de jaula de rutas libre de TOCTOU, namespaces PID / UTS / USER, una netns de loopback privada con publicación de puertos -p, y límites de cgroup de memoria + pids (OOM en el límite).
• Aplicación de escritorio, sin root. Una aplicación GTK4 nativa (dd-app) más un CLI dd instalan un demonio en segundo plano por usuario y un — todo bajo , nunca .

Por qué un JIT, no una VM?

Cualquier otra forma de ejecutar contenedores de Linux en un Mac — Docker Desktop, Colima, Rancher, OrbStack — arranca una VM de Linux bajo un hipervisor y ejecuta el demonio dentro de ella. Esa VM es un impuesto que pagas todo el día. dd la elimina: un contenedor es un proceso normal de macOS cuyas llamadas al sistema son gestionadas por un núcleo de Linux en espacio de usuario.

La ventaja es estructural: la computación del invitado se ejecuta como instrucciones nativas de Apple Silicon (sin capa de virtualización de hardware en la ruta crítica), y el conocido cuello de botella de intercambio de archivos de Docker Desktop — el puente virtiofs/FUSE entre macOS y la VM — simplemente no existe, porque el VFS de dd es el sistema de archivos del anfitrión detrás de una jaula de rutas.

Compensación honesta: un núcleo en espacio de usuario solo es tan completo como las llamadas al sistema que implementa, y hoy Por defecto, el invitado se ejecuta en un proceso — rápido, y la decisión correcta para código de confianza (tu entorno de desarrollo, CI, tus propias herramientas). Para código no confiable ahora hay una división de centinela optativa (DDJIT_UNTRUSTED): el invitado se ejecuta en una caja de arena Seatbelt con denegación por defecto que no tiene autoridad de sistema de archivos/red del anfitrión, mientras que un proceso centinela de confianza posee los recursos reales y sirve las llamadas al sistema a través de un anillo de memoria compartida — la forma de gVisor. Es temprano (las llamadas al sistema de archivos principales — read/write/open/close/lseek — se reenvían hoy; sockets/exec/fork están llegando), así que para código completamente hostil, una VM todavía expone una superficie más reducida.

Rendimiento

El mismo binario estático de Linux, ejecutado de dos formas en un Apple M5 Pro (macOS 26.3): dentro de la VM de Linux (cómo los Docker basados en VM ejecutan contenedores) vs. a través del JIT de dd en el anfitrión sin ninguna VM. Mediana de 7 (make bench). Un tiempo menor es mejor; "dd vs VM" > 1× significa que dd es más rápido. El carril de dd incluso paga un pequeño impuesto de puente entre procesos que la aplicación real no tiene — por lo que son conservadores.

Contenedores x86-64 — dd vs emulación en VM (qemu-user; ejecutar x86 en Apple Silicon significa traducirlo de cualquier manera). El JIT de dd supera a qemu en 9 de 10 cargas de trabajo, dramáticamente en punto flotante:

Contenedores aarch64 — dd vs una VM nativa (la VM ejecuta arm64 a velocidad nativa total — la barra más difícil):

dd ejecuta la computación arm64 a velocidad nativa — adelante en int sieve + mandelbrot, en paridad en SHA-256, matmul, memcpy, n-body y base64. Las brechas restantes son trabajo intensivo en ramas indirectas / llamadas al sistema — qsort (~1.3×), text-scan (~1.35×) y SQLite (~1.5×) — reducidas drásticamente por los últimos pases (§B-off + x16/x17 robado llevó a SQLite de ~1.9× a ~1.5×). Cerrar el resto (despacho VDBE) es la frontera activa; consulta docs/design/arm-sqlite-parity.md. (Cada carga de trabajo está dimensionada para ejecutarse ≥0.45s, por lo que el pequeño impuesto de puente por ejecución del arnés es insignificante aquí).

Estos son microbenchmarks de computación — ni siquiera capturan las ventajas estructurales de dd (sin VM que arrancar, sin RAM residente, E/S directa del sistema de archivos del anfitrión). Todos los números medidos, mediana de 7. Reproduce: make bench.

El objetivo es superar a la VM en todos los benchmarks. dd ya gana en cada carga de trabajo x86-64 anterior e iguala o supera a arm64 nativo; donde todavía está detrás — SQLite arm64 intensivo en syscall/asignación, y exprimir más del traductor x86 — es exactamente la frontera de optimización (el optimizador de trazas de nivel 2 y el trabajo de rendimiento jit86). La paridad o mejor en todas partes es el estándar.

Cómo funciona

dd ejecuta un contenedor de Linux al ser su núcleo en espacio de usuario. Un JIT traduce el código máquina del invitado e intercepta cada instrucción de llamada al sistema; el manejador de intercepción — service() en dd-jit/src/runtime/os/linux/ — es la ABI de llamadas al sistema de Linux, implementada contra el anfitrión macOS.

1. Cargar el ELF invitado (static-PIE, o dinámico a través de su ld.so) y construir la pila inicial.
2. Traducir & despachar el PC invitado bloque por bloque; el código de la misma ISA se translitera principalmente, x86-64 se decodifica y se reemite en arm64.
3. Ejecutar el bloque traducido como código nativo del anfitrión hasta un terminador (rama / salto indirecto / llamada al sistema).
4. Serviciar la llamada al sistema — cada ruta pasa a través de la jaula VFS del contenedor; los namespaces y cgroups son simplemente estado del proceso.

Ejemplos

# 1. Inicia el demonio, apunta docker hacia él
make jit
DD_IMAGES=/path/to/images cargo run -p dd-daemon
export DOCKER_HOST=unix://$PWD/dd.sock

# 2. Es simplemente Docker
docker run -p 8080:80 -m 256m alpine sh -c 'echo hi from $(hostname)'
docker ps
docker images
docker run --rm -it ubuntu bash

# 3. O mediante la aplicación de escritorio instalada (por usuario, sin root)
dd install                                  # LaunchAgent + docker context
dd app                                       # abre la GUI
docker --context dd run alpine echo hi

Instalación

dd está dirigido a macOS con Apple Silicon (arm64, macOS 12+). El JIT necesita las Herramientas de Línea de Comandos de Xcode (clang + codesign).

Descargar la aplicación (recomendado)

Obtén el último .dmg de la página de versiones, ábrelo y arrastra dd a Aplicaciones. Luego en un terminal:

dd install     # árbol ~/.dd + LaunchAgent por usuario + `docker context create dd`
dd app         # abre la GUI
dd doctor      # verifica socket / agente / contexto / cuarentena de la app

Gatekeeper: el DMG no está firmado (ad-hoc). En el primer inicio, haz clic derecho en la aplicación → Abrir, o ejecuta xattr -dr com.apple.quarantine /Applications/dd-app.app (dd doctor detecta esto e imprime la solución).

Compilar desde el código fuente

xcode-select --install                       # clang + codesign
# instala Rust (estable) y Nix (para el shell de desarrollo GTK4)
git clone https://github.com/ricccrd/dd && cd dd
make app       # compila + ensambla & firma ad-hoc target/dd-app.app
make dmg       # -> target/dist/dd-<ver>-<arch>.dmg
make install   # copia a /Applications y ejecuta `dd install`

make app/dmg ejecutan el empaquetado dentro del shell de desarrollo Nix (nix/flake.nix), que proporciona GTK4 + dylibbundler / create-dmg. El paquete reubica el grafo de dylib de GTK en Contents/Frameworks, prepara los datos de tiempo de ejecución de GTK y firma ad-hoc de adentro hacia afuera.

Espacio de trabajo

Un espacio de trabajo de Cargo.

• dd-jit/ — el entorno de ejecución JIT (C, bajo src/runtime/) más sus enlaces Rust. build.rs compila y firma un binario JIT por arquitectura invitada (aarch64, x86_64); src/lib.rs expone Guest + el contrato de lanzamiento tipado SpawnConfig. El invitado aarch64 está completamente descompuesto (motor jit/ + personalidad os/linux/ + frontend frontend/aarch64/); el invitado x86-64 (jit86) comparte la capa os/linux/.
• dd-daemon/ — el demonio de la API del Motor Docker. Detecta la arquitectura invitada de cada imagen desde su ELF, elige el JIT correspondiente y lo lanza mediante .

El demonio escucha en ~/.dd/run/docker.sock; tanto la GUI como docker --context dd lo utilizan. El estado persiste en ~/.dd/state.json.

Pruebas

make test                       # la matriz motor × caso, informe agrupado
make test ENGINE=x86_64         # un motor
make test FILTER=container      # un grupo / casos que coinciden con un nombre
cargo run -p dd-tests -- --list # lista grupos + casos
make test-ci                    # la ruta de cargo-test (CI)

Los casos se declaran en dd-tests/src/cases/. Un caso es un programa invitado + aserciones; los invitados aarch64 se compilan sobre la marcha (gcc -static-pie) y se comparan con un oráculo nativo, los invitados x86-64 provienen de fixtures precompilados. Cada caso se ejecuta en cada motor para el que tiene un invitado.

Estado

• Invitado: Linux aarch64 (descompuesto, motor de contenedores completo) + x86-64 (jit86, ejecuta glibc).
• Anfitrión: macOS arm64 (Apple Silicon). El JIT necesita clang + codesign (Xcode CLT).
• Contenedores: rootfs + capas de imágenes overlay (copy-up/whiteout), volúmenes bind, publicación de puertos (-p), netns loopback privada, límites de cgroup de memoria+pids, namespaces UTS/PID/USER.
• Hoja de ruta: descarga/desempaquetado de registros OCI, desduplicación de jit86 en el motor compartido, una pila de red externa completa, y la división de centinela para imágenes no confiables. Consulta docs/ para los informes detallados.

Autor

Richard Hutta — [email protected]

Licencia

MIT.