windows-drivers-rs - Rust ile Windows sürücü geliştirmeyi mümkün kılan platform

 (github.com/microsoft)
3 puan yazan GN⁺ 2023-09-25 | 3 yorum | WhatsApp'ta paylaş
  • Windows Drivers’ı Rust ile geliştirmeyi mümkün kılan bir Rust crate koleksiyonu olup, WDM ve WDF sürücü geliştirme modellerini desteklemeyi hedefler
  • Başlıca bileşenler; WDK derleme yapılandırması için wdk-build, WDK API’leri için doğrudan FFI bağları sunan wdk-sys, güvenli ve idiomatik WDK API bağları sağlayan wdk, panic handler için wdk-panic, alloc desteği için wdk-alloc ve wdk-sys doğrudan bağlarının kullanımını kolaylaştıran makro koleksiyonu wdk-macros'tur
  • WDM, KMDF, UMDF sürücüleri ve Win32 Services desteği düşünülerek hazırlanmıştır; ayrıca WDK 22H2 ve sonrasında yer alan tüm WDF sürümlerini desteklemeyi içerir
  • crates.io'da yayımlanan crate şu anda yalnızca KMDF v1.33 desteklemektedir; diğer yapılandırmalara ait bağlar, windows-drivers-rs klonlanıp wdk-sys içindeki build.rs ayarları değiştirilerek üretilebilir
  • Kullanım akışı; Cargo lib paketi oluşturma, wdk-build, wdk, wdk-sys, wdk-alloc, wdk-panic bağımlılıklarını ekleme, cdylib ayarı yapma, WDK metadata ayarlama, build.rs içinde wdk_build::configure_wdk_binary_build() çağırma, DriverEntry ekleme ve cargo make çalıştırmadan oluşur
    • Kernel Mode crate’leri olan KMDF ve WDM sürücülerinde panic stratejisi olarak abort, #![no_std] ve panic handler ayarı gerekir
    • Rust standart kütüphanesinin alloc modülünü kullanmak için wdk_alloc::WdkAllocator ile global allocator ayarı yapılmalıdır
  • Derleme gereksinimleri; bindgen için libclang, derleme sonrası işlemler için cargo-make ve geçerli bir WDK ortamıdır; önerilen yöntem eWDK developer prompt içine girmektir
  • cargo make, varsayılan davranışında sürücüyü derler ve paketler; sonuç olarak imzalı sürücü paketi ile WDRLocalTestCert.cer dosyası target/<Cargo profile>/package altında veya hedef mimari yolunda oluşturulur
  • cargo make default --target <TARGET TRIPLE>, --release, --features <FEATURES>, +<TOOLCHAIN> gibi argümanların iletilmesini destekler; ayrıca WDK_BUILD_ENABLE_SIGNTOOL_VERIFY=true ayarıyla üretilen .sys ve .cat dosyalarının imza doğrulama adımı etkinleştirilebilir
  • Yeni Cargo eklentisi cargo-wdk, Rust sürücüsü derlemede önerilen araç olarak cargo-makein yerini almak üzere geliştirilen bir Preview durumundadır
  • WDM, KMDF ve UMDF için minimum örnekler examples dizininde bulunur; sürücü oluşturma örnekleri ise Windows-rust-driver-samples içinde görülebilir
  • Hâlâ geliştirmesinin erken aşamasındadır ve production use için henüz önerilmemektedir

İlgili okumalar

3 yorum

 
GN⁺ 2023-09-25
Hacker News yorumları

  • Hatırlamayanlar için: Mark Russinovich, patronunun koltuğunu devralıp bir sonraki MSFT CEO adayı olarak anılmadan önce, Redmond mühendislerinin NT kernel geliştirmeyi öğrenmek için gittiği bir yazılım araçları ve NT kernel danışmanlık şirketi işletiyordu.
    Ayrıca Sony'nin DRM rootkit'ini, Symantec'in rootkit benzeri dosya koruma özelliğini ortaya çıkardı; Best Buy'ın ERD Commander'ı korsan kullandığını da yakaladı.
    2014'te LinkedIn'i uçurmuş olmam şimdi biraz içime oturuyor. Tüm Valley ve Mark'ın birinci derece bağlantı olduğu hesaptı; yine de görece tanınmamanın özgürlüğü ve çevikliği var. Ne kadar yaptığını, kazandığını ve kimi tanıdığını anlatmanın anlamsız olduğuna dair Desmond Dekker reggae şarkısı hangisiydi?

    • Apple da benzer bir şey yapmış gibi. Dahili Apple belgeleri, Jonathan Levin'in kitapları yanında pek bir şey sayılmadığından, Apple'ın OS mühendisleri için bu kitapları sık sık satın aldığı söyleniyor.
      Bu ölçekteki şirketlerin gerçek kaynak koduna ve mühendislere erişim gibi çok daha avantajlı bir konumda olmasına rağmen bunu kendi başlarına iyi yapamamaları oldukça ilginç. Bu üçüncü taraflar, en azından Levin, büyük ölçüde tersine mühendisliğe dayanmak zorundaydı.
      https://newosxbook.com
    • Ondan bahsederken Sysinternals'ı es geçmek olmaz. Günlük işimde o araç setine güveniyorum.
      Dünyada Windows kullanan neredeyse her şirketin en az bir Sysinternals aracı kullandığını düşünürsek, Sysinternals'ın etkisi belki Azure'un kendisinden bile büyük olmuş olabilir.
    • Sysinternals araçları her Windows kurulumuna varsayılan olarak dahil edilmeli. Benim ortamımda vazgeçilmezler; arkadaşların bilgisayarını tamir ederken ya da debug ederken yoklukları gerçekten hissediliyor.
      MSFT'nin Mark Russinovich ve ekibini acquihire etmesinin nedeni de bu değil miydi zaten?
    • İyi bir programcı ama kitaplarını okuyunca iyi bir CEO olacağını sanmıyorum.
      İlk kitabından edindiğim izlenim, dünyayı aşırı siyah-beyaz gördüğüydü.

  • Orijinal tweet: https://twitter.com/markrussinovich/status/17057307039574058...

  • Güzel /s ama bu pek Rust'a özgü değil:
    pub struct QueueContext {
    buffer: PVOID,
    length: usize,
    timer: wdf::Timer,
    current_request: WDFREQUEST,
    current_status: NTSTATUS,
    spin_lock: wdf::SpinLock,
    }

    • Bunların çoğu eninde sonunda FFI tamsayı tiplerine işaret ediyor. Windows sürücü API'si böyle kullanıldığı için.
      Linux kernel'ında Rust sürücü yazarken de benzer bir sorun var; C ile birlikte çalışan diğer projelerde de aynı.
      NTSTATUS gibi tiplerin üzerinde epey dokümantasyon var. C veya C++'ın aksine, Rust'ta bir tamsayı değerini enum değerine öylece atayamazsınız. Bir wrapper sınıfı oluşturup her seferinde cast ettirebilirsiniz ama o zaman kodun yarısı .into() olur ve sürücüye ek yük getirme ihtimali de yüksek.
      Görünüşe göre buffer için void* dışında bu enum değerlerini ayarlamıyor ya da değiştirmiyorlar; sadece okuyorlar. NTSTATUS için bir match {} bloğu yeterli olur gibi. WDFREQUEST bir handle olduğu için, aynı tipte başka bir handle ile değiştirmek dışında yapabileceğiniz pek bir şey de yok.
      Timer ve SpinLock, unsafe kütüphane çağrılarını içinde saran Rust tarzı nesnelere dönüştürülmüş. Bunun dışında, ciddi bir performans maliyeti olmadan bu kodu daha Rust'a özgü hale getirmenin yolu pek görünmüyor.
    • Onu ortadan kaldırmak için her şeyi baştan yazmak gerekir gibi.

  • Daha iyisi ne olur biliyor musun? Aygıt sürücülerini C# gibi bellek yönetimli bir dilde yazmak.

    • Microsoft giderek daha fazla kodu kullanıcı alanına itiyor. Güncel değişikliklerden biri, yazıcı üreticilerinin yazıcılara özel işlev eklerken sürücü yerine UWP yazıcı uygulaması kullanmasını şart koşması. Bu tür uygulamalar genelde C# gibi dillerle yazılıyor.
      Kernel'ı daha kolay erişilebilir hale getirmektense, kernel içinde üretici kodunu daha az çalıştırmanın en iyi yol olduğu yönündeki Microsoft kararına katılıyorum. C#, “bir buffera erişmek istiyorum ama henüz page-in edilmemiş ve ben bir interrupt handler içindeyim” gibi durumlara uygun değil; bu yüzden kernel'da garbage collector'ı hatasız çalıştırmak neredeyse imkânsız görünüyor.
    • Gerçekten daha iyi olur mu bilmiyorum. Sürücü geliştirme deneyimim yok ama aygıt sürücüleri, çalışan işletim sisteminin düşük seviyeli çekirdek bileşenleri olduğundan, garbage collection'ın kendi takvimine göre yürütmeyi kesmesiyle pek uyumlu görünmüyor.
    • Sürücünün garbage collector çalıştırmak için durup farenin teklemesini istemem.
    • Microsoft bunu zaten denedi ama feci şekilde başarısız oldu. Sanırım nedenini açıklamadılar; ancak 2000'lerin başındaki donanımlarda garbage collection yüzünden duraklamalar çok fazla olurdu diye düşünüyorum.
    • C++ ile bile pageable kernel driver yazabilme yeteneğini koruyarak aygıt sürücüsü yazmak çok zor.
      Sürücüler, örneğin interrupt handler sırasında olduğu gibi page fault'un mümkün olmadığı anlarda belleğe erişebileceğinden, bellek kullanılabilirliğini çok sıkı kontrol etmek gerekir. C# dili ve runtime'ı en azından bunu açıkça ele alacak özellikler eklemeli.
 
bungker 2023-11-30

Bence biraz küçümseniyor, o yüzden eklemek istiyorum. Russinovich, Windows çekirdeğiyle ilgili sayısız kaynak ve araç üretmiş bir kişidir. Windows çekirdeğiyle ilgili geliştiriciler arasında (rootkit geliştirenler dahil) Russinovich’in kaynaklarını ya da belgelerini inceleyerek çalışmamış neredeyse kimse yoktur diye düşünüyorum.
 
botplaysdice 2023-12-01

Windows çekirdeğinin Rust ile yeniden yazıldığına dair konuşmalar vardı; sonunda sürücü SDK'sı da çıkıyor demek. Yakında 20XX yılından itibaren sürücüleri Rust ile yapın diye bir duyuru gelebilir gibi görünüyor.