मेमोरी सुरक्षा के कट्टर समर्थक

 (itsallaboutthebit.com)
1 पॉइंट द्वारा GN⁺ 2 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • सिर्फ unsafe की मौजूदगी के आधार पर Rust को खारिज करना और सिर्फ Fil-C को सुरक्षित मानने वाला मानदंड असली सॉफ्टवेयर के दायरे और तकनीकी trade-offs को नजरअंदाज करता है
  • Fil-C C/C++ की गलत memory access को panic में बदल देता है, लेकिन इसके साथ ABI incompatibility, कुछ स्थितियों में कई गुना performance गिरावट, और GC अपनाने जैसी लागतें आती हैं
  • Android के लगभग 50 लाख lines के Rust code में रिलीज से पहले ठीक की गई 1 संभावित memory safety vulnerability मिली, जिसका अनुमान 10 लाख lines पर 0.2 cases है; यह C/C++ के पुराने data, लगभग 1,000 cases, से 1,000 गुना से भी कम था
  • हर program में 99.9% समस्याएं रोकने वाली तकनीक और 90% programs में 100% समस्याएं रोकने वाली तकनीक में से सिर्फ एक चुनना जरूरी नहीं है; जिन software में Fil-C की सीमाएं स्वीकार करना मुश्किल है, उनके लिए Rust जैसे alternatives उपयुक्त हैं
  • Memory safety में performance·ABI·GC·data race prevention को साथ में देखना चाहिए; अगर Rust को भी अपर्याप्त कहकर आलोचना की जाती है, तो सामान्य C/C++ और non-Fil-C Zig पर कम से कम वही मानदंड लागू होने चाहिए

Rust और मौजूदा system languages का responsibility model

  • non-GC system programming languages में memory safety की चर्चा मुख्यतः Rust और C/C++/Zig के responsibility model के अंतर के इर्द-गिर्द रही है
    • Rust, कुछ ऐसे programs को भी reject करने की कीमत स्वीकार करता है जो सुरक्षित हो सकते थे, ताकि memory safety problems पैदा कर सकने वाले programs को compile होने से रोका जा सके
    • unsafe raw pointer dereference आदि की अनुमति देकर कुछ guarantees को bypass करने वाला escape hatch है
    • C-family languages memory safety guarantees का अधिकतर भार programmer पर छोड़ती हैं
  • C++ के RAII और smart pointers, Zig के defer जैसे language-specific support में फर्क है, लेकिन ये गलत memory access को मूल रूप से block नहीं करते

Fil-C ने जो विकल्प जोड़ा

  • Fil-C C और C++ code को memory-safe तरीके से चलाने का नया approach देता है
    • out-of-bounds access या use-after-free जैसी गलत memory access होने पर यह panic कराता है
    • यह GC और pointer द्वारा access की जा सकने वाली memory को track करने वाले InvisiCaps को combine करता है
  • Zig में भी Fil-C से प्रेरित एक नया compile mode प्रस्तावित किया गया है
  • अगर कुछ लोकप्रिय C/C++ projects Fil-C से compile किए गए releases उपलब्ध कराएं, तो memory safety vulnerabilities कम करने के विकल्प बढ़ सकते हैं

Rust को unsafe मानने का मानदंड

  • Fil-C developer ने Twitter पर unsafe के जरिए कुछ guarantees bypass किए जा सकने के कारण Rust को memory-safe language नहीं माना है
  • Zig developer Andrew Kelley ने भी संबंधित issue title में Fil-C से प्रेरित mode को “Rust के विपरीत वास्तव में memory-safe” compile mode कहा
  • कुछ चर्चाएं यह मांग करती हैं कि अगर Rust users सचमुच memory safety को महत्व देते हैं, तो उन्हें Rust छोड़कर ज्यादा सुरक्षित Fil-C को promote करना चाहिए
  • यह मानदंड Fil-C की व्यावहारिक लागतों को हटाकर Rust और Fil-C की तुलना करता है, और Rust community पर अक्सर लगने वाली fanatical होने की आलोचना जैसी ही सोच दिखाता है

Fil-C लागू करने की सीमाएं

  • Fil-C कोई मुफ्त drop-in replacement नहीं है
    • यह non-Fil-C के साथ compile किए गए programs से ABI-compatible नहीं है
    • कुछ स्थितियों में यह कई गुना धीमा हो सकता है
    • यह GC लाता है
  • सरल utilities जैसे programs, जहां performance गिरावट महसूस करना मुश्किल हो या dynamic linking की जरूरत न हो, में ये सीमाएं निर्णायक नहीं हो सकतीं
  • इसके उलट, ऐसे लोकप्रिय projects भी बहुत हैं जो GC और ABI incompatibility स्वीकार नहीं कर सकते; मौजूदा रूप में Fil-C लागू करना जिन programs में मुश्किल है, वे अक्सर Rust के लिए अच्छे fit होते हैं

असली Rust code की vulnerability data

  • Rust की वास्तविक security को आंकने के लिए data अभी ज्यादा नहीं है, लेकिन Rust software में exploitable memory safety vulnerabilities बहुत अधिक नहीं मिली हैं
  • Android के 50 लाख से ज्यादा lines के Rust code में 1 संभावित memory safety vulnerability मिली और release से पहले ठीक कर दी गई
    • अनुमानित vulnerability density 10 लाख lines पर 0.2 cases है
    • Android का पुराना C/C++ data 10 लाख lines पर लगभग 1,000 cases है
    • Rust code की density C/C++ से 1,000 गुना से भी ज्यादा कम track की जा रही है
  • अलग-अलग projects में आंकड़े बदल सकते हैं, लेकिन यह real-world environments में Rust द्वारा memory safety problems के introduce होने का risk काफी घटाने का सबूत है

सिर्फ एक चुनना जरूरी क्यों नहीं

  • हर program में 99.9% समस्याएं रोकने वाली तकनीक और 90% programs में 100% समस्याएं रोकने वाली तकनीक की काल्पनिक तुलना दिखाती है कि applicability और prevention level दोनों महत्वपूर्ण हैं
  • असली अनुपात पता नहीं हैं, लेकिन इन दो approaches में से सिर्फ एक चुनना जरूरी नहीं है
    • trade-offs स्वीकार कर सकने वाले C/C++/Zig projects Fil-C binaries दे सकते हैं
    • जिन software में Fil-C इस्तेमाल नहीं हो सकता, उन्हें ऐसी language में लिखा जा सकता है जो memory safety vulnerabilities के risk को पूरी तरह या अधिकतर खत्म कर दे

GC इस्तेमाल कर सकने पर भी Rust चुनने की वजह

  • Go या Fil-C जैसे GC-based options होने पर भी Rust इस्तेमाल करना उचित है
  • GC-based language में लिखे जा सकने वाले programs में अक्सर unsafe की जरूरत नहीं होती, और जिन programs में unsafe की जरूरत होती है, उनमें अक्सर GC इस्तेमाल नहीं किया जा सकता
  • छोटी memory safety risk की तुलना में data race prevention जैसी दूसरी language guarantees और features को ज्यादा महत्वपूर्ण माना जा सकता है
  • Fil-C मौजूदा C/C++ की memory safety vulnerabilities को crash में बदल देता है
    • यह security vulnerability से बेहतर है, लेकिन अगर 10 लाख lines पर लगभग 1,000 cases की पुरानी density जैसी ही रहे, तो ठीक करने लायक बहुत सारे crashes बचेंगे
    • अतीत में attacker द्वारा program crash करा सकने की क्षमता का उपयोग करने वाली security vulnerabilities भी रही हैं

consistent memory safety मानदंड

  • अगर Rust में 10 लाख lines पर 0.2 cases भी स्वीकार्य नहीं हैं, तो सामान्य C/C++ और non-Fil-C Zig पर भी उतनी ही या उससे अधिक कड़ी आलोचना लागू होनी चाहिए
  • Rust से कम safety वाले alternatives को स्वीकार करते हुए सिर्फ unsafe की वजह से Rust को खारिज करना memory safety absolutism को consistent तरीके से लागू नहीं करता

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2 시간 전
Lobste.rs की राय

  • Andrew Kelly की जिस टिप्पणी को OP ने शायद आपत्तिजनक माना, उसका आशय यह था कि Zig, C/C++ dependencies समेत पूरे executable को बिना किसी escape hatch के पूरी तरह memory-safe executable के रूप में compile कर सकता है, और pointer tracking की frequency के आधार पर performance cost लगभग 1~6 गुना है
    लेखक ने इसे Rust पर हमला माना और लेख के अंत में Zig पर हमला किया, लेकिन Fil-C और Zig का नया build mode ecosystem में सकारात्मक योगदान हैं और Rust से अलग design points और trade-offs देते हैं
    इसका मतलब मैं यह समझता हूँ कि Zig team के पसंदीदा data-oriented programming को अपनाने पर performance cost को 1x के करीब घटाया जा सकता है

    • लेखक “Fil-C से प्रेरित, Rust के विपरीत सच में memory-safe compile mode की शुरुआत” शीर्षक और Fil-C developer के Twitter post पर प्रतिक्रिया दे रहा था
      इसे अनावश्यक रूप से उकसाने वाला पढ़ना भी अनुचित नहीं है, और Andrew ने बाद में शीर्षक को कम उत्तेजक बना दिया

  • आमतौर पर उल्टा होता है, लेकिन जब “तुम्हारी language memory-safe नहीं है” जैसी हल्की चुटकी उनकी ओर आई, तो Rust developers की प्रतिक्रिया का पैमाना काफी बड़ा था
    मुझे भी Rust बहुत पसंद है, लेकिन इसे निष्पक्षता से लेना जरूरी है

    • “Rust काफी हद तक memory-safe है, लेकिन Fil-C उस पहलू में ज्यादा safe है” कहना बहुत विवादास्पद नहीं और तथ्य जैसा लगता है
      इससे भी आगे, seL4 का formally verified C और ज्यादा safe है
    • मैं सही programs को महत्व देता हूँ और जहां तक हो सके गलत code नहीं लिखना चाहता, इसलिए विरोधाभास जैसा लगे तो भी Zig की बजाय Rust पसंद करता हूँ
      Zig का फायदा है कि memory allocation failure पर सही तरीके से exit करना आसान है और compile भी तेज है
      Fil-C Rust से ज्यादा memory-safe है या नहीं, यह मुझे नहीं पता, लेकिन मेरे use case में garbage collector और C ABI incompatibility निर्णायक बाधाएं हैं
      single-threaded बनाने पर race conditions से बचा जा सकता है और garbage collector जोड़ने पर memory safety मिल सकती है, लेकिन Rust की अच्छी बात यह है कि वह इन दोनों compromises के बिना दोनों चीजें देता है

  • चूंकि memory safety को बहुत महत्व देता हूँ, Fil-C और Zig का Fil-C ABI implementation स्वाभाविक विकल्प हैं
    C dependencies वाले Rust projects में safety guarantees कमजोर हो जाते हैं, और केवल pure Rust इस्तेमाल करना संभव तो है लेकिन असुविधाजनक है
    Rust को भी Fil-C ABI implement करना चाहिए ताकि C dependencies को safely build करके Rust से link किया जा सके; मुझे समझ नहीं आता कि यह विवादास्पद क्यों है

    • Rust में पहले से Miri interpreter है, जो जांचता है कि unsafe Rust code, safe Rust की guarantees का पालन करता है या नहीं
      अगर ऐसी ही functionality implement की जाए, तो मैं चाहूँगा कि वह debug builds में केवल FFI code को बेहतर बनाने वाले सहायक साधन के रूप में इस्तेमाल हो
      garbage collector रखकर हर operation को runtime पर check करने का तरीका हर use case के लिए उपयुक्त नहीं है

  • Fil-C को सिर्फ साधारण utility use के लिए मानकर खारिज करने से पहले Software Should Work conference का Fil-C talk देखना चाहिए
    speaker ने user space के पूरे हिस्से और OpenOffice Impress तक को Fil-C से बने Linux laptop पर presentation दी
    कुछ C/C++ programs के लिए यह उपयुक्त नहीं होगा, लेकिन लेखक जितना मानता है उतना toy technology जैसा नहीं दिखता

  • Python background से आने के कारण memory safety तो baseline assumption थी, और Rust चुनने के तीन कारण थे
    पहला, इसके मजबूत type system से compile time पर correctness हासिल की जा सकती है, और #![forbid(unsafe_code)] व cargo-geiger से dependency audit के जरिए मिलने वाली memory safety इसका सबसे कम रोमांचक रूप है
    दूसरा, यह ऐसा ecosystem देता है जिसमें code को एक बार safely लिखकर कई languages और execution environments में share करना आसान है
    तीसरा, उस समय के try!(x) जैसी syntactic sugar है, जो high-level code आराम से लिखने देती है
    Zig और Fil-C, typestate pattern या newtypes जैसी चीजों से invariants को type system में encode कर logical errors compiler से पकड़वाने की क्षमता पूरी करते नहीं दिखते
    Fil-C की ABI incompatibility भी shared web hosting के CPython जैसे मौजूदा runtime के लिए safe compiled modules लिखते समय समस्या बनती है

    • Zig में भी typestate pattern और कई तरह की constraints की type encoding संभव है, और कुछ मायनों में comptime Rust से अधिक expressive है
      compile time और verbosity, तथा ecosystem के अधिकांश हिस्से द्वारा इस स्तर तक कोशिश न करने जैसे trade-offs हैं, लेकिन यह सच में संभव है और काफी मजेदार भी है

  • जिज्ञासा है कि Fil-C जैसी technology 20 साल पहले क्यों नहीं आई

    • mainframe क्षेत्र में pointer और capability-based permissions को share और tag करने के तरीके से जुड़ी security समस्याओं के बारे में दशकों से चेतावनी दी जाती रही है
      लेकिन कोई भी CPU या memory, यानी लागत, के रूप में उसकी कीमत चुकाना नहीं चाहता था
    • कुछ महीने पहले मैंने Filip से ऐसा ही सवाल पूछा था और यह जवाब मिला था
      2004~2018 में ideas थे, लेकिन memory-safe C का विचार ही मूर्खतापूर्ण माना जाता था; 2018~2023 में सोच बदली, लेकिन extreme compatibility हासिल करने का तरीका नहीं मिला
      2023~2024 के शुरुआती Fil-C में compatibility और performance काफी कम थे, और 2024 के अंत में InvisiCaps breakthrough से आज की high compatibility और ठीक-ठाक performance मिली
      2018 के आसपास सोच बदलने की वजह यह observation था कि GPU में इस्तेमाल होने वाले C variants, memory-safe C के सरल रूप हैं
    • 20 साल पहले computers धीमे थे और safety cost के प्रति कहीं ज्यादा संवेदनशील थे

  • “अगर Rust camp सच में memory safety को महत्व देता है, तो उसे ज्यादा safe Fil-C का समर्थन कर Rust छोड़ देना चाहिए” को सबसे उदारता से समझें, तो मतलब यह है कि अब Fil-C मौजूद है, इसलिए दुनिया को Rust में फिर से लिखने की कोशिश बंद करें और C/C++ पर लौटकर पहले जैसा unified library ecosystem बनाए रखें
    Rust libraries को C/C++ से इस्तेमाल किया जा सकता है, फिर भी कुछ developers ऐसा नहीं चाहते; इसलिए तर्क यह है कि अगर Rust users बेहतर समाधान मान लें और छोड़ दें, तो fragmentation खत्म हो जाएगी
    लेकिन Fil-C में garbage collector और केवल x86-64 Linux support जैसे trade-offs हैं, जो Rust में नहीं हैं
    memory safety के अलावा Cargo और global namespace न होना भी Rust इस्तेमाल करने के महत्वपूर्ण कारण हैं, और language camps के बीच fragmentation का व्यापक culture war से जुड़ जाना दुखद है
    मैं बस ऐसी library बनाना चाहता हूँ जिसे हर कोई खुशी से इस्तेमाल करे

    • क्या C और C++ भर से ही पहले से fragmented ecosystem नहीं है, यह सवाल है
      C developers में कुछ लोग C++ libraries नहीं चाहते होंगे, और Zig व Odin भी आ चुके हैं, इसलिए Rust गायब हो जाए तब भी fragmentation बनी रहेगी
      जिज्ञासा है कि क्या Rust किसी खास अलग तरह की fragmentation पैदा करता है
    • मैं भी ऐसी दुनिया चाहता हूँ जहाँ हर कोई संतुष्ट होकर library इस्तेमाल करे, और मैं Rust→Zig high-level transpiler पर काम कर रहा हूँ जो generics को comptime के रूप में preserve करता है
      Rust ज्यादा constraints encode करता है, इसलिए source language के रूप में आदर्श है