मेमोरी-सुरक्षित रोडमैप के पक्ष में मामला

सिस्टम/OS कोड में मेमोरी-सुरक्षित भाषाओं को अपनाना

• चर्चा इस बात पर केंद्रित है कि कर्नलों और निम्न-स्तरीय सिस्टमों में मेमोरी सुरक्षा कैसे लाई जाए।
• Linux kernel में Rust को आशाजनक माना जा रहा है, लेकिन उसका दायरा अभी बहुत छोटा और शुरुआती चरण में है; यह ज़्यादातर ड्राइवरों में है।
• पसंदीदा रणनीति: पुनर्लेखन के बजाय “किनारी” घटकों को क्रमिक रूप से Rust में बदलना।
• कुछ लोगों का तर्क है कि माइक्रोकर्नल या भारी सेगमेंटेशन (VMs, Qubes-style isolation) ने यह समस्या बहुत पहले ही हल कर दी होती।

भाषा चयन और NSA की “Safe List”

• NSA के परिशिष्ट में C#, Go, Java, Python, Rust, Swift को “memory safe” बताया गया है, जिससे बहस छिड़ गई।
• कई लोग नोट करते हैं कि वास्तविक दुनिया के इकोसिस्टम अक्सर C/C++ लाइब्रेरीज़ को कॉल करते हैं, जिससे व्यावहारिक सुरक्षा कमज़ोर पड़ जाती है।
• कुछ लोग पूछते हैं कि Python सूची में क्यों है लेकिन Ruby, JS, या Perl नहीं; इसका कारण लोकप्रियता और AI/ML का रुझान बताया गया।

Rust बनाम C/C++ (और Go/Swift)

• समर्थक Rust के “safe by default, unsafe in small, explicit regions” पर ज़ोर देते हैं, जिससे ऑडिट करने वाला क्षेत्र छोटा हो जाता है।
• आलोचकों का कहना है कि निम्न-स्तरीय काम में उन्हें बार-बार unsafe और MaybeUninit का सामना करना पड़ता है, और यह अतिरिक्त औपचारिकता वाले C जैसा लगता है।
• C++ समर्थक RAII, स्मार्ट पॉइंटर, कस्टम integer types, sanitizers, और अनुशासित subsets को “काफी सुरक्षित” बताते हैं, लेकिन दूसरे जवाब देते हैं कि इतिहास दिखाता है कि मनुष्य फिर भी गंभीर बग्स डाल देते हैं।
• Go और Swift को भाषा स्तर पर मेमोरी-सुरक्षित बताया गया है, लेकिन कुछ चेतावनियों के साथ: Go में data-race आधारित exploits हो सकते हैं; Swift और Rust concurrency के लिए और मज़बूत गारंटी जोड़ते हैं।

अन्य भाषाएँ: Ada, Fortran, Java, JavaScript, Python

• Ada/ SPARK को safety-critical डोमेनों (avionics, rail, defense) में बहुत मेमोरी-सुरक्षित बताया गया, लेकिन बाज़ार हिस्सेदारी बेहद कम है।
• Fortran अधिकतर वैज्ञानिक कंप्यूटिंग तक सीमित है; इसे बड़ा attack surface नहीं माना जाता।
• Java को कुछ लोग exploits के लिए “pest fest” कहते हैं, जबकि दूसरों के अनुसार यह mostly ठीक है, सिवाय कुछ उल्लेखनीय घटनाओं (जैसे log4j) के।
• JavaScript engines को पूरी तरह सुरक्षित बनाना JIT जटिलता के कारण कठिन है; कुछ लोग JVM पर सुरक्षित implementations का ज़िक्र करते हैं।
• Python स्वयं मेमोरी-सुरक्षित है, लेकिन C/C++ extensions पर निर्भरता जोखिम फिर से जोड़ देती है।

Concurrency, Undefined Behavior, और सुरक्षा की सीमाएँ

• कई लोग तर्क देते हैं कि memory safety के बाद undefined behavior और integer overflow/underflow अगला लक्ष्य होना चाहिए।
• Rust के परिभाषित overflow behavior (debug में panic, release में wrap, और explicit checked APIs) की सराहना की जाती है।
• अन्य लोग बताते हैं कि कोई भी भाषा concurrency को पूरी तरह “solve” नहीं करती; Rust और Swift सबसे आगे जाते हैं, लेकिन logic races बनी रहती हैं।

Legacy Code, Training, और Tools

• विशाल C/C++ legacy को मुख्य समस्या माना जाता है। बहुत से नए सिस्टम अभी भी इन्हीं भाषाओं में शुरू किए जाते हैं।
• कुछ लोग सख्त subsets (MISRA-style) और static analysis (Astree, Frama-C, आदि) का सुझाव देते हैं ताकि सुरक्षा सिद्ध की जा सके, लेकिन लागत और कठिनाई भी नोट करते हैं।
• थ्रेड इस बात को लेकर संशय में है कि केवल training से memory bugs रोके जा सकते हैं; अत्यधिक प्रशिक्षित डेवलपर भी, विनियमित डोमेनों में, इन्हें shipping के साथ बाहर भेजते रहते हैं।
• AI को भविष्य के assistant के रूप में सुझाया गया है, जो नया कोड लिखने के बजाय C/C++ में memory issues का audit करे।

Threat Models, Air Gaps, और NSA की मंशा

• प्रतिभागी ज़ोर देते हैं कि air-gapped या “offline” C code भी सुरक्षित नहीं है (Stuxnet का हवाला दिया गया); अगर air-gapping ज़रूरी लगता है, तो संभवतः memory-safe भाषाएँ भी ज़रूरी हैं।
• कुछ लोग व्यंग्यपूर्वक कहते हैं कि NSA उद्योग को ऐसे shared runtimes की ओर धकेलना चाहता है जिन पर वे हमला कर सकें, जबकि दूसरे जवाब देते हैं कि NSA के पास U.S. infrastructure को मज़बूत करने के भी प्रबल प्रोत्साहन हैं।