macOS-бинари на Linux ARM64 без эмуляции: проект Kakehashi
Sh0ny
3 августа 20261 мин чтения
Коротко
Kakehashi запускает Mach-O исполняемые файлы macOS на Linux ARM64 нативно — без JIT и эмуляции процессора, только подмена системных вызовов. Подход работает для утилит командной строки, и инженерный принцип за ним интереснее результата.
Проект Kakehashi делает то, что на первый взгляд звучит как эмуляция, но по факту ей не является. Он запускает исполняемые файлы macOS в формате Mach-O, собранные под ARM64, на Linux-системах с той же архитектурой процессора. Никакого JIT-компиляции, никакой эмуляции инструкций — код выполняется нативно. Вся работа сводится к подмене системных вызовов для libSystem и обработке исключений.
Это возможнj именно потому, что Apple Silicon и типичный Linux ARM64 — одна и та же ISA. Процессор понимает одни и те же инструкции; разница между macOS и Linux для пользовательского бинарника лежит не в CPU, а в интерфейсе ядра. Kakehashi не переводит машинный код — он переводит контекст вызовов, подменяя macOS-системный слой на Linux-эквиваленты.
В этом смысле проект ближе к Wine, чем к QEMU, но даже проще: Wine часто работает на чужой архитектуре и вынужден транслировать инструкции. Здесь этого слоя нет вообще. Накладные расходы — только на обработку syscall и исключений, что для утилит командной строки означает практически нативную скорость.
Ограничения тоже очевидны из формулировки. Цель проекта — запуск CLI-утилит, собранных для macOS, а не GUI-приложений. Для графического софта потребовалось бы эмулировать или портировать AppKit, CoreGraphics и весь стек фреймворков — это совсем другой масштаб работы. Текущий подход работает ровно потому, что CLI-утилитам нужен минимальный набор системных вызовов.
Реализация на Rust под лицензией Apache 2.0 — выбор, который делает проект удобным для встраивания в другие инструменты и дистрибутивы. Если у вас есть пайплайн, где часть скриптов собрана под macOS ARM64, а инфраструктура живёт на Linux ARM64, Kakehashi — кандидат на то, чтобы убрать один слой костылей.
Главный вопрос не в том, заработает ли он с вашей конкретной утилитой, а в том, как быстро сообщество дополнит недостающие syscall-обработчики. Проект молод, и покрытие системных вызовов — естественное узкое место для любого транслятора ABI.