2012-04-15 7 views
6

मेरा प्रश्न इतना व्यापक है, मुझे पता है, लेकिन मैं इस बारे में लंबे समय से सोच रहा हूं।क्या एक खराब यूएसबी डिवाइस एक बग फ्री लिनक्स कर्नेल को क्रैश करने में सक्षम होना चाहिए?

एक छोटी सी पृष्ठभूमि। मैं एक भौतिकी प्रयोगशाला में काम करता हूं जहां सभी प्रयोगशाला कंप्यूटर डेबियन (पुराने संस्करण और लेनी का मिश्रण) या हाल ही में उबंटू 10.4 एलटीएस चला रहे हैं। हमने प्रयोग हार्डवेयर और अन्य कंप्यूटरों के साथ इंटरफ़ेस करने के लिए बहुत से कस्टम सॉफ़्टवेयर लिखे हैं।

हमारे पास बहुत सारे एफपीजीए बोर्ड हैं जो प्रयोग के विभिन्न हिस्सों को नियंत्रित कर रहे हैं, ये यूएसबी के माध्यम से विभिन्न कंप्यूटरों से जुड़े हुए हैं। एक प्रयोग को नियंत्रित करने वाले कंप्यूटर को अपग्रेड करने के बाद हमने सभी लेजर चलाने वाले कंप्यूटर के क्रैश/लॉकअप को देखना शुरू कर दिया। यह पूरी तरह स्थिर था।

मेरा प्रश्न यह है: अगर ऊपर के साथ क) अजगर/जीटीके सॉफ्टवेयर जीयूआई ख) यूएसबी डिवाइस ड्राइवर या ग) वास्तविक डिवाइस इस लिनक्स को दोषी ठहराया जा सकता है एक मुद्दे की वजह से पूरे कंप्यूटर ताले कर्नेल (या ओएस के अन्य स्तर)?

क्या यह सॉफ़्टवेयर/हार्डवेयर के कार्यान्वयन में गलती करने के बावजूद लिनक्स कर्नेल से घबराहट नहीं करना गलत है।

मेरा खुद का अनुमान: किसी भी उपयोगकर्ता स्तर के अनुप्रयोगों को पूरी प्रणाली को कभी भी क्रैश करने में सक्षम नहीं होना चाहिए क्योंकि उन्हें केवल अपनी सामग्री तक पहुंच प्राप्त करनी चाहिए।

कोई भी डिवाइस ड्राइवर स्वयं कर्नेल का हिस्सा बन जाता है और इसलिए इसे क्रैश करने में सक्षम होगा। क्या मेरी तर्क आवाज है?

बोनस प्रश्न: क्या डिवाइस और कर्नेल को किसी भी तरह से इन्सुलेट करने का कोई तरीका है कि लिनक्स खुशी से चल रहा रहेगा इससे कोई फर्क नहीं पड़ता कि हार्डवेयर के साथ बेवकूफ गलतियां क्या हैं। यह दो कारणों से बहुत उपयोगी होगा: 1) एक चल रहे सिस्टम के साथ डीबगिंग आसान है, 2) प्रयोग के प्रयोजनों के लिए हमें वास्तव में लंबे समय तक आवश्यकता है और सिस्टम क्रैश का केवल एक हिस्सा होने पर एक में दुर्घटनाओं से असीम रूप से बेहतर है बाकी के प्रचार के लिए प्रणाली का हिस्सा।

इस विषय पर किसी भी लिंक और पढ़ने की सामग्री की सराहना की जाएगी। धन्यवाद।

+0

मैं दुर्घटनाओं में कोई विशेषज्ञ नहीं हूं, लेकिन मैं कहूंगा कि आप अपने अनुमानों में सही हैं। बोनस प्रश्न के बारे में, _logical_ त्रुटियों (यानी खराब प्रोटोकॉल) को कर्नेल द्वारा कोई और समस्या नहीं होने चाहिए; लेकिन _phisical_ त्रुटियां (यानी शॉर्टकटकिट, ओवरकुरेंट, इत्यादि) सामान्य रूप से कर्नेल द्वारा प्रबंधित नहीं की जा सकती हैं, और आपदा के विभिन्न स्तरों को उकसाएंगी। – rodrigo

उत्तर

3

आप सही हैं कि अनधिकृत कोड सिस्टम को नीचे लाने में सक्षम नहीं होना चाहिए, जब तक कोई कर्नेल बग न हो। अप्रतिबंधित और विशेषाधिकार के बीच की रेखा बिल्कुल उपयोगकर्ता-स्थान बनाम कर्नेल के समान नहीं है। यदि उपयोगकर्ता खाते में सुपरसुर विशेषाधिकार हैं, तो उपयोगकर्ता-मोड प्रोग्राम /dev/kmem खोल सकता है और ओएस के आंतरिक डेटा संरचनाओं को मिटा सकता है।

डिवाइस ड्राइवर समस्याओं से मुख्य कर्नेल को इन्सुलेट करने के लिए, डिवाइस ड्राइवर को वर्चुअल मशीन के अंदर चलाएं।

वीएमवेयर वर्कस्टेशन समेत कई लोकप्रिय वीएम सिस्टम मेजबान से डिवाइस पर विशिष्ट ड्राइवर के बिना मेजबान से अतिथि तक एक मनमानी यूएसबी डिवाइस को अग्रेषित करने का समर्थन करते हैं।

+0

प्रश्न का पालन करें। मान लें कि डिवाइस ड्राइवर सही ढंग से लिखा गया था किसी भी हार्डवेयर विफलता (संलग्न डिवाइस का) सिस्टम को नीचे लाने में सक्षम नहीं होना चाहिए, सही? – HansHarhoff

+0

@ हंसहहरॉफ: जब तक असफल हार्डवेयर कंप्यूटर पोर्ट के लिए निर्दिष्ट अधिकतम स्वीकार्य सहनशीलता का कारण नहीं बनता है, जहां इसे उल्लंघन करने के लिए संलग्न किया गया है, यह सही है।अधिकांश यूएसबी होस्ट शॉर्ट सर्किट के सहिष्णु हैं, उदाहरण के लिए। दूसरी तरफ, यदि आपके पास एक यूएसबी केबल पर बिजली की हड़ताल है, तो सभी शर्त बंद हैं क्योंकि अधिकतम रेटिंग पार हो जाएगी। –

+0

मेरी दो मुख्य चिंताओं के रूप में आप यूएसबी पोर्ट (या कम से कम वोल्टेज बूंद) के शॉर्ट सर्किट और हार्डवेयर के आकस्मिक/अचानक डिस्कनेक्टिंग कहते हैं। हम परीक्षण करने वाले हैं कि संचालित यूएसबी हब शॉर्ट सर्किट के लिए बफर के रूप में काम कर सकते हैं या नहीं। अचानक हटाने के संबंध में मुझे लगता है कि उत्तर की प्रतीक्षा करते समय महत्वपूर्ण चीजें कुछ समय निकालना है। – HansHarhoff