Trade-off Emulasi Binary ELF di macOS: User-Space vs Virtual Machine

Menjalankan binary Linux Executable and Linkable Format (ELF) secara langsung di macOS Apple Silicon menghadapi batasan fundamental arsitektur kernel: kernel XNU macOS menggunakan format Mach-O dan mengimplementasikan antarmuka syscall BSD/Mach, bukan Linux kernel ABI. Pengembang harus memilih antara melakukan translasi instruksi dan syscall di tingkat user-space atau menjalankan guest kernel Linux utuh di dalam Virtual Machine (VM).

Arsitektur User-Space Emulation vs Hardware-Assisted Virtualization

Dua metode utama memiliki mekanisme translasi dan boundary isolasi yang sangat berbeda:

• User-Space Syscall Translation: Runtime loader memuat segmen binary ELF langsung ke address space proses macOS, kemudian mencegat setiap instruksi syscall Linux (seperti svc #0 pada ARM64) dan memetakannya secara manual ke Mach trap atau wrapper libSystem. Jika arsitekturnya x86-64, runtime ini juga membutuhkan dynamic binary translation (DBT) seperti Rosetta 2 atau QEMU user-mode.
• Virtual Machine (Type-2 Hypervisor): Memanfaatkan Apple Hypervisor.framework (HVF) untuk menginisialisasi Virtual CPU (vCPU) berbasis ekstensi hardware ARM Virtualization (VT). Binary ELF berjalan di atas guest kernel Linux native yang menangani syscall secara langsung tanpa translasi software layer per-call. Solusi tooling modern mencakup Apple Virtualization.framework, microVM (seperti Firecracker atau Tart), Lima, dan Docker Desktop.

Mekanisme Intersepsi Syscall pada User-Space

Pada pendekatan user-space, dynamic linker kustom memetakan binary ELF dan intercept syscall melalui sinyal sistem atau ptrace-like handling:

// Konsep dasar dispatch syscall Linux ke POSIX/XNU di user-space
long dispatch_linux_syscall(long syscall_nr, long arg1, long arg2, long arg3) {
    switch (syscall_nr) {
        case 56: // __NR_openat pada Linux ARM64
            // Translasi flag Linux (O_LARGEFILE, dll) ke BSD/macOS open flags
            return xnu_openat_compat((int)arg1, (const char *)arg2, (int)arg3);
        case 222: // __NR_mmap
            // Tangani perbedaan alokasi memory page size (Linux 4KB vs Apple Silicon 16KB)
            return xnu_mmap_compat((void *)arg1, (size_t)arg2, (int)arg3);
        default:
            // Syscall tidak diimplementasikan
            return -ENOSYS;
    }
}

Tantangan Teknis: ABI Kernel, glibc, dan Page Size

Pendekatan user-space translation menghadapi rintangan kompatibilitas mendalam:

• Perbedaan Memory Page Size: Apple Silicon beroperasi secara default pada ukuran halaman memori 16KB (ARM64_64), sementara mayoritas binary ELF Linux dikompilasi dengan asumsi 4KB page size. Binary yang mengeksekusi mmap dengan alignment 4KB akan gagal jika memory subsystem runtime tidak memetakan ulang fragmentasi virtual memory secara virtual.
• Semantik Kernel Khusus Linux: Sejumlah interface Linux modern tidak memiliki padanan one-to-one di kernel XNU macOS. Contoh: io_uring, epoll (harus ditranslasikan ke kqueue yang memiliki model event berbeda), cgroups, dan flag clone khusus Linux (CLONE_NEWPID, CLONE_NEWNS).
• Thread-Local Storage (TLS) Register: Linux ARM64 menggunakan register TPIDR_EL0 untuk TLS. Kernel macOS mengatur dan membatasi register ini secara berbeda melalui thread_set_state, mengharuskan runtime user-space mengelola switching konteks register secara manual.

Perbandingan Trade-off Arsitektur

Pertimbangan Biaya, Resource, dan Maintainability

Memilih antara kedua pendekatan ini berdampak pada biaya operasional tim teknik:

• Maintenance Burden User-Space: Runtime user-space translation memerlukan pemeliharaan terus-menerus terhadap Linux ABI drift. Setiap kali binary bergantung pada syscall kernel Linux versi terbaru, runtime harus diperbarui secara manual. Pendekatan ini hanya cocok untuk execution tooling command-line sederhana (CLI compiler, standalone utility).
• Biaya Lisensi dan Resource Tim: Penggunaan VM standar seperti Docker Desktop sering kali memicu kewajiban lisensi berbayar pada skala enterprise, serta mengonsumsi alokasi baterai dan CPU idle untuk background guest OS. Penggunaan alternatif berbasis open-source seperti Lima, Colima, atau microVM kustom berbasis Apple Virtualization.framework memberikan efisiensi tanpa overhead lisensi.

Panduan Pengambilan Keputusan

Pilih User-Space Emulation jika sistem membutuhkan cold-start instan, footprint memori minimal, dan binary yang dijalankan hanyalah tool kompilasi atau CLI mandiri yang tidak bergantung pada fitur spesifik kernel Linux.

Pilih Virtual Machine / microVM jika binary membutuhkan ekosistem container (Docker/Podman), soket IPC Linux spesifik, thread tracing (eBPF), atau library kompleks dengan dependensi kernel Linux modern.