macOS yang Berjalan dengan QEMU di Docker

 (github.com/sickcodes)
3 poin oleh GN⁺ 2024-08-01 | 1 komentar | Bagikan ke WhatsApp
  • Docker-OSX adalah proyek yang menjalankan macOS berbasis QEMU + KVM di dalam container Docker, menyediakan output X11, SSH, VNC, integrasi USB iPhone, serta pembuatan serial untuk riset keamanan iMessage
  • Cara menjalankannya menggunakan struktur yang meneruskan perangkat /dev/kvm, socket X11, port forwarding, dan variabel lingkungan SHORTNAME ke Docker untuk memilih versi macOS, dengan contoh dari Catalina 10.15 hingga Tahoe 16
  • Susunan image dibagi berdasarkan tujuan seperti latest, auto, naked, naked-auto, dan dapat memakai .img buatan sendiri atau menjalankan pekerjaan baris perintah dengan image Catalina yang sudah dikonfigurasi sebelumnya
  • Persyaratannya adalah host x86_64 yang mendukung KVM, virtualisasi BIOS aktif, ruang disk minimal 20GB, serta 50GB untuk penggunaan Xcode dan minimal 50GB saat memakai :auto
  • Selain Linux, ini juga dapat berjalan pada nested virtualization WSL2 di Windows 11 build 22000+, tetapi output layar memerlukan salah satu dari WSLg, VNC, atau desktop environment

Menjalankan macOS di dalam container Docker

  • Docker-OSX adalah proyek untuk menjalankan macOS di dalam container Docker
    • Berjalan di atas QEMU + KVM
    • Mendukung X11 forwarding
    • Menyediakan konfigurasi agar USB iPhone dapat berfungsi
    • Menjelaskan bahwa riset keamanan macOS dapat dilakukan di Linux dan Windows
  • Proyek ini dibuat di atas OSX-KVM, dan juga menyebut KVM-OpenCore, OpenCorePkg
  • Image Docker Hub juga tersedia: sickcodes/docker-osx

Versi macOS yang didukung dan cara menjalankan cepat

  • Quick Start memakai docker run dengan meneruskan elemen berikut
    • --device /dev/kvm
    • -p 50922:10022 untuk SSH
    • volume /tmp/.X11-unix untuk X11
    • DISPLAY
    • SHORTNAME untuk memilih versi macOS
  • Target yang disertakan dalam README adalah sebagai berikut

    • High Sierra 10.13

    • Mojave 10.14

    • Catalina 10.15

    • Big Sur 11

    • Monterey 12

    • Ventura 13

    • Sonoma 14

    • Sequoia 15

      • Tahoe 16
      • Beberapa contoh setelah Monterey juga memakai GENERATE_UNIQUE=true bersama MASTER_PLIST_URL
      • Contoh Sonoma, Sequoia, dan Tahoe juga menyertakan CPU='Haswell-noTSX' dan CPUID_FLAGS

Jenis image dan tujuan penggunaan

  • Docker-OSX menyediakan image container berdasarkan tujuan penggunaan
    • sickcodes/docker-osx:latest: untuk mencoba dengan cepat atau membuat image macOS sendiri
    • sickcodes/docker-osx:auto: memakai sistem Catalina yang sudah dikonfigurasi sebelumnya, dengan nama pengguna user dan kata sandi alpine
    • sickcodes/docker-osx:naked: menjalankan dengan menempelkan file .img milik pengguna
    • sickcodes/docker-osx:naked-auto: mengotomatisasi SSH dan eksekusi perintah dengan meneruskan USERNAME, PASSWORD, OSX_COMMANDS ke image pengguna
    • sickcodes/docker-osx:big-sur, :monterey, :ventura, :sonoma, :high-sierra, :mojave: untuk menjalankan versi tertentu
  • Image naked disesuaikan untuk alur boot berulang dari image disk yang sudah ada, atau mengembalikan container ke status sebelumnya
  • auto dan naked-auto dapat digunakan untuk pekerjaan berfokus command line atau pekerjaan headless seperti build berbasis Homebrew

Fitur utama

  • Fitur yang disebutkan oleh Docker-OSX adalah sebagai berikut
    • Penggunaan iPhone OSX KVM di Linux dengan usbfluxd
    • Menjalankan VM macOS Monterey
    • Berbagi folder
    • USB passthrough dan hotplug
    • SSH aktif di localhost:50922
    • VNC aktif di localhost:8888 saat memakai versi ./vnc
    • serial number generator untuk riset keamanan iMessage
    • X11 forwarding
    • Dukungan Big Sur, image kustom, dan mode headless Xvfb
    • Container dapat diduplikasi dengan docker commit
  • Kubernetes juga didukung, dan Helm Chart serta dokumentasi disebut berada di direktori helm

Persyaratan dan pengaturan awal

  • Persyaratan minimumnya adalah sebagai berikut
    • Ruang disk 20GB atau lebih
    • 50GB saat memakai Xcode
    • Minimal 50GB saat memakai :auto
    • Virtualisasi diaktifkan di BIOS
    • host x86_64 yang mendukung KVM
  • Pengaturan awal mengikuti alur memasang QEMU dan dependensi terkait di host, lalu mengaktifkan libvirtd, virtlogd, dan modul kernel KVM
  • Perintah pemasangan paket disediakan masing-masing untuk Arch, Ubuntu/Debian, dan CentOS/RHEL/Fedora
  • Dalam beberapa kasus pengguna harus masuk ke grup Docker, KVM, dan libvirt, serta memastikan daemon Docker sedang berjalan

Syarat menjalankan di Windows

  • Menjalankan Docker-OSX di Windows dimungkinkan pada lingkungan Windows 11 + WSL2
    • Diperlukan Windows 11 build 22000+, 21H2 atau lebih baru
    • Setelah memasang WSL, tambahkan nestedVirtualization=true ke .wslconfig
    • Di distribusi WSL, periksa ketersediaan /dev/kvm dan akselerasi KVM dengan kvm-ok
    • Di Docker for Windows, aktifkan engine berbasis WSL2 dan integrasi dengan distribusi WSL default
  • Metode output layar dibagi menjadi 3
    • WSLg: opsi paling sederhana dan direkomendasikan, tetapi mungkin ada masalah pengiriman keyboard atau tampilan mouse kedua
    • VNC: gunakan pengaturan QEMU VNC atau bagian VNC
    • Desktop Environment: memakai lebih banyak sumber daya tetapi memberikan pengalaman desktop Linux penuh

Berbagi file dan pengelolaan disk

  • sshfs disarankan sebagai cara berbagi yang paling mudah dan aman
    • Di Linux/Windows, rootfs macOS dapat di-mount ke ruang pengguna dengan bentuk sshfs user@localhost: -p 50922 ~/mnt/osx
  • QEMU 9p sharing juga bisa digunakan
    • Folder host diteruskan ke container sebagai /mnt/hostshare
    • Di dalam macOS, mount dengan sudo -S mount_9p hostshare
  • Berbagi lewat NFS juga dijelaskan
    • Daftarkan direktori berbagi host ke /etc/exports
    • Jalankan container Docker-OSX dengan --network host
    • Gunakan mount_nfs di terminal macOS
  • Jika ruang disk Docker tidak cukup, /var/lib/docker bisa dipindahkan ke drive eksternal, block storage, NFS, dan sebagainya, lalu dibuat symbolic link
    • Dijelaskan agar mengikuti tutorial terkait hanya jika siap menerima kemungkinan terhapusnya image dan layer Docker yang ada saat ini

USB iPhone dan USB passthrough

  • Untuk desktop PC, metode passthrough USB iPhone berbasis VFIO dijelaskan melalui tautan terpisah
  • Pada laptop, PC, dan perangkat lain, USB passthrough berbasis jaringan dapat digunakan lewat usbfluxd
    • Hubungkan iPhone atau iPad ke Linux lewat USB
    • Ekspos usbmuxd ke port TCP 5000
    • Di guest macOS, hubungkan ke host dengan bentuk usbfluxd -f -r 172.17.0.1:5000
    • Dijelaskan bahwa perangkat akan muncul setelah aplikasi seperti Xcode ditutup lalu dibuka kembali
  • USB passthrough umum dijelaskan memerlukan QEMU dijalankan sebagai root
    • Periksa bus dan port dengan lsusb -t
    • Gunakan --privileged, /dev/kvm, EXTRA="-device ... usb-host ...", dan sebagainya
    • Saat VM berjalan, sistem host tidak dapat mengakses perangkat USB tersebut

Headless, VNC, SPICE, dan eksekusi jarak jauh

  • Menjalankan secara headless dilakukan dengan menghapus dua baris terkait X11 dari docker run
    • Hapus volume /tmp/.X11-unix
    • Hapus variabel lingkungan DISPLAY
  • Container headless berbasis image kustom dijelaskan berguna untuk pipeline CI/CD
  • VNC dapat dipakai hanya secara lokal, tetapi README secara eksplisit menyebut tidak ada enkripsi TLS/HTTPS sama sekali
    • Dijelaskan bahwa penggunaan tunnel SSH dan menutup port eksternal akan membuatnya lebih aman
  • SPICE juga dapat digunakan
    • Hubungkan dengan remote-viewer spice://localhost:3001
    • -disable-ticketing pada contoh mengizinkan akses VM tanpa autentikasi, sehingga dianjurkan merujuk ke pengaturan autentikasi di manual SPICE

Nomor serial dan riset iMessage/iCloud

  • Nilai berikut disebut perlu diubah untuk menggunakan iMessage atau iCloud
    • SERIAL
    • BOARD_SERIAL
    • UUID
    • MAC_ADDRESS
    • ROM dijelaskan sebagai alamat MAC huruf kecil tanpa titik dua
  • Docker-OSX menyediakan dua cara
    • GENERATE_UNIQUE=true: membuat nilai unik saat runtime
    • GENERATE_SPECIFIC=true: memakai nilai yang ditentukan
  • ./custom/generate-unique-machine-values.sh dapat membuat nomor serial, alamat MAC, output CSV/TSV, serta image boot disk
  • Nomor serial dapat diperiksa di dalam macOS dengan ioreg -l | grep IOPlatformSerialNumber

Performa, resolusi, dan pengaturan jaringan

  • Dijelaskan bahwa container dapat dipercepat dengan osx-optimizer
    • Melewati layar login GUI
    • Menonaktifkan indexing Spotlight
    • Menonaktifkan latar belakang layar login yang berat
    • Menonaktifkan pembaruan
  • Resolusi dapat diubah dengan variabel lingkungan WIDTH dan HEIGHT
    • Harus digunakan bersama GENERATE_UNIQUE=true atau GENERATE_SPECIFIC=true
    • Boot memerlukan sekitar 30 detik tambahan untuk membuat partisi boot baru
    • Resolusi yang salah akan diatur ulang ke 800x600
  • Adapter jaringan dapat diubah dengan variabel lingkungan
    • Koneksi internet cepat: NETWORKING=vmxnet3
    • Koneksi internet lambat: NETWORKING=e1000-82545em
  • Pada instalasi jarak jauh, mengaktifkan IPv4 forwarding dapat meningkatkan performa, tetapi dijelaskan bahwa IP host bisa bocor meskipun VPN digunakan di dalam container

Pemecahan masalah dan batasan

  • Jika daemon Docker tidak berjalan, dapat muncul error docker: unknown server OS: .
    • sudo dockerd
    • sudo systemctl --start dockerd
    • sudo systemctl --enable --now dockerd
  • RAM tidak dapat dialokasikan melebihi mesin fisik
    • Nilai default adalah -e RAM=3
    • Jika dialokasikan terlalu banyak, dapat muncul error cannot set up guest memory 'pc.ram': Cannot allocate memory
  • Error terkait ALSA dapat muncul saat inisialisasi container atau selama boot, dan dijelaskan tidak perlu dikhawatirkan jika proses boot dan fungsi berjalan normal
  • TODO masih mencantumkan item berikut
    • Dokumentasi untuk peneliti keamanan
    • Akselerasi GPU
    • Dukungan virt-manager

Lisensi dan pemberitahuan

  • Docker-OSX dilisensikan dengan GPL v3+
  • Disebutkan bahwa penggunaan Docker-OSX sebagai alat untuk membuat perangkat lunak proprietari diperbolehkan
  • Termasuk pemberitahuan terkait riset keamanan Apple dan Apple Bug Bounty Program, serta tautan ke tulisan terpisah mengenai isu hukum Hackintosh, OSX-KVM, dan Docker-OSX
  • Dijelaskan bahwa nama produk, logo, merek, dan trademark yang disebut di proyek ini adalah milik pemilik masing-masing, dan para pemegang merek tersebut tidak berafiliasi dengan, mensponsori, atau mendukung repositori ini

Bacaan terkait

1 komentar

 
GN⁺ 2024-08-01
Opini Hacker News

  • Ini penting bagi orang yang benar-benar ingin memakai proyeknya, tapi saya tidak mengerti kenapa begitu banyak resep build seperti Dockerfile dibuat untuk mengunduh materi acak dari internet selama proses build
    Dockerfile proyek ini juga mengambil 2 repositori Git dan 1 skrip pada saat build
    Selain tentu saja gagal di server build sandbox yang akses internetnya diblokir, siapa pun yang sedikit saja peduli keamanan harus mengaudit seluruh resep build sebelum menggunakannya
    Sekarang tidak cukup lagi hanya memeriksa dependensi yang tercantum di spesifikasi build seperti README, requirements.txt, atau package.json; melihat kegagalan infrastruktur inti belakangan ini dan meningkatnya serangan rantai pasok, ini adalah tren yang sangat mengkhawatirkan

    • Saya sangat tidak suka ketika proyek menarik file build dari internet. Biasanya terjadi tanpa diduga, dan selain masalah keamanan, itu juga membuat software yang bergantung di atasnya jauh lebih sulit dipaketkan
      Muncul kejutan yang tidak menyenangkan, seperti masalah versi, tidak ada internet, atau yang terburuk dependensinya tidak lagi tersedia. Distribusi mandiri seharusnya menjadi default
    • Jawabannya adalah churn perubahan. Ranah DevOps berubah terlalu cepat sampai sekarang tidak ada lagi yang punya waktu untuk mencari tahu “cara yang benar”
    • Arah yang benar adalah menunggu pemain open source besar seperti Red Hat, SUSE, dan Canonical membuat build menjadi aman
      Fedora dan openSUSE biasanya punya kebijakan agar build, termasuk paket distribusi dan image container, hanya dibuat dari paket di repositori atau hanya memakai binary yang ditambahkan secara eksplisit saat build
      Jadi kalau bisa dipasang dengan dnf/zypper install atau diambil dari registry container vendor, artefaknya bisa dipercaya
      Kalau butuh bleeding edge terbaru, Anda harus menerima materi acak dari internet
      Sulit bagi developer open source sembarang untuk membuat artefak build yang siap offline dan tepercaya, dan mereka tidak punya infrastruktur seperti itu. Karena itulah perusahaan seperti Red Hat atau SUSE ada
      Perusahaan bernilai puluhan miliar dolar bersedia membayar seseorang untuk mengerjakan pekerjaan plumbing: mengubah artefak acak dari internet menjadi artefak yang tepercaya, dapat direproduksi, dan ditandatangani, sekaligus melacak CVE dan melakukan pembaruan rutin
    • Saya tidak melihat bedanya dengan JavaScript yang menarik puluhan ribu dependensi hanya untuk menampilkan satu halaman web
      Pada era 80-an, orang membayangkan komponen software pakai ulang yang modular, seperti balok Lego yang bisa dipasang-pasang, dan saat itu disebut CASE. Sekarang hal itu sudah terwujud, tapi tentu ada harganya
    • Kemungkinan besar alasan utamanya adalah untuk menjaga kerapian konfigurasi dalam repositori Git terpisah
      Kalau tidak melakukan clone di Dockerfile, perlu ada instruksi pra-build seperti “gunakan --recursive saat clone atau jalankan git submodule init untuk mengambil repositori lain ke direktori kerja saat ini”

  • Satu-satunya kemungkinan untuk akselerasi GPU adalah meneruskan dGPU yang didukung lewat PCI passthrough. AMD RX 6xxx ke atas bisa di macOS 14.x, tetapi Nvidia modern tidak mungkin
    Intel iGPU berfungsi hingga Comet Lake, dan sebagian Ice Lake, tetapi yang lebih baru tidak
    macOS build Apple Silicon tampaknya sulit diemulasikan untuk sementara waktu, dan ada sedikit pekerjaan awal untuk boot ARM Darwin
    Selain itu, AMD tidak punya Intel VT-x sehingga virtualisasi rusak di host AMD, tetapi lewat hack aneh menggunakan VirtualBox versi lama, Docker bisa dijalankan sampai taraf tertentu melalui emulasi

    • Secara teori, seseorang bisa membuat driver display untuk akselerasi 3D libvirt/kvm/qemu seperti yang ada di Windows dan Linux. Dengan begitu, meski performanya tidak optimal, hampir semua GPU bisa memanfaatkan performa GPU
      AMD punya alternatif VT-x sendiri, yaitu AMD-V, jadi seharusnya berjalan tanpa masalah. Namun ada hambatan lain untuk mem-boot macOS di CPU AMD, yang biasanya diselesaikan dengan memuat kext atau trik lain
      Saya kurang paham apa gunanya menjalankan seluruh sistem operasi dengan Docker. Cukup distribusikan sebagai OVA atau format virtualisasi pilihan. qcow2 dan skrip bash untuk memulai VM mungkin sudah cukup
    • Bagian “AMD tidak punya Intel VT-x sehingga virtualisasi rusak di host AMD” bukankah bisa dengan AMD-V?

  • Tulisan terkait:
    Docker-OSX: Run macOS VM in a Docker - https://news.ycombinator.com/item?id=34374710 - Januari 2023, 110 komentar
    macOS in QEMU in Docker - https://news.ycombinator.com/item?id=23419101 - Juni 2020, 186 komentar

  • Beberapa bulan lalu saya mengaturnya sebagai eksperimen, dan berjalan cukup baik. Namun agar iMessage berfungsi, saya mengetahui bahwa aplikasinya mengirim hardware ID ke Apple, dan proyek ini memakai nilai palsu
    Sejak saat itu, saya mulai meluncur di lereng “sepertinya tidak akan berhasil”, dan mengetahui bahwa nilai palsu bisa ditandai oleh Apple sehingga pada akhirnya ID iCloud bisa ditandai sebagai calon spammer dan akses dari perangkat lain dibatasi
    Satu-satunya pilihan adalah terus mencoba nilai dengan skrip pembuat hardware ID yang ditautkan secara samar sampai menemukan nilai yang “berfungsi”, tetapi tidak ada sinyal jelas bahwa nilainya benar-benar cocok dan tidak merusak reputasi iCloud
    Selain itu, semuanya berjalan sangat baik, dan sangat berguna saat keadaan mendesak

    • Cara “terus mengganti HWID sampai berhasil” juga umum dipakai untuk membuat iMessage berfungsi di Hackintosh. Dulu bisa dicek apakah berhasil di checkcoverage.apple.com
      Tak lama kemudian, saya sadar lebih mudah menyalin Serial dari Mac sungguhan, meski sudah tua
      Namun alat ini tampaknya lebih berguna untuk hal seperti skrip build yang bergantung pada framework macOS proprietary, bukan untuk dipakai seperti komputer pribadi
    • Untuk riset keamanan, umumnya sebaiknya jangan menggunakan akun iCloud utama atau akun utama lainnya

  • Sekadar ingin mencoba apakah bisa melakukan build untuk iOS. Misalnya hal-hal seperti Unity atau React Native
    Meski build memakan waktu 5 kali lebih lama, dari sisi kebebasan ini bisa cukup keren

    • Cross-compilation kemungkinan besar pendekatan yang lebih baik: https://github.com/tpoechtrager/osxcross
      Cara Godot melakukan build dengan target iOS juga seperti ini: https://github.com/godotengine/build-containers/blob/main/Do...
      Ada juga image Docker dengan tool yang sudah terpasang sebelumnya, tetapi perlu sedikit modifikasi untuk menargetkan iOS: https://github.com/shepherdjerred/macos-cross-compiler
      Saat di RStudio, yang sekarang menjadi Posit, saya pernah mengerjakan cross-compilation C/C++/Fortran/Rust dari host Linux dengan target macOS x86_64/aarch64
      Jika mengunduh paket R yang memiliki native code dari Posit Package Manager(https://p3m.dev/client/), paket itu di-cross-compile dengan cara ini :)
    • Saya sudah mencobanya sendiri. Port USB harus dibagikan entah bagaimana lewat Docker, dan menurut panduan di repositorinya prosesnya nyaris seperti ilmu hitam, tetapi setelah build aplikasi iOS, saya bisa menjalankannya di iPhone
    • Akan mengesankan kalau di lingkungan ini di atas mesin Windows bisa melakukan build React Native iOS yang memiliki modul Swift native dan menjalankannya di simulator

  • Dulu pernah mewawancarai Sick Codes tentang pendekatan produk ini: https://www.vice.com/en/article/akdmb8/open-source-app-lets-...
    Ada juga OSX-PROXMOX yang melakukan hal serupa di homeserver Proxmox: https://github.com/luchina-gabriel/OSX-PROXMOX
    Secara pribadi saya memakai yang terakhir di HP Z420 Xeon, dan sangat stabil, terutama jika ditambah GPU passthrough

  • Akan menyenangkan jika bisa menjalankan sinkronisasi iCloud di homeserver. Saat ini tidak ada cara yang bagus untuk membackup iCloud secara fisik ke homeserver/NAS, dan hanya berfungsi di Windows/Apple

    • Ini mungkin membantu menyinkronkan data tersebut lalu menyimpannya secara lokal atau membackupnya ke tempat lain:
      https://github.com/steilerDev/icloud-photos-sync
      https://github.com/icloud-photos-downloader/icloud_photos_do...
    • Saya sedang mengerjakan solusi menggunakan OSX-Docker dan OSXPhotos. Sudah cukup dekat, tetapi saya ingin membackup semua informasi dari iCloud sekaligus menyertakan perubahan metadata
      Ternyata iCloud tidak memperbarui foto asli. Itu bisa dimengerti, tetapi tidak membantu bagi orang yang mengharapkan perubahan tersebut ikut terbawa saat melakukan backup
    • Saya penasaran bagaimana ini membantu masalah itu. Dibandingkan melakukan rsync folder iCloud dari Mac/PC yang terhubung ke NAS, apa hal berbeda yang bisa dilakukan olehnya?

  • Saya penasaran apakah redistribusi image MacOS diizinkan oleh lisensi. Atau apakah proyek ini terang-terangan mendistribusikan salinan bajakan di Docker Hub?

    • Saya tidak yakin, tetapi Corellium memvirtualisasikan instance iOS, lalu digugat Apple dan akhirnya berdamai
    • Ini jelas ilegal

  • Saya penasaran apakah pengembangannya akan terhenti saat versi MacOS yang lebih baru tanpa dukungan Intel dirilis
    Bisakah menjalankan Docker di dalam container ini untuk menjalankan MacOS di dalam MacOS? ;)

    • Secara teori, kapan saja qemu bisa dijalankan dalam mode emulasi penuh
    • Anda bisa melakukan itu begitu saja di program VM mana pun yang didukung

  • Saya benar-benar tidak suka ketika istilah “USB passthrough” dipakai untuk situasi yang sebenarnya paling banter adalah “proxy USB melalui Ethernet”
    Itu bukan passthrough. Ia membawa berbagai kelemahan yang tidak ada pada passthrough biasa, dan mungkin juga tidak ada pada passthrough tingkat lanjut

    • QEMU USB passthrough adalah USB passthrough sungguhan. Masalah USB passthrough berasal dari controller USB itu sendiri dan cara enumerasi perangkat, dan satu-satunya solusi yang lebih baik adalah melakukan PCIe passthrough untuk seluruh controller USB
      Namun cara itu juga membawa masalah lain. Ini berdasarkan pengalaman menjalankan farm pengujian VM skala besar dengan banyak hardware yang diteruskan
      Meski begitu, “proxy USB melalui Ethernet” juga passthrough sungguhan, hanya saja passthrough dengan latensi lebih besar daripada VirtIO