Apple Silicon'da 2 sanal makine sınırını aşma yöntemi (2023)

• Apple Silicon tabanlı macOS, Virtualization.framework ile çalıştırılabilen macOS VM'lerini en fazla 2 adetle sınırlar ve bu sınır macOS lisans sözleşmesindeki bir maddeye dayanır
• Analiz sonucunda bu sınırın XNU çekirdeği içindeki özel hv_apple_isa_vm_quota değişkeni tarafından yönetildiği ve önyükleme argümanlarıyla geçersiz kılınabildiği doğrulandı
• System Integrity Protection içindeki AppleInternal kontrolünü aşmak için geliştirme çekirdeği (Development Kernel) derleyip önyükleme prosedürü kullanıldı
• Ayarlardan sonra UTM, Viable, Parallels gibi araçlarda aynı anda en fazla 9 macOS VM çalıştırma başarıyla gerçekleştirildi
• Apple'ın çekirdek içinde VM sınırını geçersiz kılma işlevini bırakmış olması dikkat çekiyor; gelecekte otomasyon araçları veya çekirdek eklentileriyle iyileştirme olasılığı öne sürülüyor

---

Apple Silicon'da macOS sanal makinesi için 2 adetlik sınırın kaldırılma süreci

• Apple Silicon tabanlı Mac'lerde Virtualization.framework kullanarak macOS sanal makinesi çalıştırırken en fazla yalnızca 2 adet çalıştırılabilen bir sınır bulunuyor
  • Bu sınır, macOS yazılım lisans sözleşmesinin (SLA) 2.B.iii maddesi uyarınca konulmuş durumda
  • İlgili madde; geliştirme, test, macOS Server kullanımı ve ticari olmayan kişisel kullanım için en fazla 2 macOS örneğinin çalıştırılmasına izin veriyor
• Analiz sonucunda bu sınırın kullanıcı alanında değil, çekirdeğin (XNU) özel bölümünde uygulandığı görüldü
  • Intel çekirdeğinde aynı kod bulunmuyor; Apple Silicon çekirdeğindeki hv_vm_* işlev ailesi sanallaştırma yığınından sorumlu
  • hv_init() başlatma kodundaki hv_apple_isa_vm_quota değişkeni VM sayısını yönetiyor ve VM oluşturma/silme sırasında artırılıp azaltılıyor
  • Çekirdekte hypervisor= ve hv_apple_isa_vm_quota= önyükleme argümanları bulunuyor; ikincisi VM sınırını geçersiz kılabiliyor
• Sürüm çekirdeğinde hypervisor argümanı yerine kısıtlama System Integrity Protection (SIP) içindeki AppleInternal kontrolü ile sağlanıyor
  • CSR_ALLOW_APPLE_INTERNAL bayrağı yalnızca etkin olduğunda hv_apple_isa_vm_quota argümanı uygulanıyor
  • Bunu aşmak için Apple'ın geliştirme çekirdeğini (Development Kernel) önyükleme yöntemi kullanıldı

Geliştirme çekirdeği koleksiyonunu derleme

• Apple Developer sitesinden Kernel Debug Kit (KDK) indirilip kurulmalı
  • KDK'nin ana macOS derlemesiyle tam olarak eşleşmesi gerekiyor; eşleşmezse çekirdek ve kext bağlama ile önyükleme hataları oluşabilir
• uname komutuyla çekirdek mimarisi kontrol edildikten sonra kmutil create komutu kullanılarak geliştirme çekirdeği koleksiyonu (VirtualMachine.kc) oluşturuluyor
  • Örnekte macOS 14.0 (derleme 23A5301h) ve T6020 çekirdeği kullanılıyor
  • --variant-suffix development seçeneğiyle geliştirme çekirdeği belirtiliyor ve birden çok sistem uzantısı deposu ekleniyor

Geliştirme çekirdeği için önyükleme ayarları

• Mac kapatıldıktan sonra kurtarma modu (recoveryOS) ile açılıp Terminal'de şu ayarlar yapılıyor
  1. System Integrity Protection'ı devre dışı bırakma (csrutil disable)
  2. Önyükleme argümanı kısıtlamasını kaldırma (bputil --disable-boot-args-restriction)
  3. Özel çekirdek koleksiyonunu belirtme (kmutil configure-boot)
  4. Önyükleme argümanlarını ayarlama (nvram komutuyla iletilir)
     • kcsuffix=development : geliştirme çekirdeğiyle önyükleme
     • hypervisor=0x1 : sanallaştırma yığınının özel işlevlerini etkinleştirme
     • hv_apple_isa_vm_quota=0xFF : VM için azami sayıyı 255 olarak ayarlama
• Yeniden başlatmanın ardından sysctl kern.osbuildconfig ve nvram boot-args ile uygulanıp uygulanmadığı doğrulanabiliyor

Birden çok VM çalıştırma sonucu

• Kurulum tamamlandıktan sonra UTM, Viable, Parallels gibi Virtualization.framework tabanlı çözümlerle test yapıldı
  • M2 Pro MacBook Pro üzerinde aynı anda 9 macOS VM çalıştırma başarısı elde edildi
  • Sistem yine de test edilebilir düzeyde çalışmayı sürdürdü

Özelliğin eklendiği dönem ve iç yapı

• macOS 12 Monterey ile birlikte hv_apple_isa_vm_quota önyükleme argümanı sanallaştırma yığınıyla beraber eklendi
  • Sonraki sürümlerde de (macOS Sonoma dahil) AppleInternal kontrolü hâlâ mevcut
  • Apple'ın XNU içinde çeşitli özel işlevleri koruduğu doğrulandı

OS güncellemelerinde dikkat edilmesi gerekenler

• Özel çekirdek koleksiyonu kullanıldığında otomatik OS güncelleme özelliği devre dışı kalıyor
  • Güncelleme sonrası hata oluştuğundan varsayılan çekirdek koleksiyonuna geri dönmek gerekiyor
  • Kurtarma modunda bputil ile yeni önyükleme ilkesi oluşturularak varsayılan çekirdeğe dönülebiliyor
  • Örnek: bputil --full-security veya --disable-boot-args-restriction seçenekleri kullanılabilir

Sonuç ve gelecekteki iyileştirme fikirleri

• Apple'ın VM sınırını uygulama biçimi doğrulandı ve resmî olmayan da olsa sınırı kaldırma yöntemi deneysel olarak kanıtlandı
  • Virtualization ekibi bunu resmen belgelendirmemiş olsa da VM sınırını geçersiz kılma işlevinin çekirdekte bırakılmış olması dikkat çekici
• Gelecekte düşünülen iyileştirmeler
  • KC derleme ve önyükleme otomasyon aracı geliştirme
    • Ana sisteme göre geliştirme çekirdeği koleksiyonunu otomatik oluşturma ve kurtarma modu ayarlarını destekleme
  • Çekirdek eklentisi (kext) ile hv_apple_isa_vm_quota değişkenini geçersiz kılma işlevi geliştirme
    • Geliştirme çekirdeğiyle önyükleme yapmadan sınırı kaldırma olasılığını araştırma
• Bir sonraki araştırma konusu olarak Apple Silicon VM'lerinde DEP kaydı ve seri numarası geçersiz kılma olasılığı incelenecek

[GN⁺]

Hacker News görüşleri

• Tüm Mac’lere aynı şekilde uygulanan böyle bir sınır çok mantıksız
  Daha güçlü bir Mac aldıysan daha fazla macOS örneğini sanallaştırabilmen gerekir
  Örneğin M5 için 2, M5 Pro için 4, M5 Max için 8 gibi bir sınır koymak daha makul olurdu

  • Neden en başta bir sınır koyduklarını anlamıyorum
    Donanım performansı zaten doğal sınırdır; kullanıcı kendi kendine duracaktır
  • Bu daha çok bir kaynak meselesinden ziyade iş kararı gibi görünüyor
    Ucuz Mac VPS hizmetlerini engellemeye yönelik bir adım olması muhtemel
  • Bu donanımsal bir sınır değil, Tim Cook’un satış kaygılarıyla mücadele etmek demek
  • 100 dolara Windows 11 Pro lisansı alırsan VM sınırı 1024 oluyor
    Hyper‑V, donanım kaldırabildiği sürece aynı anda en fazla 1024 VM çalıştırabiliyor
    Benim küçük Windows ARM dizüstü bilgisayarımda bile 4 tanesi sorunsuz çalışıyor
  • Gerçekten saçma
    openclaw’ı test etmek için VM çalıştırdım ama iCloud ve App Store erişimi kısıtlı olduğu için afalladım

• Mykola Grymalyuk’un bu blog yazısını yazdıktan 2 yıl sonra Apple’a katılmış olması ilginç
  İnsanın aklına “ya kahraman olarak ölürsün ya da…” mem’i geliyor

• M3 ve sonrasında Hypervisor.framework / Virtualization.framework kullanarak nested VM çalıştırılabiliyor
  Bu sınırı aşmaya yarıyorsa epey ilginç olabilir

  • Hatırladığım kadarıyla yalnızca Linux guest’lerde iç içe çalıştırma mümkün
    macOS sadece tek seviye destekliyor; yani bir macOS guest içinde başka bir macOS guest başlatmak mümkün değil
  • Eğer her VM 2 VM çalıştırabiliyorsa, sonsuz VM zinciri bile kurulabilir
    Üşeniyorum ama keşke biri denese

• Apple’ın neden böyle bir sınır koyduğunu gerçekten merak ediyorum

  • Apple’ın iş modeli, donanım ve yazılımı paket halinde satmak üzerine kurulu
    Donanım satışları yazılım geliştirmeyi finanse ettiği için, donanımını satın almayan insanların macOS kullanmasını istemiyor
  • macOS’te bu tür kullanıcı kısıtlamaları çok fazla
    Kullanıcı özgürlüğünden çok Apple’ın kontrolü elinde tutması öncelikli
  • Belki de tek bir Mac ile çevrimiçi hesap çiftliği (identity farm) işletilmesini engellemek için yapılmıştır

• Özel bir kernel derleyip sistemi açabilmeleri ve hatta GUI’ye kadar getirebilmeleri şaşırtıcı

• Yazının kendisi gerçekten çok ilginç ama böyle keyfi kısıtlamaları olan bir platformu geliştirme için kullanmak tuhaf

  • Son 20 yılda Apple’ın gerçekten ciddi bir geliştirme platformu olup olmadığı şüpheli
    Birçok geliştirici üst düzey donanımı için kullanıyor ama macOS her zaman “neredeyse Linux olan ama iTunes merkezli bir şirketin kontrol ettiği bir işletim sistemi” gibiydi

• Apple Silicon’da özel kernel collection kullanılırsa otomatik OS güncellemelerinin mümkün olmadığı söyleniyor
  Ama bu belki de bir gizli nimet olabilir

• Bunun lume’da da çalışıp çalışmayacağını merak ediyorum
  Şu anda benzer bir sınır var

  • Muhtemelen çalışır
    Bildiğim kadarıyla lume, Apple’ın Virtualization.framework’ünü saran ince bir sarmalayıcı

• SIP’yi kapatıp boot argümanlarını ayarlarsan özel kernel olmadan da mümkün olduğunu duymuştum

  • Eğer doğruysa bu gerçekten hak ettiği değeri görmeyen bir ipucu

• Apple VM sayısını 2 ile mi sınırladı?

  • Evet, macOS VM’leri lisans gereği en fazla 2 adet olabiliyor
    Diğer OS guest’leri ise sınır olmadan çalıştırılabiliyor