Maestro: Linux uyumluluğunu hedefleyen Rust tabanlı çekirdek
(blog.lenot.re)- Maestro, günlük kullanıma uygun olacak kadar Linux ile uyumlu, hafif bir Unix benzeri işletim sistemini Rust ile sıfırdan oluşturmayı amaçlayan bir projedir
- 2018’de bir okul projesi olarak başladı; başlangıçta C dili ile uygulanmıştı, ancak kod tabanını yönetme sorunları ve çekirdek geliştirmede güvenlik gereksinimleri nedeniyle Rust’a geçildi
- Şu anda x86 32 bit için monolitik bir çekirdektir; 437 Linux sistem çağrısının 135’i bir ölçüde uygulanmış durumda, bu da yaklaşık %31 seviyesidir
- Önyükleme sistemi ve daemon yöneticisi Solfège, sistem yardımcı araçları ve paket yöneticisi blimp de birlikte geliştiriliyor; musl, bash ve bazı GNU coreutils bileşenleri de çalışıyor
- Hâlâ çok erken aşamada olduğu için kararsızdır; testler ağırlıklı olarak QEMU, VMWare ve VirtualBox üzerinde yapıldığından, önemli veriler bulunan makinelere kurmamak daha güvenlidir
Maestro’nun hedefi ve çıkış noktası
- Maestro, Rust ile baştan yazılmış Unix benzeri bir işletim sistemidir
- Amaç, hafif ve günlük kullanıma imkân verecek kadar Linux ile yeterince uyumlu bir sistem oluşturmaktır
- Sistemi A’dan Z’ye doğrudan anlayabilecek ve istenen şekilde özelleştirebilecek bir ortam oluşturmak için başlatıldı
C’den Rust’a geçişin nedeni
- İlk commit 22 Aralık 2018 03:18 tarihinde yapıldı ve proje bir okul ödevi olarak başladı
- İlk uygulama yaklaşık bir buçuk yıl boyunca C dili ile yürütüldü, ancak kod tabanını temiz tutmak zorlaştı
- Rust ile yeniden başlamanın sağladığı avantajlar
- Önceki hatalardan öğrenilenlere dayanarak projeyi baştan yeniden tasarlayabilmek
- C ile Linux benzeri bir çekirdeği yeniden yazmaktan daha yeni denemeler yapabilmek
- Rust’ın tip sistemi sayesinde bellek güvenliğine ilişkin sorumluluğun bir kısmını programcı yerine derleyiciye bırakabilmek
Çekirdek geliştirmede Rust’ın avantajlı olduğu noktalar
- Çekirdek geliştirmede hata ayıklama, sıradan uygulamalara göre çok daha zordur
- Dokümantasyon bulmak zordur ve BIOS uygulamalarının kendisinde kusurlar olabilir
- Önyükleme sırasında çekirdek belleğin tamamına erişebildiği için kendi kodu gibi yanlış konumlara da yazabilir
- Bellek sızıntılarını izlemek için valgrind gibi araçlar kullanılamaz
- gdb, QEMU ve VMWare ile birlikte kullanılabilir; ancak çekirdeğin davranışı emülatöre veya sanal makineye göre değişebilir
- VirtualBox gibi gdb desteklemeyen ortamlar da vardır; QEMU ve VMWare’in gdb destek özelliklerinde de bazı eksikler bulunur ve gdb’nin çökebildiği durumlar olur
- Bu tür sorunları azaltmak için bellek güvenli bir dil çekirdek geliştirmede de avantaj sağlar
- Rust, çekirdeğe çeşitli güvenlik mekanizmaları eklemeye yardımcı oldu ve projedeki en iyi karar olarak değerlendiriliyor
Mevcut uygulama durumu
- Maestro şu anda monolitik bir çekirdektir ve yalnızca x86 32 bit mimarisini destekler
- Yazı anı itibarıyla uygulama durumu
- 437 Linux sistem çağrısının 135’i bir ölçüde uygulanmış durumda
- Sistem çağrısı uygulama oranı: {p:31}
- Tüm depolar toplamında 615 dosya ve 48.800 satır kod bulunuyor
- Satır sayısı
clockomutuyla hesaplandı
- Çekirdek dışındaki OS bileşenleri
- Solfège: systemd’ye bir ölçüde benzeyen, ancak daha hafif bir önyükleme sistemi ve daemon yöneticisi
- maestro-utils: sistem yardımcı komutları koleksiyonu
- blimp: paket yöneticisi
- Diğer bileşenler GitHub’da yayımlanmış durumda
- Çalıştığı doğrulanan üçüncü taraf yazılımlar
- musl C standart kütüphanesi
-
bash
ls,cat,mkdir,rm,rmdir,uname,whoamigibi bazı GNU coreutils komutları- Orijinal neofetch Maestro’yu tanımadığı için yamalanmış bir neofetch sürümü gerekiyor
Doğrudan test etme yöntemi ve kısıtlar
- OS hâlâ çok erken aşamada ve çok kararsızdır
- Önemli veriler bulunan bir makineye kurulması önerilmez
- Şimdiye kadar ağırlıklı olarak QEMU, VMWare ve VirtualBox üzerinde test edildi
- İki kurulum yöntemi vardır
- Önceden derlenmiş sıkıştırılmış
.isodosyasını indirmek - ISO’yu doğrudan derlemek
- Önceden derlenmiş sıkıştırılmış
- ISO, OS kurulum programını içerir ve QEMU, VMWare, VirtualBox gibi ortamlarda çalıştırılabilir
- ISO’yu çalıştırmak için yeterli RAM gerekir; 1 GB yeterlidir
- Çünkü kurulacak paketler diskte değil initramfs’in RAM alanında saklanır
- Mevcut OS, USB bellek veya CD-ROM’u doğrudan okuyamadığı için bootloader’a bağımlıdır
Yazıda ele alınacak konular
- Amaç bir OS yapımı öğreticisi yazmak değildir
- OS geliştirme temelleri için osdev.org ve Philipp Oppermann’s blog önerilir
- İleride daha ileri konular, sorun çözme süreçleri ve bilgisayarların, işletim sistemlerinin ve internetin içeride nasıl çalıştığı ele alınacak
Gelecekteki geliştirme yönü
- Öncelik kod tabanını düzenlemek ve performans optimizasyonudur
- Bir okul projesi olarak başladığı için takvime yetişmek amacıyla kestirme yolların seçildiği kısımlar var ve biriken teknik borcun ödenmesi gerekiyor
- Bazı bellek sızıntılarının da düzeltilmesi gerekiyor; performans optimizasyonu yazı konusu olabilir
- Sonraki büyük hedef, paket yöneticisinin OS üzerinde tamamen çalışmasını sağlamak
- Ağ desteği gerekiyor ve şu anda geliştiriliyor
- Paylaşımlı kütüphane desteği gerekiyor
- Paylaşımlı kütüphaneler dosyaların doğrudan belleğe eşlenmesini gerektirir, ancak mevcut çekirdeğin
mmapsistem çağrısı uygulaması bunu desteklemiyor
- Bundan sonra gcc/g++, clang, rustc, make, Git, Vim gibi programlar daha kolay kurulup test edilebilecek
- Nihai hedef, çekirdeği Maestro üzerinde geliştirme akışına ulaşmaktır
Çekirdeğin olgunluğunu artıran geliştirme süreci
- Geliştirme, programı çekirdek üzerinde çalıştırıp; çalışmazsa buna neden olan sistem çağrısını bulup uygulama veya düzeltme biçiminde ilerler
- Program çekirdek üzerinde çalıştırılır
- Çalışmazsa sistem çağrısı çıktısına bakılarak ilk soruna yol açan sistem çağrısı bulunur
- İlgili sistem çağrısı uygulanmamışsa veya hatalıysa uygulanır ya da düzeltilir
- Program yeniden çalıştırılır
- Çekirdek üzerinde ne kadar çok program doğru çalışırsa, çekirdek o kadar kararlı ve olgun hâle gelir
1 yorum
Hacker News yorumları
Destek verdiğiniz için gerçekten çok teşekkürler; bu projeye çok emek verdim, o yüzden benim için büyük anlam taşıyor
Şu anda web sitesi epey yavaş, hatta kapanmış gibi görünüyor; beklediğimden fazla trafik var ve bir DoS saldırısından da şüpheleniyorum
Şu an işteyim, bu yüzden hemen odaklanmam zor ama eve gidince daha iyi çalışacak şekilde düzeltmeye çalışacağım
2010'da, Rust henüz yokken, üniversiteden mezun olduktan hemen sonra C ile Unix benzeri hobi amaçlı bir OS üzerinde biraz uğraşmıştım ve gerçekten çok eğlenceliydi
Buraya kadar getirecek zamanı bulabilmiş olman kıskandırıcı
Gezinme çubuğu ekranın yaklaşık %33'ünü kaplıyor ve kaldırılamıyor
İnsanların neden böyle şeyleri sabitleyip değerli okuma alanını çaldığını anlamıyorum. İsteyen biri zaten yaklaşık 300 ms içinde en üste kaydırabilir
Küçük ve harika bir proje. Linux'un sistem çağrılarının üçte birini bile uygulamamışken bu kadar önyüklenebilmesi şaşırtıcı
Ama eksik olanların daha karmaşık parçalar olma ihtimali yüksek. Örneğin TTY katmanı şu anda oldukça temel seviyede görünüyor ve düzgün hale getirmek için çok iş gerekebilir
Bu yüzden önümüzdeki 3 yıl içinde Maestro'nun Linux uygulamaları çalıştırmasını beklemek zor. Linux'un sahip olduğu binlerce sürücüyü hesaba katmasak bile böyle
Olgun platformlar, birçok senaryoyu desteklemek için zamanla mantık katmanları biriktirir ve bu yüzden çoğu kullanım tüm sistemin büyük bölümüne ihtiyaç duymaz
Bu, “Kimse Excel'in %10'undan fazlasını kullanmaz ama herkesin kullandığı %10 farklıdır” sözüne benziyor
Excel işlevlerinin %30'unu uygularsan dünyadaki elektronik tabloların %99'unu açabilen bir motor yapabilirsin. Ama tam belge uyumluluğu istiyorsan daha gidilecek çok yol var
Bazı sistem çağrıları yalnızca belirli kod yollarında çağrılıyor olabilir ya da sadece daha yeni çekirdekleri hedeflerken gereken yeni çağrılar olabilir
Sistem çağrıları çok fazla ve içlerinde epey tuhaf olanlar da var. Tamamen açık bir alternatif uygulama olacaksa sonunda çoğunu desteklemek gerekir ama üçte bir iyi bir başlangıç
[1] VM'i bare metal üzerinde çalıştırmak ya da VM olarak önyüklemek istiyordum ve
init=/path/to/the/vmbenzeri bir şeyi saymazsak, bunun oraya en az emekle ulaşmanın yolu olduğu göründü. Ama bu yöntem benim gerçekten istediğim şeyi, yani donanım sürücülerini ve TCP yığınını VM dilinin içinde tutmayı sağlamıyorFaydalı olması için Steam, LibreOffice ya da Firefox çalıştırması gerektiğini sanmıyorum. Tipik sunucu veya mikroservis mimarilerindeki birçok bileşenin yaptığı iş nispeten basit ve güvenli, basit bir çekirdekten oldukça büyük fayda sağlayabilir gibi görünüyor
Rust ile yazılmış, tek çekirdekli ve Linux ABI uyumluluğunu hedefleyen Kerla da var. Ama birkaç yıldır uykuda gibi görünüyor
[1] https://news.ycombinator.com/item?id=28986229
Mikrokernel tasarımlı ve muhtemelen biraz daha olgun. MIT lisanslı olduğu için kod paylaşımı açısından da bir imkan olabilir
Sırf “Rust ile yazılmış” olması nedeniyle, yetenekli bir hacker'ın bir şeyler bulup bulamayacağını görmek için güvenlik/sızma testi/fuzzing yapmak eğlenceli olabilir
Fuzzing testi ya da sızma testi yapılırsa birçok sorun ortaya çıkacağına %100 eminim. Henüz buna zaman ayırma lüksüm olmadı
Sanırım bu, şu anda durdurulmuş olan Kerla projesinde zaten denenmiş bir şey
Eğlenceli bir proje gibi geliyor. Ama C kullanmanın dezavantajlarının ve OS geliştirmenin zorluğunun büyük kısmının debugging tarafında olduğunu düşünüyorum
Rust'a geçince belirli türde bellek hataları ortadan kalkmış olabilir ama debugging hâlâ aynı derecede acı verici mi? Yoksa önceye göre azalıp katlanılabilir hale geldi mi, merak ediyorum
Debugging hâlâ acı verici ama eskisine göre çok daha az
Örneğin mutex kullanmayı unutma ihtimalin yüksek değil; derleyici bunu hata olarak bildiriyor
Yani her şeye çare değil, deadlock gibi sorunlar hâlâ var. Özellikle araya kesme girdiğinde
Örneğin mutex'i kilitledin ve bir kesme olduysa, o mutex'i kilitleyen kod kesme bitene kadar durur. Ama kesme işleyici aynı mutex'i kilitlemeye çalışırsa deadlock oluşur ve tip sistemi bu tür sorunlarda yardımcı olamaz
Çözüm, mutex kilitliyken kesme işlemeyi devre dışı bırakmaktır ama derleyici bunu zorunlu kılamaz
Biraz konudan sapacağım ama yazarın katkı videosunda kullandığı Gource hoşuma gitti
Daha önce görmemiştim ama birkaç yıl önce buna benzer bir şey yapma fikrim olmuştu. Demek ki gerçekten tamamen yeni fikir diye bir şey yokmuş
Özellikle öğrenme amacıyla yapılıyorsa çekirdeği kendin yazma fikrini gerçekten seviyorum. Çekirdekleri ve genel olarak OS'leri anlamak için hangi kaynakları kullandığını merak ediyorum
Theseus OS'tan bahsedilmemesine şaşırdım. Rust ile sıfırdan yazılmış, üzerinde çalışılmaya devam edilen bir OS ve Rust derleyicisinin bellek güvenliği garantilerini kullanarak, klasik bir OS'te dikkatle tesisat döşer gibi uğraşmanız gereken birçok şeyi otomatik olarak sağlıyor
Örneğin tek ayrıcalık seviyesi ve tek adres alanı yapısına rağmen güvenli. OS'in bütün parçaları hot-plug yapılabiliyor
Dezavantajı, yerel kodun tamamının Rust olması gerekmesi ama geçen yıl bir WASM runtime'ı uygulandı. 3 yıl önceki ilgili başlık:
https://news.ycombinator.com/item?id=25741729
ft_penguin projesini üstlenecek kadar deli birinin çıkacağını düşünmemiştim. İsmi hâlâ bu mu emin değilim ama dürüst olmak gerekirse gerçekten çok iyi iş çıkarmışsın
7 yıl önce okuldayken bunun, gereken zamana kıyasla getirisi en düşük projelerden biri olduğunu düşünmüştüm
Başta bir arkadaşınla mı başladığını, Rust ile yeniden yazmadan önce nasıldı merak ediyorum. Aynı anda başka projeler de yapıyor muydun, onu da merak ediyorum
Koda bakınca eğlenceli günleri hatırladım; şimdi DevOps işini bırakıp asıl yapmak istediğim gömülü sistemler veya başka düşük seviye işlere yönelmek istiyorum