windows-drivers-rs - Rust में Windows ड्राइवर डेवलपमेंट को संभव बनाने वाला प्लेटफ़ॉर्म

• यह Rust crate के संग्रह है, जो Windows Drivers को Rust में विकसित करने में सक्षम बनाता है, और WDM तथा WDF ड्राइवर डेवलपमेंट मॉडल के समर्थन को लक्ष्य करता है
• इसके मुख्य घटक हैं: WDK build configuration के लिए wdk-build, WDK API के direct FFI bindings के लिए wdk-sys, सुरक्षित और idiomatic WDK API bindings के लिए wdk, panic handler के लिए wdk-panic, alloc समर्थन के लिए wdk-alloc, और wdk-sys direct bindings के उपयोग में मदद करने वाले macro संग्रह wdk-macros
• इसे WDM, KMDF, UMDF ड्राइवर और Win32 Services समर्थन को ध्यान में रखकर बनाया गया है, और इसमें WDK 22H2 या उससे ऊपर में शामिल सभी WDF versions का समर्थन शामिल है
• crates.io पर प्रकाशित crate इस समय केवल KMDF v1.33 को समर्थन देते हैं, जबकि अन्य कॉन्फ़िगरेशन के bindings windows-drivers-rs को clone करने के बाद wdk-sys के build.rs configuration में बदलाव करके जनरेट किए जा सकते हैं
• उपयोग का flow इस प्रकार है: Cargo lib package बनाना, wdk-build, wdk, wdk-sys, wdk-alloc, wdk-panic dependencies जोड़ना, cdylib सेट करना, WDK metadata configure करना, build.rs में wdk_build::configure_wdk_binary_build() कॉल करना, DriverEntry जोड़ना, और फिर cargo make चलाना
  • Kernel Mode crate जैसे KMDF और WDM ड्राइवरों के लिए panic strategy abort, #![no_std], और panic handler configuration आवश्यक है
  • यदि Rust standard library के alloc module का उपयोग करना है, तो wdk_alloc::WdkAllocator global allocator सेट करना आवश्यक है
• build requirements में bindgen के लिए libclang, post-build कार्यों के लिए cargo-make, और एक वैध WDK environment शामिल हैं; अनुशंसित तरीका eWDK developer prompt में प्रवेश करना है
• cargo make डिफ़ॉल्ट रूप से ड्राइवर को build और package करता है, और परिणामस्वरूप signed driver package तथा WDRLocalTestCert.cer फ़ाइल target/<Cargo profile>/package या target architecture path के अंतर्गत बनती है
• यह cargo make default --target <TARGET TRIPLE>, --release, --features <FEATURES>, +<TOOLCHAIN> जैसे arguments पास करने का समर्थन करता है, और WDK_BUILD_ENABLE_SIGNTOOL_VERIFY=true सेट करके बने हुए .sys और .cat फ़ाइलों के signature verification को सक्षम किया जा सकता है
• नया Cargo extension cargo-wdk अभी Preview अवस्था में विकसित किया जा रहा है, ताकि Rust ड्राइवर build के लिए अनुशंसित टूल के रूप में cargo-make की जगह ले सके
• WDM, KMDF, UMDF के न्यूनतम उदाहरण examples directory में हैं, और ड्राइवर बनाने के उदाहरण Windows-rust-driver-samples में देखे जा सकते हैं
• यह अभी शुरुआती विकास चरण में है और production use के लिए अभी अनुशंसित नहीं है

[GN⁺]

Hacker News की राय

• जिन्हें याद नहीं है, उनके लिए: Mark Russinovich, अपने बॉस की जगह लेने और अगले MSFT CEO उम्मीदवार के रूप में चर्चा में आने से पहले, एक software tools और NT kernel consulting कंपनी चलाते थे, जहाँ Redmond के engineers NT kernel development सीखने जाते थे
  उन्होंने Sony के DRM rootkit, Symantec के rootkit जैसे file-protection फीचर भी पकड़े, और Best Buy द्वारा ERD Commander की गैरकानूनी कॉपीिंग भी सामने लाई
  2014 में LinkedIn को उड़ा देना अब थोड़ा अफसोसजनक लगता है। वह ऐसा account था जिसमें पूरी Valley और Mark first-degree connection में थे, लेकिन फिर भी अपेक्षाकृत अनाम रहने में आज़ादी और फुर्ती होती है। वह Desmond Dekker का reggae गाना कौन-सा था जिसमें कहा गया था कि आपने कितना किया, कितना कमाया और किसे जानते हैं, यह बखानना बेकार है

  • लगता है Apple ने भी कुछ ऐसा ही किया था। अंदरूनी Apple documents Jonathan Levin की किताबों के मुकाबले कुछ खास नहीं थे, इसलिए कहा जाता है कि Apple ने OS engineers के लिए वे किताबें अक्सर खरीदीं
    यह काफी दिलचस्प है कि उस पैमाने की कंपनियाँ, जिनके पास actual source code और engineers तक access जैसी कहीं बेहतर स्थिति होती है, फिर भी ऐसी चीजें खुद ठीक से नहीं कर पातीं। इन third parties को, कम से कम Levin को, काफी हद तक reverse engineering पर निर्भर रहना पड़ा
    https://newosxbook.com
  • उनके बारे में बात करते हुए Sysinternals को छोड़ा नहीं जा सकता। रोज़मर्रा के काम में मैं उस tool suite पर निर्भर रहता हूँ
    अगर यह सोचें कि दुनिया भर में Windows इस्तेमाल करने वाली लगभग हर कंपनी कम से कम एक Sysinternals tool इस्तेमाल करती है, तो Sysinternals का असर शायद Azure खुद से भी बड़ा रहा होगा
  • Sysinternals tools हर Windows installation में default शामिल होने चाहिए। मेरे setup में ये अनिवार्य हैं, और दोस्तों के कंप्यूटर ठीक या debug करते समय इनके बिना सच में कमी महसूस होती है
    शायद इसी वजह से MSFT ने Mark Russinovich और उनकी team को acquihire किया होगा
  • वे अच्छे programmer हैं, लेकिन उनकी किताब पढ़कर नहीं लगता कि वे अच्छे CEO बनेंगे
    पहली किताब से मुझे यह impression मिला कि वे दुनिया को बेहद black-and-white तरीके से देखते हैं

• मूल tweet: https://twitter.com/markrussinovich/status/17057307039574058...

  • कम खराब link:
    http://farside.link/twitter.com/markrussinovich/status/17057...

• बढ़िया /s है, लेकिन यह Rust जैसा नहीं है:
  pub struct QueueContext {
  buffer: PVOID,
  length: usize,
  timer: wdf::Timer,
  current_request: WDFREQUEST,
  current_status: NTSTATUS,
  spin_lock: wdf::SpinLock,
  }

  • इनमें से ज़्यादातर आखिरकार FFI integer types की ओर इशारा करते हैं। Windows driver API इसी तरह इस्तेमाल होती है
    Linux kernel में Rust driver लिखते समय भी ऐसी ही समस्या होती है, और C के साथ interop करने वाले दूसरे projects में भी यही बात है
    NTSTATUS जैसे types के साथ काफी documentation जुड़ी होती है। C या C++ के विपरीत, Rust में integer values को सीधे enum values में assign नहीं किया जा सकता। wrapper class बनाकर हर बार cast करवाया जा सकता है, लेकिन तब आधा code .into() हो जाएगा और driver में overhead आने की संभावना भी बड़ी है
    देखने में, buffer के लिए void* जैसी चीज को छोड़कर, इन enum values को set या modify नहीं किया जा रहा, सिर्फ read किया जा रहा है। NTSTATUS के लिए match {} block काफी होना चाहिए। WDFREQUEST एक handle है, इसलिए उसी type के दूसरे handle से बदलने के अलावा इससे बहुत कुछ किया भी नहीं जा सकता
    Timer और SpinLock को unsafe library calls को अंदर wrap करने वाले Rust-जैसे objects में बदला गया है। इसके अलावा, बिना काफी performance cost के इस code को और ज्यादा Rust-जैसा बनाने का तरीका साफ नहीं दिखता
  • लगता है इसे हटाने के लिए सब कुछ फिर से लिखना पड़ेगा

• जानते हैं बेहतर क्या है? C# जैसी memory-managed language में device drivers लिखना

  • Microsoft ज्यादा से ज्यादा code को user space में धकेल रहा है। हालिया बदलावों में, printer manufacturers से कहा जा रहा है कि printer में custom features जोड़ते समय drivers के बजाय UWP printer apps इस्तेमाल करें। ऐसे apps आम तौर पर C# जैसी languages में लिखे जाते हैं
    kernel को ज्यादा आसानी से accessible बनाने के बजाय, kernel के अंदर manufacturer code कम चलाना ही बेहतर है—Microsoft के इस निष्कर्ष से मैं सहमत हूँ। C# “मुझे किसी buffer तक access चाहिए, लेकिन वह अभी page in नहीं हुआ है, और मैं interrupt handler के अंदर हूँ” जैसी स्थितियों के लिए उपयुक्त नहीं है, इसलिए kernel में garbage collector को bug-free चलाना लगभग असंभव लगता है
  • पक्का नहीं कि यह सच में बेहतर होगा। driver development का अनुभव नहीं है, लेकिन device drivers चल रहे operating system के low-level core components होते हैं, इसलिए garbage collection का अपने schedule पर execution रोकना इससे अच्छा मेल खाता नहीं दिखता
  • मैं नहीं चाहूँगा कि driver garbage collector चलाने के लिए रुक जाए और mouse अटकने लगे
  • Microsoft ने पहले ही कोशिश की थी, लेकिन बुरी तरह असफल रहा। मुझे नहीं लगता उन्होंने वजह बताई थी, लेकिन मेरा मानना है कि 2000s की शुरुआती hardware पर garbage collection की वजह से बहुत ज्यादा pauses आए होंगे
  • C++ में भी pageable kernel drivers लिखने की क्षमता बनाए रखते हुए device drivers लिखना बहुत कठिन है
    driver को memory availability पर बहुत सख्त control रखना पड़ता है, क्योंकि वह ऐसे समय में भी memory access कर सकता है जब page fault संभव नहीं होता, जैसे interrupt handler के दौरान। C# language और runtime को कम से कम इसे explicitly handle करने की capabilities जोड़नी पड़ेंगी

[bungker]

मुझे लगता है कि इसकी थोड़ी कम सराहना हो रही है, इसलिए यह जोड़ रहा हूँ। Russinovich वह व्यक्ति हैं जिन्होंने Windows kernel से जुड़ी असंख्य सामग्री और tools बनाए हैं। Windows kernel से जुड़े डेवलपर्स में — rootkit बनाने वाले डेवलपर्स सहित — शायद ही कोई ऐसा होगा जिसने Russinovich की सामग्री या दस्तावेज़ों को देखकर अध्ययन न किया हो।

[botplaysdice]

सुना था कि Windows kernel को Rust में दोबारा लिखा जा रहा है, और अब आखिरकार driver SDK भी आ रहा है। लगता है जल्द ही 20XX से यह घोषणा भी आ जाएगी कि drivers Rust में ही बनाओ।