Analisis Mendalam Darwin OS dan Kernel XNU Apple

 (tansanrao.com)
2 poin oleh GN⁺ 2025-04-06 | 1 komentar | Bagikan ke WhatsApp
  • Darwin milik Apple adalah fondasi berbasis keluarga Unix untuk macOS, iOS, dan OS Apple modern, sementara XNU adalah kernel hibrida yang menggabungkan Mach dan BSD dalam satu kernel
  • XNU mempertahankan task, thread, memori virtual, dan IPC berbasis port dari Mach, sambil menempatkan layanan BSD dalam ruang alamat kernel yang sama untuk mengurangi biaya message passing ala mikrokernel murni
  • Garis keturunan Mach 2.5+4.3BSD dari NeXTSTEP berlanjut ke Mac OS X dan Darwin setelah Apple mengakuisisi NeXT pada 1996, lalu secara bertahap menambahkan kode FreeBSD, I/O Kit, dukungan 64-bit, ARM, dan Apple Silicon
  • macOS dan iOS memperluas fitur seperti sandbox, code signing, SIP, APFS, DriverKit, penjadwalan QoS, Jetsam, dan compressed memory melalui kerja sama antara kernel dan ruang pengguna
  • Evolusi XNU lebih dekat pada pendekatan mempertahankan fondasi Mach/BSD alih-alih menulis ulang kernel, dengan mengintegrasikan bagian yang butuh performa ke dalam kernel dan memisahkan bagian yang butuh isolasi lewat IPC dan ruang pengguna

Titik awal Darwin dan XNU

  • Darwin adalah sistem operasi inti keluarga Unix yang menopang macOS, iOS, dan platform OS modern Apple
  • Di pusatnya ada kernel XNU, singkatan dari “X is Not Unix”, yang menggabungkan inti mikrokernel Mach dan komponen Unix BSD
  • Struktur ini memanfaatkan sekaligus desain berbasis message passing dari Mach dan stabilitas serta kompatibilitas POSIX dari BSD untuk mengejar keseimbangan antara modularitas dan performa

Sejarah yang berlanjut dari Mach, NeXTSTEP, ke Mac OS X

  • Mach dimulai sebagai proyek pada 1985 di Carnegie Mellon University yang dipimpin Richard Rashid dan Avie Tevanian
    • Ini adalah desain mikrokernel yang hanya menempatkan fungsi tingkat rendah seperti manajemen memori, penjadwalan CPU, dan IPC di dalam kernel, sementara file system, jaringan, dan driver dimaksudkan berjalan sebagai server ruang pengguna
    • Konsep seperti task, thread, Mach port, copy-on-write, dan memory object menjadi objek inti kernel
  • NeXTSTEP dirilis pada 1989 dengan menempatkan subsistem Unix 4.3BSD di atas kernel Mach 2.5
    • NeXT memilih memprioritaskan performa dengan mengintegrasikan kode BSD ke dalam ruang alamat kernel ketimbang memakai pendekatan mikrokernel murni
    • Sistem ini juga menyertakan DriverKit berbasis Objective-C, yang kemudian berlanjut ke garis keturunan XNU milik Apple
  • Apple mengakuisisi NeXT pada 1996 dan memilih NeXTSTEP sebagai fondasi Mac OS X yang baru
    • Proyek Rhapsody dimulai, membawa kernel hibrida Mach/BSD dari NeXT ke Apple
    • Setelah itu XNU mengadopsi kode turunan Mach 3.0 berbasis OSFMK 7.3 serta kode 4.4BSD dan FreeBSD

Perkembangan awal Darwin dan Mac OS X

  • Apple merilis developer preview Mac OS X pada 1999, lalu membuka Darwin 1.0 pada 2000 agar developer dapat mengakses kernel XNU dan ruang pengguna Unix dasar
  • Mac OS X 10.0 Cheetah dirilis secara komersial pada 2001 berbasis Darwin 1.3.1
  • Fokus perubahan awal ada pada penguatan lapisan BSD, jaringan, file system, dan performa threading
    • Mac OS X 10.1 Puma meningkatkan performa manajemen thread dan dukungan thread real-time
    • Mac OS X 10.2 Jaguar mencakup IPv6, IPSec, mDNSResponder, dan journaling HFS+
    • Mac OS X 10.3 Panther mengintegrasikan peningkatan kernel FreeBSD 5 dan lock kernel yang lebih terperinci untuk memperkuat pemanfaatan multiprosesor
  • Mac OS X 10.4 Tiger memperoleh sertifikasi UNIX 03, mengadopsi kqueue/kevent dari FreeBSD, dan mempertahankan fondasi lintas platform untuk transisi ke Intel Mac

Kebutuhan mobile yang dibawa 64-bit dan iPhone OS

  • Mac OS X 10.5 Leopard berbasis Darwin 9 memperkenalkan eksekusi kernel 64-bit, driver 64-bit, ASLR, sandbox, dan DTrace
  • iPhone OS pertama pada 2007 juga dirilis berbasis Darwin 9, memperluas XNU hingga perangkat mobile ARM
    • iPhone awal memiliki RAM terbatas dan tidak bisa memakai swap, sehingga menggunakan mekanisme Jetsam untuk menghentikan aplikasi latar belakang saat memori rendah
    • iPhone OS menjalankan aplikasi pihak ketiga di dalam sandbox dan mewajibkan code signing yang ketat pada biner
  • Mac OS X 10.6 Snow Leopard menghentikan dukungan PowerPC dan memperkuat optimasi 64-bit serta multicore yang berfokus pada Intel
    • Grand Central Dispatch dan libdispatch adalah library ruang pengguna, tetapi memanfaatkan dukungan thread pool dan penjadwalan dari kernel
    • OpenCL juga memerlukan integrasi erat antara framework pengguna dan driver kernel untuk komputasi GPU
  • iOS 4 menyesuaikan scheduler agar cocok dengan pembedaan prioritas aplikasi latar belakang dan dukungan SoC ARM multicore

Perluasan fitur kernel di macOS dan iOS modern

  • OS X 10.9 Mavericks menambahkan compressed memory dan timer coalescing
    • Compressed memory mengompresi halaman tidak aktif di dalam RAM untuk mengurangi disk swap
    • Timer coalescing menyelaraskan waktu CPU bangun agar konsumsi daya lebih rendah
  • OS X 10.11 El Capitan memperkenalkan System Integrity Protection, atau SIP
    • SIP ditegakkan kernel melalui framework Mandatory Access Control pada lapisan BSD, sehingga bahkan proses root tidak dapat mengubah file dan proses sistem penting
  • macOS 10.13 High Sierra memperkenalkan APFS sebagai file system default
    • Lapisan VFS pada XNU diperluas untuk mendukung snapshot, cloning, dan enkripsi tingkat container dari APFS
    • Pada periode yang sama, pemuatan kext pihak ketiga mulai memerlukan persetujuan pengguna
  • macOS 10.15 Catalina memperkenalkan DriverKit modern
    • DriverKit memindahkan banyak driver menjadi Driver Extension ruang pengguna di luar kernel
    • Kernel menyediakan akses hardware terbatas ke driver ruang pengguna melalui IPC dan shared memory
    • Catalina juga memperkenalkan system volume read-only untuk memperkuat perlindungan SIP

XNU di era Apple Silicon

  • macOS 11 Big Sur dan Darwin 20 pada 2020 adalah rilis pertama yang mendukung Apple Silicon Mac
  • XNU sebenarnya sudah mendukung ARM lewat iOS, tetapi Apple Silicon Mac mengharuskannya mempertimbangkan juga arsitektur CPU big.LITTLE yang heterogen
    • Scheduler mengenali inti heterogen agar bisa menempatkan thread berat dan prioritas tinggi pada performance core, serta thread QoS rendah atau latar belakang pada efficiency core
    • Kelas QoS dipakai sebagai petunjuk penjadwalan yang pada Apple Silicon juga dapat memengaruhi pemilihan jenis core
  • Dalam arsitektur unified memory Apple Silicon, pengelola memori kernel dan driver GPU menangani berbagi buffer
    • Abstraksi Mach VM cocok untuk berbagi memory object antara ruang pengguna dan GPU melalui VM remapping alih-alih penyalinan
  • Backend ARM64 mendukung Pointer Authentication, menggunakan kunci PAC pada exception frame dan pointer sistem untuk membantu mitigasi serangan ROP
  • XNU tetap menjadi fondasi bersama bagi banyak platform Apple seperti macOS, iOS, watchOS, tvOS, bridgeOS, dan visionOS

Struktur kernel hibrida XNU

  • Komponen Mach dan BSD dalam XNU ditautkan menjadi satu biner kernel dan berbagi ruang alamat yang sama
    • Tidak ada batas proteksi antara Mach dan BSD, dan di dalam kernel keduanya berinteraksi lewat pemanggilan fungsi biasa, bukan pesan IPC
    • System call Unix seperti read() tidak mengirim pesan ke server BSD terpisah, melainkan langsung masuk ke kode file system BSD di dalam kernel
  • Mach menangani infrastruktur inti kernel
    • Ia mengelola pembuatan dan penghentian task serta thread, context switching, penjadwalan tingkat rendah, lock, timer, dan scheduling queue
    • Setiap proses BSD dipetakan ke sebuah Mach task, dan setiap thread ke sebuah Mach thread
    • Mach VM menyediakan peta alamat virtual, memory object, copy-on-write, dan berbagi memori berbasis IPC
  • BSD menyediakan karakter dan layanan Unix
    • Ia mengelola PID, user ID, signal, thread POSIX, file system, jaringan, IPC Unix, device I/O, serta framework izin dan keamanan
    • VFS menangani file system seperti HFS+, APFS, dan NFS, dan pada file memory-mapped terhubung dengan Mach VM melalui vnode pager
    • Sandbox dan SIP bekerja melalui kolaborasi antara modul keamanan BSD dan pembatasan Mach task port
  • I/O Kit adalah poros ketiga XNU, yakni framework driver berorientasi objek yang ditulis dalam bentuk C++ terbatas
    • Perangkat dan driver direpresentasikan sebagai hierarki kelas, dan driver berjalan sebagai objek C++ di dalam kernel
    • Ruang pengguna mendapat akses terbatas melalui properti I/O Registry dan antarmuka user client
    • Sebelum DriverKit hadir di macOS modern, sebagian besar driver berjalan sebagai kext di dalam kernel

Mach IPC dan layanan sistem

  • XNU tidak memakai pesan Mach pada jalur system call Unix, tetapi memanfaatkan Mach IPC secara luas untuk komunikasi antara layanan ruang pengguna dan antara kernel dengan proses
  • Mach port digunakan sebagai handle ruang pengguna untuk banyak objek kernel
    • Setiap task memiliki task port, dan proses yang berwenang dapat memakainya untuk memeriksa atau mengendalikan task lain
  • Event dan notifikasi juga dikirim melalui pesan Mach
    • WindowServer menerima event input pengguna dari kernel sebagai pesan Mach
    • Grand Central Dispatch secara internal memakai Mach port untuk menidurkan thread penunggu event
    • kqueue/kevent dapat menunggu pesan Mach port dan file descriptor sekaligus
  • Framework XPC dari Apple dibangun di atas pesan Mach
    • Koneksi XPC secara internal berbasis pada Mach port
    • Model izin Mach port dipakai untuk verifikasi hak pemanggil pada layanan seperti securityd milik Keychain
    • Pesan Mach dapat membawa out-of-line memory dan hak port, sehingga dipakai untuk membangun RPC tingkat tinggi
  • MIG, atau Mach Interface Generator, digunakan untuk menghasilkan definisi antarmuka serta kode pengiriman dan penerimaan pesan antara kernel dan ruang pengguna

Scheduler dan manajemen thread

  • Scheduler XNU berawal dari scheduler round-robin berbasis prioritas milik Mach, tetapi telah banyak dimodifikasi agar cocok dengan kebutuhan desktop dan mobile
  • Secara historis Mach mendefinisikan prioritas thread dalam rentang 0~127, dan XNU memakai nilai seperti sched_pri dan base_pri
    • Prioritas thread time-sharing dapat berubah berdasarkan penggunaan
    • Thread real-time memakai prioritas tetap
  • XNU menangani efisiensi dan load balancing melalui run queue per-CPU dan interrupt scheduler
  • Sandbox aplikasi iOS dan eksekusi latar belakang tercermin dalam scheduler melalui konsep peran kerja atau kelompok prioritas
  • Kelas QoS diintegrasikan ke penjadwalan sejak iOS 8 dan OS X 10.10
    • Kelas seperti user-interactive, user-initiated, default, utility, dan background memengaruhi pita prioritas dan penjadwalan
    • Thread yang dibuat lewat Grand Central Dispatch atau NSThread mewarisi QoS
    • Pada Apple Silicon, thread QoS background dapat ditempatkan ke efficiency core
  • Queue real-time dan penjadwalan berbasis deadline juga didukung untuk audio real-time dan pekerjaan penting

Manajemen memori dan Mach VM

  • Manajemen memori XNU berpusat pada subsistem Mach VM
  • Setiap Mach task memiliki ruang alamat virtual yang direpresentasikan oleh VM map dan VM region
    • fork() memakai copy-on-write alih-alih langsung menyalin seluruh memori
    • Induk dan anak berbagi halaman yang sama sampai ada penulisan
  • Mach menggunakan konsep memory object dan pager
    • Pager default untuk memori anonim ditangani oleh daemon ruang pengguna dynamic_pager, yang mengelola swap file saat diperlukan
    • Memori file ditangani oleh vnode pager pada lapisan BSD di dalam kernel yang berinteraksi dengan kode file system
  • Compressed memory di Mavericks diimplementasikan dengan menambahkan compression pager di dalam kernel
    • Saat tekanan memori tinggi, halaman tidak aktif tidak langsung dikirim ke disk, tetapi disimpan terkompresi dalam compressor pool di RAM
    • Jika kompresi masih tidak cukup, disk swap digunakan
  • Pengelolaan memori fisik ditangani oleh lapisan yang bergantung pada arsitektur, yaitu pmap
    • pmap mengelola page table atau struktur padanan pada arsitektur terkait
    • Pada ARM64, fitur keamanan dan isu terkait cache juga terhubung dengan pmap
  • Shared cache milik dyld digunakan secara efisien dengan memetakan halaman fisik yang sama sebagai read-only ke banyak proses

Dukungan virtualisasi

  • Pada Intel Mac, Hypervisor.framework tersedia sejak OS X 10.10 untuk mendukung virtualisasi ruang pengguna
    • Framework ini memakai Intel VT-x agar proses ruang pengguna dapat bertindak seperti virtual machine monitor
    • Alat seperti xhyve dan beberapa aplikasi virtualisasi memanfaatkan fitur ini
  • Pada Apple Silicon, Virtualization.framework di macOS 11 berjalan di atas hypervisor dalam kernel untuk ARM64
    • Developer dapat menjalankan VM Linux atau macOS dari ruang pengguna
    • Apple memilih pendekatan akses melalui framework dan izin Apple, alih-alih membiarkan hypervisor pihak ketiga sembarang berjalan di dalam kernel
  • Dari sudut pandang kernel, fitur hypervisor mencakup pengelolaan memori fisik tamu, trap-and-emulate untuk instruksi sensitif, dan pemaparan antarmuka vCPU
  • Scheduler Mach menjadwalkan vCPU yang dari sudut host merupakan thread, dan subsistem memori dipakai untuk pemetaan memori tamu
  • Di iOS, virtualisasi juga dimungkinkan dalam kondisi dan izin tertentu, dan ada contoh perangkat A14 yang sudah di-jailbreak mengaktifkan hypervisor untuk menjalankan VM Linux

Secure Enclave dan Exclaves

  • macOS menggunakan dua mekanisme isolasi, yaitu Secure Enclave dan exclaves, untuk melindungi pekerjaan dan data sensitif
  • Secure Enclave adalah subsistem khusus yang diperkeras dan terintegrasi ke Apple SoC
    • Terdapat pada iPhone, iPad, T2, atau Apple Silicon Mac
    • Ia menjalankan sistem operasi sendiri berbasis mikrokernel dan mengelola informasi sensitif seperti kunci kriptografi serta data biometrik
    • Tujuannya adalah memisahkan data penting meskipun prosesor aplikasi utama atau kernel utama telah dikompromikan
  • Exclaves adalah struktur keamanan yang lebih baru yang muncul di macOS 14.4 dan iOS 17
    • Alih-alih menempatkan pekerjaan sensitif dalam domain hak istimewa yang sama dengan kernel XNU utama, sebagian resource inti dipisahkan ke domain “externally located” yang terpisah
    • Resource yang menjadi sasaran mencakup layanan Apple ID, buffer audio, data sensor, dan komponen pengelolaan indikator
    • kext khusus dan private framework seperti ExclaveKextClient.kext, ExclaveSEPManagerProxy.kext, dan ExclavesAudioKext.kext terlibat dalam pengelolaannya
  • Pemisahan ini memberi lapisan pertahanan tambahan dengan mengisolasi pekerjaan di dalam exclave walaupun kernel utama telah dikompromikan

Arah desain jangka panjang

  • Darwin dan XNU adalah desain campuran, bukan mikrokernel sepenuhnya dan bukan pula kernel monolitik sepenuhnya
  • Inti berbasis Mach membantu adaptasi ke arsitektur baru dan fitur sistem baru, sementara lapisan BSD menyediakan lingkungan kompatibel POSIX serta tool dan API Unix
  • Apple mengakomodasi transisi CPU dari PowerPC ke Intel lalu ARM, serta kategori perangkat baru seperti iPhone, Apple Watch, dan Apple Vision Pro di atas fondasi XNU
  • Perubahan kernel terutama berlangsung dengan tiga cara
    • Fitur baru diperluas di atas kernel yang ada
    • Komponen yang penting bagi performa diintegrasikan ke dalam kernel
    • Komponen yang memerlukan isolasi dipisahkan melalui Mach IPC dan ruang pengguna
  • Rilis open source Darwin memberi peneliti jendela untuk menelaah kernel hibrida komersial ini, meski cakupan yang dibuka tetap terbatas

Bacaan terkait

1 komentar

 
GN⁺ 2025-04-06
Komentar Hacker News

  • Sistem memori virtual Mach masuk bukan hanya ke 4.4BSD dan FreeBSD, tetapi juga NetBSD[0] dan OpenBSD[1], namun tampaknya tidak ke DragonFly BSD[2]
    [0] https://netbsd.org/docs/kernel/uvm.html
    [1] https://man.openbsd.org/OpenBSD-3.0/uvm.9
    [2] https://www.dragonflybsd.org/mailarchive/kernel/2011-04/msg0...

    • Tepatnya tidak begitu. 386BSD, FreeBSD, dan NetBSD pada awalnya memang mewarisi desain ala Mach 2.5, tetapi FreeBSD cukup cepat mengganti semua sisa jejak Mach VM[0] dengan penulisan ulang VM yang modern dan berkinerja baik
      Pada era FreeBSD 4, tidak ada lagi kode Mach asli yang tersisa di codebase kernel, dan hal itu sudah selesai pada akhir 1990-an, jadi keterkaitan FreeBSD dengan Mach paling jauh hanya pada tahap percabangan/fondasi yang sangat awal
      NetBSD dan OpenBSD juga meneruskannya untuk beberapa waktu, tetapi setelah terbentur keterbatasan performa, SMP/skalabilitas, dan networking dari desain Mach, mereka menulis ulang sepenuhnya menjadi UVM (Unified Virtual Memory) yang dirancang dan dipimpin oleh Chuck Cranor; OpenBSD kemudian meminjam implementasi ini dan masih menggunakannya sampai sekarang
      Di antara BSD yang masih hidup[1], satu-satunya yang terus memakai Mach adalah XNU/Darwin, dan itu pun bukan Mach 2.5 melainkan Mach 3. Ada Mach 2.5, 3, dan 4 (GNU/Hurd memakai Mach 4), tetapi kompatibilitasnya rendah dan terutama hanya berbagi pengaruh pada tingkat arsitektur keseluruhan, jadi lebih tepat melihatnya sebagai desain terpisah yang sama-sama mendapat pengaruh serupa
      [0] Dari awal jejaknya juga tidak banyak
      [1] Saya juga tidak begitu tahu apakah DragonBSD sekarang sudah mati atau masih hidup

  • Yang menarik dari Darwin adalah kecepatan perubahan radikal pada komponen intinya. Mulai dari mengorbankan kompatibilitas mundur system call, code signing wajib, hingga dyld_shared_cache yang menghapus file library sistem individual demi mempercepat pemuatan executable dinamis—semuanya menunjukkan pendekatan desain yang berorientasi hasil, tanpa nostalgia atau area yang dianggap sakral
    Ini tampak seperti pendekatan yang hanya bisa dilakukan oleh produsen hardware besar seperti Apple

  • Tulisan itu mengatakan daemon pager yang mengelola file swap berjalan di ruang pengguna, dan memori kernel juga bisa di-swap, tetapi tidak menjelaskan bagaimana daemon ruang pengguna melakukan swap terhadap memori kernel
    Saya penasaran apakah ada pengecualian hardcoded untuk daemon khusus, atau apakah ia memakai system call khusus. Di mana saya bisa membaca detail lebih lanjut tentang manajemen memori ruang pengguna?

    • Penjelasan itu tidak akurat dan mencampur beberapa hal. Mikrokernel Mach awalnya memang mendukung paging ruang pengguna sungguhan yang mirip mmap, dengan daemon arbitrer sebagai pengganti file system; antarmukanya bisa dilihat di sini:
      https://web.mit.edu/darwin/src/modules/xnu/osfmk/man/memory_...
      Namun tidak jelas apakah Darwin pernah benar-benar memakai fitur ini, dan setidaknya selama kira-kira 20 tahun terakhir fitur itu tidak digunakan. dynamic_pager tidak pernah memakai antarmuka ini; ketika XNU memberi tahu bahwa swap kurang, ia membuat file swap dan menyerahkannya ke kernel lewat system call macx_swapon dan macx_swapoff, menggunakan antarmuka Mach yang jauh lebih terbatas. Swap sebenarnya dilakukan oleh kernel, dan kode dynamic_pager lama ada di sini:
      https://github.com/apple-oss-distributions/system_cmds/blob/...
      Fitur itu pun kini sudah masuk ke kernel, sehingga dynamic_pager saat ini pada dasarnya hampir tidak melakukan apa-apa:
      https://github.com/apple-oss-distributions/system_cmds/blob/...
      Sebagian besar memori kernel bersifat fixed (wired) sehingga tidak bisa di-page, tetapi kernel dapat secara eksplisit meminta memori yang bisa di-page melalui cara seperti IOMallocPageable, dan memori itu bisa di-swap ke disk. Namun ini jarang dipakai, dan kode semacam ini harus berhati-hati agar menghindari deadlock. Meski ruang pengguna tidak lagi terlibat dalam “paging” itu sendiri, cukup umum ruang pengguna ikut campur satu atau dua lapisan di bawahnya, seperti FSKit atau file system ruang pengguna berbasis FUSE, file system di atas disk image, serta NFS/SMB yang melewati ekstensi networking ruang pengguna. Namun bagian terakhir ini mungkin keliru. File system yang terhambat oleh ruang pengguna jelas mungkin ada, tetapi meletakkan swap di atas file system seperti itu mungkin tidak didukung
    • https://github.com/apple-oss-distributions/xnu

  • Setiap kali membaca cerita tentang kernel Darwin, saya jadi bertanya-tanya betapa berbedanya jadinya jika Apple sekadar mem-fork Linux lalu membangun layanan OS di atasnya.
    Terutama melihat betapa Apple terobsesi dengan Darwin, saya mendapat kesan kurang baik karena apa yang hilang dari open source tampak tidak seimbang dibandingkan keuntungan terhadap waktu dan biaya yang harus Apple keluarkan.

    • Tidak pernah ada momen yang tepat bagi Apple untuk melakukan transisi seperti itu. NeXTSTEP muncul lebih dulu daripada Linux, dan ketika beralih ke Mac OS X, Apple tidak mampu menanggung proyek mengganti seluruh kernel selain semua pekerjaan lainnya.
      Linux pada akhir 1990-an juga jelas bukan pilihan yang lebih baik, dan setelah OS X melewati beberapa versi lalu menjadi OS turunan UNIX paling sukses di PC konsumen, beralih ke basis Linux menjadi pilihan yang hampir tidak memberi keuntungan jangka pendek, tetapi penuh biaya dan risiko.
      Jika Apple mempertahankan MacOS klasik 5 tahun lebih lama, atau Linux matang 5 tahun lebih cepat, transisi OS X bisa saja sangat berbeda. Namun membuang XNU demi kernel Linux sebelum 2.6 jelas tidak masuk akal.
    • Pada masa Apple mengakuisisi NeXT, Linux sedang giat dikembangkan dan belum benar-benar mapan. Karena Linux adalah kernel monolitik, ia juga tidak menyediakan tingkat kompartementalisasi seperti yang ditawarkan Mach.
      Dengan standar saat ini, FreeBSD memiliki banyak keunggulan Darwin sekaligus karakter open source ala Linux. Jika menginginkan lingkungan yang lebih aman tanpa ketergantungan Apple yang makin kuat, FreeBSD dan BSD lain juga layak dipertimbangkan sebagai target distribusi.
    • Menariknya, Apple berkontribusi dalam mem-porting Linux ke PowerPC Mac melalui proyek MkLinux yang dimulai pada 1996. Ini mendahului akuisisi NeXT pada akhir tahun itu:
      https://en.m.wikipedia.org/wiki/MkLinux
      Sepertinya tidak ada pekerjaan untuk membawa GUI Macintosh dan ekosistem aplikasinya ke Linux. Namun bahkan sebelum akuisisi NeXT, Apple sudah menjalankan lingkungan Macintosh di atas Unix lewat A/UX untuk 68k Mac, dan kemudian Macintosh Application Environment untuk Solaris serta HP-UX; yang terakhir menjalankan Mac OS sebagai proses Unix. Jika ingatan saya benar, pekerjaan Macintosh Application Environment menjadi dasar bagi Blue Box di Rhapsody, lalu lingkungan Classic di Mac OS X. Secara teori, mem-porting Macintosh Application Environment ke MkLinux juga bisa dibayangkan. Pada 1996, setelah penyelesaian gugatan terkait BSD, BSD bebas dan open source modern juga sudah ada.
      Tentu saja, pada pertengahan 1990-an menjalankan Mac OS klasik sebagai proses di atas OS modern seperti Linux, FreeBSD, BeOS, atau Windows NT tidak realistis sebagai strategi desktop konsumen. Itu membutuhkan sumber daya kelas workstation, sementara Apple masih mendukung 68k Mac, dan Mac OS 8 pun berjalan di sebagian perangkat 68030/68040. Pada era G3/G4 hal itu akan lebih realistis, dan pada 2000-an mungkin saja menjalankan tiap program Macintosh klasik sebagai proses Mac OS terpisah di atas OS modern. Namun tanpa kembalinya Jobs, Apple mungkin tidak akan melewati 1998. Selain itu, akuisisi NeXT juga membawa Cocoa, IOKit, Quartz (penerus Display PostScript), dan berbagai teknologi inti lain yang kini penting ke Mac.
    • Saya tidak mengerti mengapa kita harus menginginkan monokultur yang lebih parah. Sudah terlalu banyak telur ditempatkan dalam satu keranjang. Saya berharap kernel menjadi lebih beragam, bukan makin terkonsolidasi.
      Dilihat dari sudut lain, rasanya mirip dengan usulan agar Apple memindahkan Safari ke Chromium.
    • XNU hanya sebagian yang open source. Intinya memang terbuka, tetapi bagian penting seperti sistem file APFS tidak disertakan.
      Jika Apple mem-fork Linux, secara hukum mereka mungkin harus membuka semua modul kernel sebagai open source. Kemungkinan besar itu positif bagi umat manusia, tetapi mungkin bukan arah yang diinginkan Apple.

  • Artikel ini memuat banyak kecintaan dan kerja keras. Sebagai orang yang mengalami sebagian besar sejarah ini, pernah mem-porting kode NeXTSTEP ke Windows, mendalami upaya reimplementasi GNUStep, mengingat YellowBox dan OpenStep, membaca buku-buku tentang struktur internal, serta rutin mengikuti konten WWDC, isinya hampir sesuai dengan ingatan saya tentang bagaimana berbagai sistem berevolusi.

  • Jobs pernah mencoba merekrut Torvalds untuk mengerjakan Mac OS X, tetapi Linus menolak: https://www.macrumors.com/2012/03/22/steve-jobs-tried-to-hir...

    • Sulit membayangkan Torvalds justru mengerjakan mikrokernel.

  • Saya tidak yakin apakah I/O Kit ditulis dengan subset C++ ini hanya demi kecepatan. Saat itu ada kontroversi. Sebab ketika Apple mengumumkan MacOS X, mereka mengatakan bahwa itu tidak kompatibel dengan perangkat lunak yang ada, dan semua mitra harus menulis ulang dengan Objective-C.
    Karena responsnya buruk, Apple mundur dan memperkenalkan Carbon, lapisan API untuk aplikasi C++, serta Core Foundation, fondasi dasar bagi Foundation berbasis Objective-C. Inilah juga alasan adanya Obj-C++. Bagian yang menarik adalah mereka membuat manajemen memori menjadi toll-free bridging. Artinya, objek yang dialokasikan di dunia C/C++ dapat diteruskan ke Obj-C tanpa overhead tambahan.

    • IOKit C++ berjalan di kernel, jadi tidak terlalu berkaitan dengan teknologi yang disebutkan. Semua itu adalah teknologi khusus ruang pengguna.

  • Apple semestinya menumbuhkan komunitas bebas dan open source yang lebih baik di sekitar XNU. Bahkan sekarang setelah berpindah ke ARM, seharusnya tetap ada distribusi yang dapat berjalan di x64.

  • Saya memang ingin memahami Darwin sedalam ini, dan ini tulisan yang bagus

    • Mac OS X Internals karya Singh adalah salah satu buku favorit saya. Itu adalah analisis luar biasa yang membahas era Mac OS X 10.4 dengan sangat mendalam, jadi saya benar-benar berharap ada versi yang diperbarui
      Buku itu juga dikutip di akhir tulisan ini. Ini adalah materi yang akan bertahan lama dalam sejarah macOS
    • Saya juga ingin memahami Windows NT sedalam ini. Dengan melewatkan pembahasan Win32 dan membahas lapisan di bawahnya. Sejauh pemahaman saya, Win32 hanyalah salah satu personality, dan dulu ada Windows Services for UNIX pada era Windows XP serta Subsystem for UNIX-based Applications di Windows Vista
      Kernel NT yang menjadi dasarnya cukup fleksibel untuk memungkinkan kepatuhan POSIX, jadi tulisan yang membahas hal seperti ini pasti akan menarik

  • Rangkuman sejarah yang bagus, tetapi banyak pekerjaan keamanan hebat yang membedakan sistem operasi Apple dari Linux atau Windows terlewatkan. Tampaknya belum ada penilaian yang tepat tentang seberapa jauh Apple saat ini unggul dalam hal keamanan. Mungkin suatu hari persepsi ini akan makin kuat, dan orang-orang yang bekerja di lingkungan sensitif akan diwajibkan oleh CISO untuk memakai Mac
    Intinya adalah sistem code signing. Sistem ini dapat memberi hak akses kepada aplikasi atau mengurungnya dalam sandbox, dan memastikan penegakan itu benar-benar tetap berjalan. Apple tidak memakai ELF seperti kebanyakan UNIX, melainkan menggunakan format bernama Mach-O. Sebagian besar perbedaan antara ELF dan Mach-O tidak penting, tetapi yang penting adalah Mach-O mendukung section tambahan yang memuat direktori kode bertanda tangan. Direktori kode berisi hash untuk halaman-halaman kode, kernel memahami struktur data ini sampai taraf tertentu, dan dyld dapat menautkannya saat binary atau library dimuat. XNU memeriksa tanda tangan direktori kode, lalu subsistem VMM menghitung hash saat halaman kode dimuat ketika dibutuhkan dan memverifikasi apakah cocok dengan hash bertanda tangan di direktori tersebut. Karena itu, hash direktori kode dapat berfungsi seperti pengenal unik untuk program apa pun di ekosistem Apple. Ada satu bug di sini: keterkaitan ini bergantung pada struktur Mach vnode, sehingga jika binary bertanda tangan ditimpa lalu dijalankan, kernel akan marah dan mematikan proses meskipun tanda tangan file baru valid. Agar situasi baru dikenali, seluruh file harus benar-benar diganti
    Di atas fondasi ini, Apple menambahkan code requirements. Ini adalah program yang ditulis dalam bahasa ekspresi kecil untuk menyatakan batasan atas berbagai atribut code signature. Requirements dapat ditulis seperti “binary ini harus ditandatangani Apple”, “izinkan versi apa pun dari binary yang ditandatangani oleh subjek beridentitas X berdasarkan otoritas sertifikat Y”, atau “binary ini harus memiliki cdhash Z”, yakni harus persis binary itu. Binary juga dapat mengekspos designated requirement yang menunjukkan kepada pihak lain dengan requirement seperti apa ia ingin diidentifikasi. Awalnya ini tampak berlebihan, tetapi memungkinkan program mempertahankan identitas yang stabil dan tidak dapat dipalsukan sambil terus berevolusi
    Kernel mengekspos identitas tanda tangan sebuah task kepada task lain melalui port. Library di ruang pengguna dapat menafsirkan bahasa batasan itu dan menerapkan requirement pada port tersebut. Misalnya, ketika sebuah program menyimpan kunci di keychain sistem, daemon keychain yang diimplementasikan di ruang pengguna memeriksa designated requirement program yang mengirim RPC, lalu memastikan requirement itu cocok dengan permintaan penggunaan kunci berikutnya
    Sistem ini diabstraksikan sebagai entitlements. Entitlement adalah pasangan key=value yang menyatakan izin. Karena ini sistem terbuka, aplikasi juga dapat mendefinisikan entitlement sendiri, tetapi sebagian besar didefinisikan Apple. Sebagian bersifat opt-in murni: cukup diminta, lalu OS mengizinkannya secara otomatis dan diam-diam. Awalnya terlihat tidak berguna, tetapi ini memungkinkan App Store menjelaskan sebelumnya apa yang akan dilakukan aplikasi, dan secara lebih umum memungkinkan sikap least privilege agar aplikasi tidak bisa mengakses hal yang tidak diperlukannya. Sebagian membutuhkan bukti tambahan seperti provisioning profile. Ini adalah struktur data CMS bertanda tangan yang disediakan Apple, kira-kira berarti “aplikasi dengan designated requirement X boleh menggunakan entitlement terbatas Y”, jadi untuk memakainya harus mendapat izin Apple. Sebagian lain pada dasarnya disalahgunakan seperti sistem flag tanda tangan serbaguna dan tidak terkait dengan keamanan
    Sistem ini diperluas lagi lewat kerja sama ruang pengguna dan XNU. Kemampuan menandatangani binary barulah permulaan, dan banyak program juga memiliki file data. Di sini sistem keamanan Apple tampak agak seperti tambal sulam. Kernel tidak terlibat dalam pemeriksaan integritas file data. Sebagai gantinya, sebuah plist ditempatkan di lokasi khusus dalam struktur direktori bundle yang agak arbitrer; plist itu berisi hash per file untuk semua file data dalam bundle; hash plist dimasukkan ke dalam code signature; dan akhirnya Gatekeeper memeriksa semuanya saat pertama kali dijalankan. Kernel bertanya kepada Gatekeeper apakah program boleh dijalankan, dan Gatekeeper mengambil keputusan berdasarkan keberadaan extended attribute yang melekat pada file dan diteruskan oleh alat GUI seperti web browser atau alat ekstraksi arsip. Kode OS ruang pengguna seperti Finder membuat Gatekeeper dipanggil untuk memeriksa program saat pertama kali diunduh, lalu Gatekeeper menghitung hash semua file dalam bundle dan memeriksa apakah cocok dengan isi yang ditandatangani di binary. Karena itu di macOS muncul dialog “Verifying app” yang lambat saat pertama kali dijalankan. Ini tampaknya cara agar aplikasi yang membuka file data besar tanpa mmap tidak macet, tetapi di jaringan cepat, verifikasi Gatekeeper yang tidak dioptimalkan bisa lebih lambat daripada proses unduhan itu sendiri, jadi agak disayangkan. Apple tampaknya tidak terlalu peduli karena menganggap distribusi di luar store sebagai teknologi legacy
    Terakhir ada Seatbelt. Ini adalah bahasa pemrograman berbasis Lisp untuk menyatakan aturan sandbox. File-file ini dikompilasi di ruang pengguna menjadi semacam bytecode yang dievaluasi kernel. Bahasanya cukup canggih, sehingga bisa mengekspresikan aturan arbitrer tentang bagaimana berbagai komponen sistem saling berinteraksi dan apa yang boleh mereka lakukan, semuanya berdasarkan identitas code signing
    Dalam skema di atas ada lubang yang jelas dan baru ditutup pada rilis terbaru. File data dapat berisi kode, tetapi hanya diperiksa sekali. Aplikasi Electron atau JVM memang demikian karena memuat kode dalam format portabel. Karena itu, sebuah aplikasi bisa memodifikasi file data aplikasi lain untuk menyuntikkan kode dan melewati code signing. Di macOS terbaru, untuk mencegah hal ini Seatbelt melakukan sandboxing terhadap semua aplikasi yang berjalan. Sepengetahuan saya, di macOS modern tidak ada kode di luar sandbox. Salah satu kebijakan sandbox adalah mencegah aplikasi memodifikasi file data aplikasi lain tanpa izin. Kebijakannya cukup canggih: aplikasi yang ditandatangani oleh subjek hukum yang sama dan telah diverifikasi Apple dapat saling memodifikasi; aplikasi juga dapat mengizinkan modifikasi oleh aplikasi lain yang memenuhi code requirement; dan pengguna dapat memberi izin saat diperlukan. Untuk memeriksanya, buka Settings -> Privacy & Security -> App Management, matikan izin Terminal.app lalu mulai ulang, kemudian jalankan perintah seperti vim /Applications/Google Chrome.app/Contents/Info.plist. Meski permission file adalah rw, vim akan melihatnya sebagai read-only
    Mulai titik ini, karena saya tidak bekerja di Apple, pemahaman saya juga berakhir. Sepengetahuan saya kernel tidak memahami app bundle, dan saya juga tidak yakin bagaimana ia memutuskan apakah system call open() harus diubah menjadi read-only. Dugaan saya, kebijakan Seatbelt default membuat kernel melakukan upcall ke daemon keamanan yang tahu cara membaca format bundle dan basis data izin SQLite, lalu daemon itu membandingkan designated requirement pihak yang membuka file dengan bundle dan kebijakan yang dinyatakan sandbox untuk mengambil keputusan

  • Saya tidak berpikir nama keamanan tepat untuk fitur semacam itu
    Menurut saya, keamanan seharusnya selalu merujuk pada keselamatan pemilik atau pengguna komputer
    Fitur-fitur Apple seperti ini memang bisa dipakai untuk meningkatkan keamanan, tetapi tujuan desain utamanya adalah agar vendor yang menjual komputer dapat mengontrol lebih kuat bagaimana pemiliknya secara teori menggunakan perangkat yang seharusnya sudah bukan milik vendor itu lagi. Dengan kata lain, arahnya adalah memungkinkan Apple menentukan program apa yang boleh dijalankan oleh pengguna akhir