dd

Execute containers Linux no macOS — sem VM.

O que é o dd?

dd executa containers Linux nativamente no macOS Apple Silicon sem máquina virtual. Não há kernel Linux nem hipervisor subjacente: um JIT traduz o código do container e trata suas chamadas de sistema Linux em espaço de usuário (linhagem gVisor / PRoot). O JIT é o kernel Linux convidado — namespaces, cgroups, camadas de imagem overlay e rede são mantidos como estado de espaço de usuário. Ele fala a API do Docker Engine, então o CLI comum docker o utiliza.

A computação do container é executada como instruções nativas Apple Silicon; apenas suas chamadas de sistema são interpretadas. Sem VM para iniciar, sem daemon dentro de uma VM, sem custo de virtualização.

Site e documentação: https://ricccrd.github.io/dd/

make jit                                          # build.rs compila + codesign os JITs
DD_IMAGES=/caminho/para/imagens cargo run -p dd-daemon  # inicia o daemon
export DOCKER_HOST=unix://$PWD/dd.sock
docker run -p 8080:80 -m 256m alpine sh -c 'echo hi from $(hostname)'

Funcionalidades

• Sem máquina virtual. Sem hipervisor, sem kernel Linux, sem VM residente. As instruções do convidado rodam nativamente em arm64; apenas a fronteira de chamadas de sistema é interceptada e tratada em espaço de usuário.
• Docker plug-and-play. dd implementa a API do Docker Engine. Aponte DOCKER_HOST para seu socket e seus comandos docker run / ps / images / build existentes funcionam sem alterações.
• O JIT é o kernel. Namespaces, cgroups, camadas de imagem overlay e rede são estado comum de espaço de usuário — um kernel de espaço de usuário na linhagem gVisor / PRoot, sem nenhum custo de VM.
• Três runtimes convidados, um mecanismo. Imagens Linux arm64 nativas; imagens Linux x86-64 via um JIT (jit86) que decodifica x86, sintetiza suas flags e reduz SSE/x87 para NEON (binários glibc funcionam); e convidados arm64 do macOS (ddcli mac) — sem VM em nenhum deles.
• Isolamento real de container. Camadas de imagem overlay (copy-up / .wh. whiteout, getdents mesclado), um VFS de confinamento de caminho livre de TOCTOU, namespaces PID / UTS / USER, uma netns loopback privada com publicação de porta -p e limites de memória + pids via cgroup (OOM no limite).
• Aplicativo desktop, sem root. Um aplicativo GTK4 nativo (dd-app) mais um CLI dd instalam um daemon de fundo por usuário e um — tudo em , nunca .

Por que um JIT, e não uma VM?

Qualquer outra forma de executar containers Linux em um Mac — Docker Desktop, Colima, Rancher, OrbStack — inicializa uma VM Linux sob um hipervisor e roda o daemon dentro dela. Essa VM é um imposto que você paga o dia todo. dd a elimina: um container é um processo macOS comum cujas chamadas de sistema são tratadas por um kernel Linux em espaço de usuário.

A vantagem é estrutural: a computação do convidado roda como instruções nativas Apple Silicon (sem camada de virtualização de hardware no caminho crítico), e o notório gargalo de compartilhamento de arquivos do Docker Desktop — a ponte virtiofs/FUSE entre macOS e a VM — simplesmente não existe, pois o VFS do dd é o sistema de arquivos do host protegido por um confinamento de caminho.

Compensação honesta: um kernel em espaço de usuário é tão completo quanto as chamadas de sistema que implementa, e hoje por padrão o convidado roda em um processo — rápido, e a decisão certa para código em que você confia (seu ambiente de desenvolvimento, CI, suas próprias ferramentas). Para código não confiável, há agora uma divisão sentry opcional (DDJIT_UNTRUSTED): o convidado roda em um sandbox Seatbelt com negação padrão, sem autoridade de fs/rede do host, enquanto um processo sentry confiável possui os recursos reais e atende chamadas de sistema através de um anel de memória compartilhada — a forma gVisor. É cedo (as chamadas de sistema de arquivos principais — read/write/open/close/lseek — são encaminhadas hoje; sockets/exec/fork estão chegando), então para código totalmente hostil uma VM ainda expõe uma superfície mais estreita.

Desempenho

O mesmo binário Linux estático, executado de duas formas em um Apple M5 Pro (macOS 26.3): dentro da VM Linux (como o Docker baseado em VM executa containers) vs. através do JIT do dd no host sem VM. Mediana de 7 execuções (make bench). Menor tempo é melhor; "dd vs VM" > 1× significa que dd é mais rápido. A faixa do dd ainda paga um pequeno imposto de ponte entre processos que o aplicativo real não paga — portanto, estes são conservadores.

Containers x86-64 — dd vs emulação de VM (qemu-user; executar x86 no Apple Silicon significa traduzir de qualquer forma). O JIT do dd supera o qemu em 9 de 10 cargas de trabalho, dramaticamente em ponto flutuante:

Containers aarch64 — dd vs uma VM nativa (a VM executa arm64 em velocidade nativa máxima — a barra mais difícil):

dd executa a computação arm64 em velocidade nativa — à frente em int sieve + mandelbrot, em paridade em SHA-256, matmul, memcpy, n-body e base64. As lacunas restantes são trabalhos com muitos desvios indiretos / chamadas de sistema — qsort (~1,3×), text-scan (~1,35×) e SQLite (~1,5×) — reduzidas acentuadamente pelas passagens mais recentes (§B-off + x16/x17 roubado levou o SQLite de ~1,9× para ~1,5×). Fechar o resto (despacho VDBE) é a fronteira ativa; veja docs/design/arm-sqlite-parity.md. (Cada carga de trabalho tem tamanho para executar ≥0,45s, então o pequeno imposto de ponte por execução da estrutura é desprezível aqui.)

Estes são micro-benchmarks de computação — eles nem capturam as vantagens estruturais do dd (sem VM para iniciar, sem RAM residente, I/O direto ao sistema de arquivos do host). Todos os números medidos, mediana de 7. Reproduza: make bench.

O objetivo é superar a VM em todos os benchmarks. dd já vence todas as cargas de trabalho x86-64 acima e iguala ou supera arm64 nativo; onde ainda está atrás — SQLite arm64 pesado em chamadas de sistema/alocação, e extrair mais do tradutor x86 — é exatamente a fronteira de otimização (otimizador de rastreamento de nível 2 e trabalho de desempenho jit86). Paridade ou melhor em todos os lugares é o padrão.

Como funciona

dd executa um container Linux sendo seu kernel em espaço de usuário. Um JIT traduz o código de máquina do convidado e intercepta toda instrução de chamada de sistema; o manipulador de interrupção — service() em dd-jit/src/runtime/os/linux/ — é a ABI de chamada de sistema Linux, implementada contra o host macOS.

1. Carregar o ELF convidado (static-PIE, ou dinâmico via seu ld.so) e construir a pilha inicial.
2. Traduzir e despachar o PC convidado bloco a bloco; código de mesma ISA é principalmente transliterado, x86-64 é decodificado e reemitido em arm64.
3. Executar o bloco traduzido como código nativo do host até um terminador (branch / salto indireto / chamada de sistema).
4. Atender a chamada de sistema — cada caminho passa pelo confinamento VFS do container; namespaces e cgroups são apenas estado do processo.

Exemplos

# 1. Inicie o daemon, aponte o docker para ele
make jit
DD_IMAGES=/caminho/para/imagens cargo run -p dd-daemon
export DOCKER_HOST=unix://$PWD/dd.sock

# 2. É apenas 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. Ou através do aplicativo desktop instalado (por usuário, sem root)
dd install                                  # LaunchAgent + contexto docker
dd app                                       # abre a GUI
docker --context dd run alpine echo hi

Instalação

O dd tem como alvo macOS Apple Silicon (arm64, macOS 12+). O JIT precisa das Ferramentas de Linha de Comando do Xcode (clang + codesign).

Baixe o aplicativo (recomendado)

Pegue o .dmg mais recente na página de releases, abra-o e arraste dd para Aplicativos. Depois, em um terminal:

dd install     # árvore ~/.dd + LaunchAgent por usuário + `docker context create dd`
dd app         # abre a GUI
dd doctor      # verifica socket / agente / contexto / quarentena do app

Gatekeeper: o DMG não é assinado (ad-hoc). Na primeira execução, clique com o botão direito no aplicativo → Abrir, ou execute xattr -dr com.apple.quarantine /Applications/dd-app.app (dd doctor detecta isso e exibe a correção).

Compile a partir do código fonte

xcode-select --install                       # clang + codesign
# instale Rust (estável) e Nix (para o shell de desenvolvimento GTK4)
git clone https://github.com/ricccrd/dd && cd dd
make app       # compila + monta e assina ad-hoc target/dd-app.app
make dmg       # -> target/dist/dd-<ver>-<arch>.dmg
make install   # copia para /Applications e executa `dd install`

make app/dmg executam o empacotamento dentro do shell de desenvolvimento Nix (nix/flake.nix), que fornece GTK4 + dylibbundler / create-dmg. O pacote reloca o grafo de dylibs do GTK para Contents/Frameworks, organiza os dados de runtime do GTK e assina ad-hoc de dentro para fora.

Workspace

Um workspace Cargo.

• dd-jit/ — o runtime JIT (C, em src/runtime/) mais suas ligações Rust. build.rs compila e codesigna um binário JIT por arquitetura convidada (aarch64, x86_64); src/lib.rs expõe Guest + o contrato de lançamento tipado SpawnConfig. O convidado aarch64 é totalmente decomposto (mecanismo jit/ + personalidade os/linux/ + frontend frontend/aarch64/); o convidado x86-64 (jit86) compartilha a camada os/linux/.
• dd-daemon/ — o daemon da API Docker Engine. Detecta a arquitetura convidada de cada imagem a partir de seu ELF, escolhe o JIT correspondente e o lança via .

O daemon escuta em ~/.dd/run/docker.sock; tanto a GUI quanto docker --context dd o utilizam. O estado persiste em ~/.dd/state.json.

Testes

make test                       # matriz mecanismo × caso, relatório agrupado
make test ENGINE=x86_64         # um mecanismo
make test FILTER=container      # um grupo / casos que correspondem a um nome
cargo run -p dd-tests -- --list # lista grupos + casos
make test-ci                    # o caminho cargo-test (CI)

Os casos são declarados em dd-tests/src/cases/. Um caso é um programa convidado + asserções; convidados aarch64 são compilados dinamicamente (gcc -static-pie) e comparados com um oráculo nativo, convidados x86-64 vêm de fixtures pré-construídas. Cada caso é executado em cada mecanismo para o qual possui um convidado.

Status

• Convidado: Linux aarch64 (decomposto, mecanismo de container completo) + x86-64 (jit86, executa glibc).
• Host: macOS arm64 (Apple Silicon). O JIT precisa de clang + codesign (Xcode CLT).
• Containers: rootfs + camadas de imagem overlay (copy-up/whiteout), volumes bind, publicação de porta (-p), netns loopback privada, limites de memória+pids via cgroup, namespaces UTS/PID/USER.
• Roadmap: pull/desempacotamento de registro OCI, dedução do jit86 no mecanismo compartilhado, uma pilha de rede externa completa e a divisão sentry para imagens não confiáveis. Veja docs/ para as descrições detalhadas.

Autor

Richard Hutta — [email protected]

Licença

MIT.