dd

Esegui container Linux su macOS — senza VM.

Cos'è dd?

dd esegue container Linux in modo nativo su macOS con Apple Silicon senza una macchina virtuale. Non c'è kernel Linux né hypervisor sottostante: un JIT traduce il codice del container e gestisce le sue chiamate di sistema Linux nello spazio utente (la discendenza gVisor / PRoot). Il JIT è il kernel Linux dell'ospite — namespace, cgroups, layer di immagini overlay e rete sono mantenuti come stato dello spazio utente. Parla l'API Docker Engine, quindi la normale CLI docker lo comanda.

Il calcolo del container viene eseguito come istruzioni native Apple Silicon; solo le sue chiamate di sistema vengono interpretate. Nessuna VM da avviare, nessun demone in una VM, nessun costo di virtualizzazione.

Sito web e documentazione: https://ricccrd.github.io/dd/

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

Funzionalità

• Nessuna macchina virtuale. Nessun hypervisor, nessun kernel Linux, nessuna VM da tenere residente. Le istruzioni dell'ospite vengono eseguite nativamente su arm64; solo il confine delle chiamate di sistema viene intercettato e gestito nello spazio utente.
• Docker sostitutivo. dd implementa l'API Docker Engine. Punta DOCKER_HOST al suo socket e i tuoi comandi docker run / ps / images / build esistenti funzionano invariati.
• Il JIT è il kernel. Namespace, cgroup, layer di immagini overlay e rete sono normale stato dello spazio utente — un kernel in spazio utente della discendenza gVisor/PRoot, senza alcun costo di una VM.
• Tre runtime ospite, un solo motore. Immagini arm64 Linux native; immagini x86-64 Linux tramite un JIT (jit86) che decodifica x86, sintetizza i suoi flag e abbassa SSE/x87 su NEON (i binari glibc funzionano); e ospiti macOS arm64 (ddcli mac) — nessuna VM in nessuno di essi.
• Isolamento reale dei container. Layer di immagini overlay (copy-up / .wh. whiteout, getdents uniti), un VFS path-jail senza TOCTOU, namespace PID / UTS / USER, una netns di loopback privata con pubblicazione della porta -p, e limiti cgroup di memoria + pids (OOM al limite).
• App desktop, senza root. Un'app nativa GTK4 (dd-app) più una CLI dd installano un demone in background per utente e un — tutto sotto , mai .

Perché un JIT, non una VM?

Ogni altro modo per eseguire container Linux su un Mac — Docker Desktop, Colima, Rancher, OrbStack — avvia una VM Linux sotto un hypervisor e fa funzionare il demone al suo interno. Quella VM è una tassa che paghi tutto il giorno. dd la elimina: un container è un normale processo macOS le cui chiamate di sistema vengono servite da un kernel Linux in spazio utente.

Il vantaggio è strutturale: il calcolo dell'ospite viene eseguito come istruzioni native Apple Silicon (nessun layer di virtualizzazione hardware nel percorso critico), e il famigerato collo di bottiglia della condivisione file di Docker Desktop — il ponte virtiofs/FUSE tra macOS e la VM — semplicemente non esiste, perché il VFS di dd è il filesystem host dietro un path jail.

Compromesso onesto: un kernel in spazio utente è completo solo quanto le chiamate di sistema che implementa, e oggi Per impostazione predefinita, l'ospite viene eseguito in un processo — veloce, e la scelta giusta per codice di cui ti fidi (il tuo ambiente di sviluppo, CI, i tuoi strumenti). Per codice non fidato ora c'è una scissione sentry opzionale (DDJIT_UNTRUSTED): l'ospite viene eseguito in un sandbox Seatbelt con negazione predefinita senza autorità di filesystem/rete, mentre un processo sentry fidato possiede le risorse reali e serve le chiamate di sistema tramite un anello di memoria condivisa — la forma gVisor. È presto (le chiamate di sistema principali per file — read/write/open/close/lseek — vengono inoltrate oggi; socket/exec/fork stanno arrivando), quindi per codice completamente ostile una VM espone ancora una superficie più ristretta.

Prestazioni

Lo stesso binario Linux statico, eseguito in due modi su un Apple M5 Pro (macOS 26.3): dentro la VM Linux (come Docker basato su VM esegue i container) vs. tramite il JIT di dd sull'host con nessuna VM. Mediana di 7 (make bench). Tempo minore è migliore; "dd vs VM" > 1× significa dd è più veloce. La corsia dd paga persino un piccolo costo di ponte cross-process che l'app reale non paga — quindi questi sono conservativi.

Container x86-64 — dd vs emulazione VM (qemu-user; eseguire x86 su Apple Silicon significa tradurlo in ogni caso). Il JIT di dd batte qemu in 9 su 10 carichi di lavoro, in modo drammatico sulla virgola mobile:

Container aarch64 — dd vs una VM nativa (la VM esegue arm64 a piena velocità nativa — la barra più difficile):

dd esegue il calcolo arm64 a velocità nativa — in testa su int sieve + mandelbrot, in parità su SHA-256, matmul, memcpy, n-body e base64. I rimanenti gap sono lavori con molti branch indiretti/chiamate di sistema — qsort (~1.3×), text-scan (~1.35×) e SQLite (~1.5×) — ridotti nettamente dalle ultime ottimizzazioni (§B-off + x16/x17 rubati hanno portato SQLite da ~1.9× a ~1.5×). Chiudere il resto (dispatch VDBE) è la frontiera attiva; vedi docs/design/arm-sqlite-parity.md. (Ogni carico di lavoro è dimensionato per funzionare ≥0.45s, quindi il piccolo costo di ponte per esecuzione del test è trascurabile qui.)

Questi sono micro-benchmark di calcolo — non catturano nemmeno i vantaggi strutturali di dd (nessuna VM da avviare, nessuna RAM residente, I/O diretto sul filesystem host). Tutti i numeri misurati, mediana di 7. Riproduci: make bench.

L'obiettivo è battere la VM su ogni benchmark. dd vince già ogni carico di lavoro x86-64 sopra e eguaglia o batte arm64 nativo; dove è ancora indietro — SQLite arm64 pesante in chiamate di sistema/allocazioni, e spremere di più dal traduttore x86 — è esattamente la frontiera dell'ottimizzazione (l'ottimizzatore di tracce di livello 2 e il lavoro sulle prestazioni di jit86). Parità o meglio ovunque è il traguardo.

Come funziona

dd esegue un container Linux essendo il suo kernel nello spazio utente. Un JIT traduce il codice macchina dell'ospite e intercetta ogni istruzione di chiamata di sistema; il gestore di intercettazione — service() in dd-jit/src/runtime/os/linux/ — è l'ABI delle chiamate di sistema di Linux, implementata verso l'host macOS.

1. Carica l'ELF ospite (static-PIE, o dinamico tramite il suo ld.so) e costruisce lo stack iniziale.
2. Traduce e spedisce il PC ospite blocco per blocco; il codice con la stessa ISA è per lo più traslitterato, x86-64 viene decodificato e riemesso su arm64.
3. Esegue il blocco tradotto come codice host nativo fino a un terminatore (branch / salto indiretto / chiamata di sistema).
4. Gestisce la chiamata di sistema — ogni percorso passa attraverso il VFS jail del container; namespace e cgroup sono solo stato del processo.

Esempi

# 1. Start the daemon, point docker at it
make jit
DD_IMAGES=/path/to/images cargo run -p dd-daemon
export DOCKER_HOST=unix://$PWD/dd.sock

# 2. It's just 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. Or via the installed desktop app (per-user, no root)
dd install                                  # LaunchAgent + docker context
dd app                                       # open the GUI
docker --context dd run alpine echo hi

Installa

dd è pensato per macOS con Apple Silicon (arm64, macOS 12+). Il JIT necessita degli Xcode Command Line Tools (clang + codesign).

Scarica l'app (consigliato)

Prendi l'ultimo .dmg dalla pagina delle release, aprilo e trascina dd in Applicazioni. Poi in un terminale:

dd install     # ~/.dd tree + per-user LaunchAgent + `docker context create dd`
dd app         # open the GUI
dd doctor      # check socket / agent / context / app quarantine

Gatekeeper: il DMG non è firmato (ad-hoc). Al primo avvio, fai clic destro sull'app → Apri, oppure esegui xattr -dr com.apple.quarantine /Applications/dd-app.app (dd doctor rileva questo e stampa la correzione).

Compila da sorgente

xcode-select --install                       # clang + codesign
# install Rust (stable) and Nix (for the GTK4 dev shell)
git clone https://github.com/ricccrd/dd && cd dd
make app       # build + assemble & ad-hoc-sign target/dd-app.app
make dmg       # -> target/dist/dd-<ver>-<arch>.dmg
make install   # copy to /Applications and run `dd install`

make app/dmg eseguono il bundling all'interno del guscio di sviluppo Nix (nix/flake.nix), che fornisce GTK4 + dylibbundler / create-dmg. Il bundle sposta il grafico dylib GTK in Contents/Frameworks, prepara i dati runtime GTK e firma ad-hoc dall'interno verso l'esterno.

Area di lavoro

Un workspace Cargo.

• dd-jit/ — il runtime JIT (C, sotto src/runtime/) più i suoi binding Rust. build.rs compila e firma con codice un binario JIT per architettura ospite (aarch64, x86_64); src/lib.rs espone Guest + il contratto di lancio tipizzato SpawnConfig. L'ospite aarch64 è completamente scomposto (motore jit/ + personalità os/linux/ + frontend aarch64/); l'ospite x86-64 (jit86) condivide il layer os/linux/.
• dd-daemon/ — il demone dell'API Docker Engine. Rileva l'architettura ospite di ogni immagine dal suo ELF, sceglie il JIT corrispondente e lo lancia tramite .

Il demone ascolta su ~/.dd/run/docker.sock; sia la GUI che docker --context dd lo usano. Lo stato persiste in ~/.dd/state.json.

Test

make test                       # the engine × case matrix, grouped report
make test ENGINE=x86_64         # one engine
make test FILTER=container      # one group / cases matching a name
cargo run -p dd-tests -- --list # list groups + cases
make test-ci                    # the cargo-test path (CI)

I casi sono dichiarati in dd-tests/src/cases/. Un caso è un programma ospite + asserzioni; gli ospiti aarch64 vengono compilati al volo (gcc -static-pie) e confrontati con un oracolo nativo, gli ospiti x86-64 provengono da fixture precompilate. Ogni caso viene eseguito su ogni motore per cui ha un ospite.

Stato

• Ospite: Linux aarch64 (scomposto, motore container completo) + x86-64 (jit86, esegue glibc).
• Host: macOS arm64 (Apple Silicon). Il JIT necessita di clang + codesign (Xcode CLT).
• Container: rootfs + layer di immagini overlay (copy-up/whiteout), volumi bind, pubblicazione porte (-p), netns di loopback privata, limiti cgroup memoria+pids, namespace UTS/PID/USER.
• Roadmap: pull/unpack del registro OCI, deduplicazione jit86 sul motore condiviso, uno stack di rete esterno completo, e la scissione sentry per immagini non fidate. Vedi docs/ per le descrizioni dettagliate.

Autore

Richard Hutta — [email protected]

Licenza

MIT.