dd

Запуск контейнеров Linux на macOS без виртуальной машины.

Что такое dd?

dd запускает контейнеры Linux нативно на macOS с Apple Silicon без виртуальной машины. Нет ядра Linux и нет гипервизора под капотом: JIT транслирует код контейнера и обрабатывает его системные вызовы Linux в пользовательском пространстве (линия gVisor / PRoot). JIT является ядром Linux для гостя — пространства имён, cgroups, слои оверлейных образов и сеть поддерживаются как состояние пользовательского пространства. Он говорит на Docker Engine API, так что обычный CLI docker управляет им.

Вычисления контейнера выполняются как нативные инструкции Apple Silicon; только его системные вызовы интерпретируются. Нет VM для загрузки, нет демона-в-VM, нет затрат на виртуализацию.

Сайт и документация: https://ricccrd.github.io/dd/

make jit                                          # build.rs компилирует и подписывает JIT
DD_IMAGES=/path/to/images cargo run -p dd-daemon  # запуск демона
export DOCKER_HOST=unix://$PWD/dd.sock
docker run -p 8080:80 -m 256m alpine sh -c 'echo hi from $(hostname)'

Возможности

• Нет виртуальной машины. Нет гипервизора, нет ядра Linux, нет VM, которая постоянно занимает память. Инструкции гостя выполняются нативно на arm64; только граница системных вызовов перехватывается и обслуживается в пользовательском пространстве.
• Docker «из коробки». dd реализует Docker Engine API. Укажите DOCKER_HOST на его сокет, и ваши существующие команды docker run / ps / images / build будут работать без изменений.
• JIT — это ядро. Пространства имён, cgroups, слои оверлейных образов и сеть — обычное состояние пользовательского пространства — ядро в пользовательском пространстве в духе gVisor / PRoot, без затрат VM.
• Три рантайма гостя, один движок. Нативные образы Linux arm64; образы Linux x86-64 через JIT (jit86), который декодирует x86, синтезирует флаги и снижает SSE/x87 на NEON (бинарники glibc работают); и гости macOS arm64 (ddcli mac) — ни в одном из них нет VM.
• Реальная изоляция контейнеров. Оверлейные слои образов (copy-up / .wh. whiteout, объединённые getdents), VFS с изоляцией путей без TOCTOU, пространства имён PID / UTS / USER, частная loopback netns с публикацией портов -p и ограничения памяти + процессов через cgroups (OOM при достижении лимита).
• Десктопное приложение, без прав root. Нативное приложение GTK4 (dd-app) и CLI dd устанавливают фоновый демон для каждого пользователя и — всё работает из , никогда не требуется .

Почему JIT, а не VM?

Любой другой способ запуска контейнеров Linux на Mac — Docker Desktop, Colima, Rancher, OrbStack — загружает Linux VM под гипервизором и запускает демон внутри неё. Эту VM вы оплачиваете весь день. dd избавляется от неё: контейнер — обычный процесс macOS, чьи системные вызовы обслуживаются ядром Linux в пользовательском пространстве.

Выигрыш структурный: вычисления гостя выполняются как нативные инструкции Apple Silicon (нет слоя аппаратной виртуализации на горячем пути), а пресловутое узкое место общего доступа к файлам Docker Desktop — мост virtiofs/FUSE между macOS и VM — просто не существует, потому что VFS dd является файловой системой хоста за изоляцией путей.

Честный компромисс: ядро в пользовательском пространстве настолько полно, насколько реализованы системные вызовы, и сегодня по умолчанию гость работает в одном процессе — это быстро и правильно для кода, которому вы доверяете (ваше окружение разработки, CI, ваши собственные инструменты). Для недоверенного кода теперь существует опциональный разделённый sentry (DDJIT_UNTRUSTED): гость работает в песочнице Seatbelt с запретами по умолчанию, не имея полномочий на файловую систему/сеть хоста, а доверенный процесс sentry владеет реальными ресурсами и обслуживает системные вызовы через кольцо разделяемой памяти — форма gVisor. Это рано (основные системные вызовы для файлов — read/write/open/close/lseek — уже работают; сокеты/exec/fork внедряются), так что для полностью враждебного кода VM всё ещё предоставляет меньшую поверхность атаки.

Производительность

Один и тот же статический бинарник Linux, запущенный двумя способами на Apple M5 Pro (macOS 26.3): внутри Linux VM (как VM-основанные Docker запускают контейнеры) и через JIT dd на хосте без VM. Медиана из 7 замеров (make bench). Меньшее время лучше; «dd vs VM» > 1× означает, что dd быстрее. Замеры dd дополнительно платят небольшой налог на межпроцессное взаимодействие, которого нет у реального приложения — так что эти цифры консервативны.

Контейнеры x86-64 — dd vs эмуляция VM (qemu-user; запуск x86 на Apple Silicon означает трансляцию в любом случае). JIT dd побеждает qemu на 9 из 10 нагрузок, особенно в вычислениях с плавающей точкой:

Контейнеры aarch64 — dd vs нативная VM (VM запускает arm64 на полной нативной скорости — самый сложный барьер):

dd выполняет вычисления arm64 на нативной скорости — опережает int sieve + mandelbrot, на паритете SHA-256, matmul, memcpy, n-body и base64. Оставшиеся отставания — тяжёлые на непрямые переходы / системные вызовы — qsort (~1.3×), text-scan (~1.35×) и SQLite (~1.5×) — были значительно сокращены последними проходами (§B-off + stolen x16/x17 улучшили SQLite с ~1.9× до ~1.5×). Закрытие остатка (диспетчеризация VDBE) — активный фронт; см. docs/design/arm-sqlite-parity.md. (Каждая нагрузка настроена на выполнение ≥0.45s, так что небольшой налог на мост между запусками здесь незначителен.)

Это вычислительные микро-бенчмарки — они даже не учитывают структурных преимуществ dd (нет загрузки VM, нет занимаемой RAM, прямой ввод-вывод к файловой системе хоста). Все цифры измерены, медиана из 7. Воспроизвести: make bench.

Цель — обогнать VM на каждом бенчмарке. dd уже побеждает во всех нагрузках x86-64 выше и сравнивается или обгоняет нативный arm64; там, где он всё ещё отстаёт — тяжёлый на системные вызовы/выделение памяти arm64 SQLite и выжимание большего из транслятора x86 — это и есть фронт оптимизации (оптимизатор трасс второго уровня и работа над производительностью jit86). Паритет или лучше везде — планка.

Как это работает

dd запускает контейнер Linux, являясь его ядром в пользовательском пространстве. JIT транслирует машинный код гостя и перехватывает каждую инструкцию системного вызова; обработчик перехвата — service() в dd-jit/src/runtime/os/linux/ — является ABI системных вызовов Linux, реализованный поверх хоста macOS.

1. Загрузка гостевого ELF (статический-PIE, или динамический через его ld.so) и построение начального стека.
2. Трансляция и диспетчеризация гостевого PC блоками; код той же ISA большей частью транслитерируется, x86-64 декодируется и переиздаётся на arm64.
3. Выполнение транслированного блока как нативного кода хоста до терминатора (ветвление / непрямой переход / системный вызов).
4. Обслуживание системного вызова — каждый путь проходит через изоляцию путей VFS контейнера; пространства имён и cgroups — это просто состояние процесса.

Примеры

# 1. Запустить демон, указать docker на него
make jit
DD_IMAGES=/path/to/images cargo run -p dd-daemon
export DOCKER_HOST=unix://$PWD/dd.sock

# 2. Это просто 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. Или через установленное десктопное приложение (для пользователя, без root)
dd install                                  # LaunchAgent + docker context
dd app                                       # открыть GUI
docker --context dd run alpine echo hi

Установка

dd предназначен для macOS на Apple Silicon (arm64, macOS 12+). JIT требует инструментов командной строки Xcode (clang + codesign).

Скачать приложение (рекомендуется)

Загрузите последний .dmg со страницы релизов, откройте его и перетащите dd в папку Программы. Затем в терминале:

dd install     # ~/.dd дерево + per-user LaunchAgent + `docker context create dd`
dd app         # открыть GUI
dd doctor      # проверить сокет / агент / контекст / карантин приложения

Gatekeeper: DMG не подписан (ad-hoc). При первом запуске нажмите правой кнопкой мыши на приложение → Открыть, или выполните xattr -dr com.apple.quarantine /Applications/dd-app.app (dd doctor обнаружит это и покажет исправление).

Сборка из исходников

xcode-select --install                       # clang + codesign
# установить Rust (stable) и Nix (для оболочки разработки GTK4)
git clone https://github.com/ricccrd/dd && cd dd
make app       # сборка + компоновка и ad-hoc-подпись target/dd-app.app
make dmg       # -> target/dist/dd-<ver>-<arch>.dmg
make install   # скопировать в /Applications и запустить `dd install`

make app/dmg выполняют упаковку внутри оболочки разработки Nix (nix/flake.nix), которая предоставляет GTK4 + dylibbundler / create-dmg. Пакет перемещает граф dylib GTK4 в Contents/Frameworks, размещает данные времени выполнения GTK4 и подписывает ad-hoc от внутреннего к внешнему.

Пространство проекта

Рабочее пространство Cargo.

• dd-jit/ — среда выполнения JIT (C, в src/runtime/) плюс его привязки к Rust. build.rs компилирует и подписывает один JIT-бинарник на гостевую архитектуру (aarch64, x86_64); src/lib.rs предоставляет Guest + типизированный контракт запуска SpawnConfig. Гость aarch64 полностью декомпозирован (движок jit/ + персона os/linux/ + фронтенд frontend/aarch64/); гость x86-64 (jit86) использует общий слой os/linux/.
• dd-daemon/ — демон Docker Engine API. Определяет архитектуру гостя из его ELF, выбирает соответствующий JIT и запускает его через .

Демон слушает на ~/.dd/run/docker.sock; и GUI, и docker --context dd используют его. Состояние сохраняется в ~/.dd/state.json.

Тестирование

make test                       # матрица движков × сценариев, группированный отчёт
make test ENGINE=x86_64         # один движок
make test FILTER=container      # одна группа / сценарии, совпадающие по имени
cargo run -p dd-tests -- --list # список групп + сценариев
make test-ci                    # путь cargo-test (CI)

Сценарии объявлены в dd-tests/src/cases/. Сценарий — это гостевая программа + утверждения; гости aarch64 компилируются на лету (gcc -static-pie) и сравниваются с нативным оракулом, гости x86-64 берутся из предварительно собранных фикстур. Каждый сценарий выполняется на каждом движке, для которого у него есть гость.

Статус

• Гость: Linux aarch64 (декомпозирован, полный движок контейнеров) + x86-64 (jit86, запускает glibc).
• Хост: macOS arm64 (Apple Silicon). JIT требует clang + codesign (Xcode CLT).
• Контейнеры: rootfs + оверлейные слои образов (copy-up/whiteout), bind-тома, публикация портов (-p), частная loopback netns, ограничения cgroups памяти и процессов, пространства имён UTS/PID/USER.
• План: загрузка/распаковка из OCI-реестра, перенос jit86 на общий движок, полный внешний сетевой стек и разделение sentry для недоверенных образов. См. docs/ для подробного описания.

Автор

Richard Hutta — [email protected]

Лицензия

MIT.