बाउंडस चेकिंग: Difference between revisions

From Vigyanwiki
No edit summary
Line 8: Line 8:


==इंडेक्स चेकिंग (सूचकांक जाँच)==
==इंडेक्स चेकिंग (सूचकांक जाँच)==
इंडेक्स चेकिंग का मतलब है कि, किसी ऐरे को अनुक्रमित करने वाले सभी [[ अभिव्यक्ति (प्रोग्रामिंग) ]] में, इंडेक्स वैल्यू को ऐरे की सीमाओं के विरुद्ध चेक किया जाता है (जो ऐरे को परिभाषित करते समय स्थापित किए गए थे), और यदि इंडेक्स सीमा से बाहर है, तो आगे निष्पादन किसी प्रकार की त्रुटि के कारण निलंबित कर दिया गया है। चूँकि किसी सरणी की सीमा के बाहर किसी मान को पढ़ने या विशेष रूप से लिखने से प्रोग्राम ख़राब हो सकता है या क्रैश हो सकता है या सुरक्षा कमजोरियाँ सक्षम हो सकती हैं ([[बफ़र अधिकता]] देखें), इंडेक्स जाँच कई उच्च-स्तरीय [[प्रोग्रामिंग भाषा]]|उच्च-स्तरीय भाषाओं का एक हिस्सा है।
सूचकांक जाँच का मतलब है कि, किसी सरणी को अनुक्रमित करने वाले सभी अभिव्यक्तियों में, सूचकांक मान को सरणी की सीमाओं के विरुद्ध जाँचा जाता है (जो कि सरणी परिभाषित होने पर स्थापित किए गए थे), और यदि सूचकांक सीमा से बाहर है, तो आगे का निष्पादन किसी प्रकार की त्रुटि के कारण निलंबित हो जाता है। चूँकि किसी सरणी की सीमा के बाहर किसी मान को पढ़ने या विशेष रूप से लिखने से प्रोग्राम ख़राब हो सकता है या क्रैश हो सकता है या सुरक्षा कमजोरियाँ सक्षम हो सकती हैं (बफ़र ओवरफ़्लो देखें), सूचकांक जाँच कई उच्च-स्तरीय भाषाओं का एक भाग है।


सूचकांक जाँच क्षमता वाली आरंभिक संकलित प्रोग्रामिंग भाषाओं में [[ALGOL 60]], [[ALGOL 68]] और [[पास्कल (प्रोग्रामिंग भाषा)]] के साथ-साथ [[BASIC]] जैसी व्याख्या की गई प्रोग्रामिंग भाषाएँ शामिल थीं।
इंडेक्स-चेकिंग क्षमता वाली प्रारंभिक संकलित प्रोग्रामिंग भाषाओं में [[ALGOL 60]], [[ALGOL 68]] और [[पास्कल (प्रोग्रामिंग भाषा)|पास्कल]] के साथ-साथ [[BASIC]] जैसी व्याख्या की गई प्रोग्रामिंग भाषाएं शामिल थीं।


कई प्रोग्रामिंग भाषाएं, जैसे [[सी (प्रोग्रामिंग भाषा)]], गति बढ़ाने के लिए कभी भी स्वचालित बाउंडस चेकिंग नहीं करती हैं। हालाँकि, इससे एक-एक करके कई त्रुटियाँ और बफ़र ओवरफ़्लो पकड़ में नहीं आते हैं। कई प्रोग्रामर मानते हैं कि ये भाषाएँ तेजी से निष्पादन के लिए बहुत अधिक त्याग करती हैं।<ref>{{Cite book |doi=10.1109/DISCEX.2000.821514|chapter=Buffer overflows: Attacks and defenses for the vulnerability of the decade|title=कार्यवाही DARPA सूचना उत्तरजीविता सम्मेलन और प्रदर्शनी। डिस्केक्स'00|volume=2|pages=119–129|year=1999|last1=Cowan|first1=C|last2=Wagle|first2=F|last3=Calton Pu|last4=Beattie|first4=S|last5=Walpole|first5=J|isbn=978-0-7695-0490-2|s2cid=167759976}}</ref> अपने 1980 के [[ ट्यूरिंग पुरस्कार ]] व्याख्यान में, सी. ए. आर. होरे ने ALGOL 60 के डिज़ाइन में अपने अनुभव का वर्णन किया, एक ऐसी भाषा जिसमें सीमा जाँच शामिल थी, उन्होंने कहा:
कई प्रोग्रामिंग भाषाएँ, जैसे C, गति बढ़ाने के लिए कभी भी स्वचालित सीमा जाँच नहीं करती हैं। हालाँकि, यह कई आवर्ती एरर और बफ़र ओवरफ़्लो को नहीं पकड़ता है। कई प्रोग्रामर का मानना है कि ये भाषाएँ त्वरित निष्पादन के लिए बहुत अधिक त्याग करती हैं।<ref>{{Cite book |doi=10.1109/DISCEX.2000.821514|chapter=Buffer overflows: Attacks and defenses for the vulnerability of the decade|title=कार्यवाही DARPA सूचना उत्तरजीविता सम्मेलन और प्रदर्शनी। डिस्केक्स'00|volume=2|pages=119–129|year=1999|last1=Cowan|first1=C|last2=Wagle|first2=F|last3=Calton Pu|last4=Beattie|first4=S|last5=Walpole|first5=J|isbn=978-0-7695-0490-2|s2cid=167759976}}</ref> अपने 1980 के ट्यूरिंग अवार्ड व्याख्यान में, सी. ए. आर. होरे ने ALGOL 60 के डिजाइन में अपने अनुभव का वर्णन किया, एक ऐसी भाषा जिसमें सीमाओं की जाँच शामिल थी, उन्होंने कहा:<blockquote>इस सिद्धांत का एक परिणाम यह है कि प्रत्येक सबस्क्रिप्टेड वेरिएबल की प्रत्येक सबस्क्रिप्ट की प्रत्येक घटना को प्रत्येक अवसर पर सरणी के ऊपरी और निचले दोनों घोषित सीमाओं के विरुद्ध रन टाइम पर जांचा गया था। कई वर्षों बाद हमने अपने ग्राहकों से पूछा कि क्या वे चाहते हैं कि हम उत्पादन संचालन की दक्षता के हित में इन चेकों को बंद करने का विकल्प प्रदान करें। सर्वसम्मति से, उन्होंने हमसे ऐसा न करने का आग्रह किया - वे पहले से ही जानते थे कि उत्पादन संचालन में कितनी बार सबस्क्रिप्ट एरर होती हैं, जहाँ उनका पता लगाने में विफलता विनाशकारी हो सकती है। मैं भय और भय के साथ नोट करता हूं कि 1980 में भी, भाषा डिजाइनरों और उपयोगकर्ताओं ने यह सबक नहीं सीखा है। इंजीनियरिंग की किसी भी सम्मानजनक शाखा में, ऐसी प्राथमिक सावधानियों का पालन करने में विफलता लंबे समय तक नियम के विरूद्ध होती है।</blockquote>रन टाइम चेकिंग को लागू करने वाली मुख्यधारा की भाषाओं में [[एडा (प्रोग्रामिंग भाषा)]], सी शार्प (प्रोग्रामिंग भाषा)|सी#, [[हास्केल (प्रोग्रामिंग भाषा)]], [[जावा (प्रोग्रामिंग भाषा)]], [[जावास्क्रिप्ट]], [[लिस्प (प्रोग्रामिंग भाषा)]], [[पीएचपी]], [[पायथन (प्रोग्रामिंग भाषा)]] शामिल हैं। , [[रूबी (प्रोग्रामिंग भाषा)]], रस्ट (प्रोग्रामिंग भाषा), और [[मूल दृश्य]] D (प्रोग्रामिंग भाषा) और [[OCaml]] भाषाओं में समय सीमा की जाँच होती है जो कंपाइलर स्विच के साथ सक्षम या अक्षम होती है। [[C++]] में रन टाइम चेकिंग भाषा का हिस्सा नहीं है, बल्कि [[मानक टेम्पलेट लाइब्रेरी]] का हिस्सा है और एक कंपाइलर स्विच (_GLIBCXX_DEBUG=1 या _LIBCPP_DEBUG=1) के साथ सक्षम है। C# असुरक्षित क्षेत्रों का भी समर्थन करता है: कोड के अनुभाग जो (अन्य बातों के अलावा) दक्षता बढ़ाने के लिए बाउंडस चेकिंग को अस्थायी रूप से निलंबित कर देते हैं। ये पूरे कार्यक्रम की सुरक्षा से समझौता किए बिना छोटी समय-महत्वपूर्ण बाधाओं को तेज करने के लिए उपयोगी हैं।
 
<ब्लॉककोट>इस सिद्धांत का एक परिणाम यह है कि प्रत्येक सबस्क्रिप्टेड वेरिएबल की प्रत्येक सबस्क्रिप्ट की प्रत्येक घटना को हर अवसर पर सरणी की ऊपरी और निचली दोनों घोषित सीमाओं के विरुद्ध रन टाइम पर जांचा जाता था। कई वर्षों के बाद हमने अपने ग्राहकों से पूछा कि क्या वे चाहते हैं कि हम उत्पादन संचालन में दक्षता के हित में इन चेकों को बंद करने का विकल्प प्रदान करें। सर्वसम्मति से, उन्होंने हमसे ऐसा न करने का आग्रह किया - वे पहले से ही जानते थे कि उत्पादन में कितनी बार सबस्क्रिप्ट त्रुटियां होती हैं, जहां उनका पता लगाने में विफलता विनाशकारी हो सकती है। मैं डर और भय के साथ नोट करता हूं कि 1980 में भी, भाषा डिजाइनरों और उपयोगकर्ताओं ने यह सबक नहीं सीखा है। इंजीनियरिंग की किसी भी सम्मानित शाखा में, ऐसी प्राथमिक सावधानियों का पालन करने में विफलता लंबे समय तक कानून के खिलाफ होती।</ब्लॉककोट>
 
रन टाइम चेकिंग को लागू करने वाली मुख्यधारा की भाषाओं में [[एडा (प्रोग्रामिंग भाषा)]], सी शार्प (प्रोग्रामिंग भाषा)|सी#, [[हास्केल (प्रोग्रामिंग भाषा)]], [[जावा (प्रोग्रामिंग भाषा)]], [[जावास्क्रिप्ट]], [[लिस्प (प्रोग्रामिंग भाषा)]], [[पीएचपी]], [[पायथन (प्रोग्रामिंग भाषा)]] शामिल हैं। , [[रूबी (प्रोग्रामिंग भाषा)]], रस्ट (प्रोग्रामिंग भाषा), और [[मूल दृश्य]] D (प्रोग्रामिंग भाषा) और [[OCaml]] भाषाओं में समय सीमा की जाँच होती है जो कंपाइलर स्विच के साथ सक्षम या अक्षम होती है। [[C++]] में रन टाइम चेकिंग भाषा का हिस्सा नहीं है, बल्कि [[मानक टेम्पलेट लाइब्रेरी]] का हिस्सा है और एक कंपाइलर स्विच (_GLIBCXX_DEBUG=1 या _LIBCPP_DEBUG=1) के साथ सक्षम है। C# असुरक्षित क्षेत्रों का भी समर्थन करता है: कोड के अनुभाग जो (अन्य बातों के अलावा) दक्षता बढ़ाने के लिए बाउंडस चेकिंग को अस्थायी रूप से निलंबित कर देते हैं। ये पूरे कार्यक्रम की सुरक्षा से समझौता किए बिना छोटी समय-महत्वपूर्ण बाधाओं को तेज करने के लिए उपयोगी हैं।


[[JS++]] प्रोग्रामिंग भाषा मौजूदा प्रकारों का उपयोग करके यह विश्लेषण करने में सक्षम है कि क्या कोई सरणी सूचकांक या मानचित्र कुंजी संकलन समय पर सीमा से बाहर है, जो एक [[नाममात्र प्रकार की प्रणाली]] है जो यह बताती है कि सूचकांक या कुंजी सीमा के भीतर है या सीमा से बाहर है। और कोड जनरेशन का मार्गदर्शन करता है। मौजूदा प्रकारों को संकलन समय में केवल 1ms ओवरहेड जोड़ने के लिए दिखाया गया है।<ref>{{Cite web | url=https://www.onux.com/jspp/blog/jspp-0-9-0-efficient-compile-time-analysis-of-out-of-bounds-errors/ | archive-url=https://web.archive.org/web/20190112060200/https://www.onux.com/jspp/blog/jspp-0-9-0-efficient-compile-time-analysis-of-out-of-bounds-errors/| archive-date=2019-01-12| title=JS++ 0.9.0: Efficient Compile Time Analysis of Out-of-Bounds Errors – JS++ Blog}}</ref>
[[JS++]] प्रोग्रामिंग भाषा मौजूदा प्रकारों का उपयोग करके यह विश्लेषण करने में सक्षम है कि क्या कोई सरणी सूचकांक या मानचित्र कुंजी संकलन समय पर सीमा से बाहर है, जो एक [[नाममात्र प्रकार की प्रणाली]] है जो यह बताती है कि सूचकांक या कुंजी सीमा के भीतर है या सीमा से बाहर है। और कोड जनरेशन का मार्गदर्शन करता है। मौजूदा प्रकारों को संकलन समय में केवल 1ms ओवरहेड जोड़ने के लिए दिखाया गया है।<ref>{{Cite web | url=https://www.onux.com/jspp/blog/jspp-0-9-0-efficient-compile-time-analysis-of-out-of-bounds-errors/ | archive-url=https://web.archive.org/web/20190112060200/https://www.onux.com/jspp/blog/jspp-0-9-0-efficient-compile-time-analysis-of-out-of-bounds-errors/| archive-date=2019-01-12| title=JS++ 0.9.0: Efficient Compile Time Analysis of Out-of-Bounds Errors – JS++ Blog}}</ref>

Revision as of 20:50, 10 August 2023

कंप्यूटर प्रोग्रामिंग में, बाउंडस चेकिंग (सीमा की जाँच) यह ज्ञात करने की एक विधि है कि क्या कोई चर उपयोग करने से पहले कुछ सीमाओं के अन्दर है। इसका उपयोग आम तौर पर यह सुनिश्चित करने के लिए किया जाता है कि कोई संख्या किसी दिए गए प्रकार (रेंज चेकिंग) में फिट होती है, या कि एक सरणी इंडेक्स के रूप में उपयोग किया जा रहा एक चर सरणी (इंडेक्स चेकिंग) की सीमा के भीतर है। एक विफल बाउंडस चेकिंग के परिणामस्वरूप आमतौर पर कुछ प्रकार के अपवाद संकेत उत्पन्न होते हैं।

चूँकि प्रत्येक उपयोग के दौरान सीमाओं की जाँच करना समय लेने वाला हो सकता है, यह हमेशा नहीं किया जाता है। सीमा-जांच उन्मूलन एक कंपाइलर अनुकूलन तकनीक है जो अनावश्यक बाउंडस चेकिंग को समाप्त करती है।

रेंज चेकिंग

रेंज चेकिंग एक जांच है जो यह सुनिश्चित करती है कि कोई संख्या एक निश्चित सीमा के भीतर है; उदाहरण के लिए, यह सुनिश्चित करने के लिए कि 16-बिट पूर्णांक को सौंपा जाने वाला मान 16-बिट पूर्णांक की क्षमता के भीतर है (अर्थात रैप-अराउंड के विरुद्ध जाँच करना)। यह टाइप चेकिंग के बिल्कुल समान नहीं है। अन्य श्रेणी की जाँचें अधिक प्रतिबंधात्मक हो सकती हैं; उदाहरण के लिए, एक कैलेंडर माह की संख्या रखने के लिए एक चर को केवल 1 से 12 तक की सीमा को स्वीकार करने के लिए घोषित किया जा सकता है।

इंडेक्स चेकिंग (सूचकांक जाँच)

सूचकांक जाँच का मतलब है कि, किसी सरणी को अनुक्रमित करने वाले सभी अभिव्यक्तियों में, सूचकांक मान को सरणी की सीमाओं के विरुद्ध जाँचा जाता है (जो कि सरणी परिभाषित होने पर स्थापित किए गए थे), और यदि सूचकांक सीमा से बाहर है, तो आगे का निष्पादन किसी प्रकार की त्रुटि के कारण निलंबित हो जाता है। चूँकि किसी सरणी की सीमा के बाहर किसी मान को पढ़ने या विशेष रूप से लिखने से प्रोग्राम ख़राब हो सकता है या क्रैश हो सकता है या सुरक्षा कमजोरियाँ सक्षम हो सकती हैं (बफ़र ओवरफ़्लो देखें), सूचकांक जाँच कई उच्च-स्तरीय भाषाओं का एक भाग है।

इंडेक्स-चेकिंग क्षमता वाली प्रारंभिक संकलित प्रोग्रामिंग भाषाओं में ALGOL 60, ALGOL 68 और पास्कल के साथ-साथ BASIC जैसी व्याख्या की गई प्रोग्रामिंग भाषाएं शामिल थीं।

कई प्रोग्रामिंग भाषाएँ, जैसे C, गति बढ़ाने के लिए कभी भी स्वचालित सीमा जाँच नहीं करती हैं। हालाँकि, यह कई आवर्ती एरर और बफ़र ओवरफ़्लो को नहीं पकड़ता है। कई प्रोग्रामर का मानना है कि ये भाषाएँ त्वरित निष्पादन के लिए बहुत अधिक त्याग करती हैं।[1] अपने 1980 के ट्यूरिंग अवार्ड व्याख्यान में, सी. ए. आर. होरे ने ALGOL 60 के डिजाइन में अपने अनुभव का वर्णन किया, एक ऐसी भाषा जिसमें सीमाओं की जाँच शामिल थी, उन्होंने कहा:

इस सिद्धांत का एक परिणाम यह है कि प्रत्येक सबस्क्रिप्टेड वेरिएबल की प्रत्येक सबस्क्रिप्ट की प्रत्येक घटना को प्रत्येक अवसर पर सरणी के ऊपरी और निचले दोनों घोषित सीमाओं के विरुद्ध रन टाइम पर जांचा गया था। कई वर्षों बाद हमने अपने ग्राहकों से पूछा कि क्या वे चाहते हैं कि हम उत्पादन संचालन की दक्षता के हित में इन चेकों को बंद करने का विकल्प प्रदान करें। सर्वसम्मति से, उन्होंने हमसे ऐसा न करने का आग्रह किया - वे पहले से ही जानते थे कि उत्पादन संचालन में कितनी बार सबस्क्रिप्ट एरर होती हैं, जहाँ उनका पता लगाने में विफलता विनाशकारी हो सकती है। मैं भय और भय के साथ नोट करता हूं कि 1980 में भी, भाषा डिजाइनरों और उपयोगकर्ताओं ने यह सबक नहीं सीखा है। इंजीनियरिंग की किसी भी सम्मानजनक शाखा में, ऐसी प्राथमिक सावधानियों का पालन करने में विफलता लंबे समय तक नियम के विरूद्ध होती है।

रन टाइम चेकिंग को लागू करने वाली मुख्यधारा की भाषाओं में एडा (प्रोग्रामिंग भाषा), सी शार्प (प्रोग्रामिंग भाषा)|सी#, हास्केल (प्रोग्रामिंग भाषा), जावा (प्रोग्रामिंग भाषा), जावास्क्रिप्ट, लिस्प (प्रोग्रामिंग भाषा), पीएचपी, पायथन (प्रोग्रामिंग भाषा) शामिल हैं। , रूबी (प्रोग्रामिंग भाषा), रस्ट (प्रोग्रामिंग भाषा), और मूल दृश्य D (प्रोग्रामिंग भाषा) और OCaml भाषाओं में समय सीमा की जाँच होती है जो कंपाइलर स्विच के साथ सक्षम या अक्षम होती है। C++ में रन टाइम चेकिंग भाषा का हिस्सा नहीं है, बल्कि मानक टेम्पलेट लाइब्रेरी का हिस्सा है और एक कंपाइलर स्विच (_GLIBCXX_DEBUG=1 या _LIBCPP_DEBUG=1) के साथ सक्षम है। C# असुरक्षित क्षेत्रों का भी समर्थन करता है: कोड के अनुभाग जो (अन्य बातों के अलावा) दक्षता बढ़ाने के लिए बाउंडस चेकिंग को अस्थायी रूप से निलंबित कर देते हैं। ये पूरे कार्यक्रम की सुरक्षा से समझौता किए बिना छोटी समय-महत्वपूर्ण बाधाओं को तेज करने के लिए उपयोगी हैं।

JS++ प्रोग्रामिंग भाषा मौजूदा प्रकारों का उपयोग करके यह विश्लेषण करने में सक्षम है कि क्या कोई सरणी सूचकांक या मानचित्र कुंजी संकलन समय पर सीमा से बाहर है, जो एक नाममात्र प्रकार की प्रणाली है जो यह बताती है कि सूचकांक या कुंजी सीमा के भीतर है या सीमा से बाहर है। और कोड जनरेशन का मार्गदर्शन करता है। मौजूदा प्रकारों को संकलन समय में केवल 1ms ओवरहेड जोड़ने के लिए दिखाया गया है।[2]


हार्डवेयर सीमा जाँच

यदि जाँच सॉफ़्टवेयर में की जाती है तो सीमा जाँच द्वारा जोड़ी गई सुरक्षा में आवश्यक रूप से CPU समय खर्च होता है; हालाँकि, यदि जाँच हार्डवेयर द्वारा की जा सकती है, तो बिना किसी रनटाइम लागत के सुरक्षा निःशुल्क प्रदान की जा सकती है। हार्डवेयर सीमा जाँच वाली एक प्रारंभिक प्रणाली 1974 में घोषित आईसीएल 2900 सीरीज मेनफ्रेम थी।[3] VAX कंप्यूटर में ऐरे इंडेक्स जाँच के लिए एक INDEX असेंबली निर्देश होता है जिसमें छह ऑपरेंड लगते हैं, जिनमें से सभी किसी भी VAX एड्रेसिंग मोड का उपयोग कर सकते हैं। B6500 और इसी तरह के बरोज़ कॉर्पोरेशन कंप्यूटरों ने हार्डवेयर के माध्यम से बाउंड चेकिंग की, भले ही मशीन कोड का उत्पादन करने के लिए किसी भी कंप्यूटर भाषा को संकलित किया गया हो। सीमित संख्या में बाद के CPU में सीमाओं की जांच के लिए विशेष निर्देश हैं, उदाहरण के लिए, मोटोरोला 68000#इंटरप्ट्स श्रृंखला पर सीएचके2 निर्देश।

ऐरे और बफर एक्सेस की सुरक्षा सुनिश्चित करने के लिए x86 की अंतर्निहित वर्चुअल मेमोरी प्रबंधन इकाई का उपयोग करने के तरीकों के संबंध में कम से कम 2005 से अनुसंधान चल रहा है।[4] 2015 में इंटेल ने अपने स्काईलेक (माइक्रोआर्किटेक्चर) प्रोसेसर आर्किटेक्चर में इंटेल एमपीएक्स एक्सटेंशन प्रदान किया जो सीपीयू रजिस्टर और मेमोरी में टेबल में सीमाओं को संग्रहीत करता है। 2017 की शुरुआत में कम से कम जीसीसी एमपीएक्स एक्सटेंशन का समर्थन करता है।

यह भी देखें

संदर्भ

  1. Cowan, C; Wagle, F; Calton Pu; Beattie, S; Walpole, J (1999). "Buffer overflows: Attacks and defenses for the vulnerability of the decade". कार्यवाही DARPA सूचना उत्तरजीविता सम्मेलन और प्रदर्शनी। डिस्केक्स'00. Vol. 2. pp. 119–129. doi:10.1109/DISCEX.2000.821514. ISBN 978-0-7695-0490-2. S2CID 167759976.
  2. "JS++ 0.9.0: Efficient Compile Time Analysis of Out-of-Bounds Errors – JS++ Blog". Archived from the original on 2019-01-12.
  3. J. K. Buckle (1978). The ICL 2900 Series (PDF). Macmillan Computer Science Series. pp. 17, 77. ISBN 978-0-333-21917-1. Archived from the original (PDF) on 20 April 2018. Retrieved 20 April 2018.
  4. Lap-Chung Lam; Tzi-Cker Chiueh (2005). "Checking Array Bound Violation Using Segmentation Hardware". 2005 International Conference on Dependable Systems and Networks (DSN'05). pp. 388–397. doi:10.1109/DSN.2005.25. ISBN 0-7695-2282-3. S2CID 6278708.


बाहरी संबंध