प्रणालीगत भाग 3: OMFS3 और लिबरेट

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











पिछले भाग:

RTOS सिस्टीकस द्वारा पहली सार्वजनिक उपस्थिति

प्रणालीगत भाग 2: जीयूआई





मैं तुरंत ध्यान देना चाहता हूं कि मैंने अपना एफएस लिखने का फैसला क्यों किया, और उपवास नहीं किया, उदाहरण के लिए, एफएटी, एनटीएफएस (कांटा एनटीएफएस कोलीबरी कोड) या ext2 / 3। मैं चाहता था कि शुरू में इसे लागू करना आसान हो, जबकि एक्स्टेंसिबल और सुरक्षित हो।



सादगी । यह बुनियादी स्तर पर जर्नलिंग की अनुपस्थिति में होता है। सब कुछ काफी सरल रूप से व्यवस्थित किया गया है - बड़े क्लस्टर हैं (प्रत्येक में 64 किलोबाइट, क्योंकि ओएस सिस्टमिकस में मॉलोक प्रत्येक 64k आवंटित करता है), कुछ समूहों में फाइलों और उपनिर्देशिकाओं के बारे में जानकारी होती है, जबकि अन्य में डेटा होता है। पहला क्लस्टर विभाजन जानकारी के लिए आरक्षित है + भविष्य के एक्सटेंशन के लिए बहुत सारे स्थान (अब यह केवल पहले 64 बाइट्स का उपयोग करता है)।



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



एक और सिस्टम क्लस्टर है (या डिस्क आकार बड़ा है तो क्लस्टर)। इसका पता अब तय नहीं है, लेकिन अनुभाग सेटिंग्स में इंगित किया गया है। यह एक विभाजन बाइट मानचित्र है, जहां प्रत्येक बाइट इंगित करता है कि संबंधित क्लस्टर मुक्त है या नहीं। बिट क्यों नहीं? तो यह आसान है + मैं अनुभव से जानता हूं कि भविष्य में कुछ काम आ सकता है, उदाहरण के लिए, संकेत करें, इसके अलावा 0 और 1, अन्य राज्यों, उदाहरण के लिए, यह क्षतिग्रस्त है, केवल-पढ़ने के लिए, आदि। बाइट कार्ड के साथ एक क्लस्टर 65 536 (एक क्लस्टर पर कार्ड में रिकॉर्ड की संख्या) का कवरेज प्रदान करता है * 65 536 (क्लस्टर आकार) = 4 294 967 296 बाइट्स, अर्थात्। डिस्क स्थान के 4 गीगाबाइट। मेरे लिए, यह काफी स्वीकार्य है।



डेटा भंडारण कैसे व्यवस्थित है? मैंने कोई विशेष संरचना नहीं बनाई थी, बस प्रत्येक क्लस्टर के अंत में 2 पासवर्ड इंगित किए गए थे: वर्तमान क्लस्टर में महत्वपूर्ण डेटा का आकार (सिद्धांत रूप में, यह मान के साथ प्रेषित किया जा सकता है, क्योंकि संपूर्ण फ़ाइल का आकार अपने इनोड रिकॉर्ड के माध्यम से जाना जाता है) और वर्तमान फ़ाइल के डेटा के साथ अगले क्लस्टर का पता। यदि पता 0 है, तो यह डेटा श्रृंखला का अंतिम क्लस्टर है। सब कुछ सरल और तार्किक है - जब एक फ़ाइल पढ़ते हैं, तो हम हर बार एक अलग डेटा स्थान संरचना में स्विच किए बिना, डिस्क को क्रमिक रूप से एक्सेस करते हैं।



सबसे स्वादिष्ट

दरअसल, किस वजह से, अपने एफएस को लिखा गया था। तो, एफएस में एन्क्रिप्शन कम स्तर पर व्यवस्थित होता है, अर्थात। प्रत्येक क्लस्टर व्यक्तिगत रूप से एन्क्रिप्ट किया गया है, न कि कोई फ़ाइल। यानी फ़ाइल सिस्टम ड्राइवर स्तर पर। एन्क्रिप्शन दो अलग-अलग कुंजी के साथ 2 चरणों में होता है।

सबसे पहले, उपयोगकर्ता के पासवर्ड से, हम GOST 34.11-2012 के 256-बिट संस्करण के माध्यम से एक 256-बिट कुंजी (अधिक सटीक रूप से एक जोड़ी, एक पासवर्ड) प्राप्त करते हैं। क्लस्टर को पहली कुंजी के रूप में GOST 28147-89 एल्गोरिथ्म का उपयोग करके एन्क्रिप्ट किया गया है (मैं "परीक्षण" प्रतिस्थापन तालिका का उपयोग करता हूं, जिसे सेंट्रल बैंक ऑफ रूसी फेडरेशन उपयोग करता है)। क्लस्टर को फिर से दूसरी कुंजी के साथ एन्क्रिप्ट किया जाता है, लेकिन एल्गोरिथ्म उपयोगकर्ता द्वारा तब सेट किया जाता है जब फ़ाइल सिस्टम खुद बनाते हैं (स्वरूपण) - RC4, RC6, IDEA (धीमा संक्रमण) या ब्लोफिश -255 वैकल्पिक हैं।



महत्वपूर्ण! पहले दो समूहों को एन्क्रिप्ट किया गया है, पढ़ें कि क्यों (उनके लिए क्या उपयोग किया जाता है)।



इसके अलावा, यह एक उच्च स्तर पर एक फ़ाइल को एन्क्रिप्ट करने की क्षमता के लिए अलग से प्रदान किया जाता है, लेकिन फिर भी फ़ाइल सिस्टम स्तर पर। यानी इन दो एन्क्रिप्शन के शीर्ष पर, जो मुझे याद दिलाता है कि आप फ़ाइल पर लागू नहीं होते हैं, लेकिन क्लस्टर में, फ़ाइल को एन्क्रिप्ट करना संभव है। यह अवसर पंजीकृत है, लेकिन अभी तक मैंने इसे लागू नहीं किया है (समय की समस्या, जटिलता नहीं)।



विलुप्ति के बारे में

सबसे पहले, मुख्य पैरामीटर 64-बिट संस्करणों में संग्रहीत किए जाते हैं, अर्थात। आकारों के साथ कोई समस्या नहीं होगी (और यह देखते हुए कि संबोधित करना सेक्टर-बाय-सेक्टर है, और 64 किलोबाइट के समूहों के लिए, आप बहुत अधिक :-) संबोधित कर सकते हैं), साथ ही टाइमस्टैम्प (64 बिट्स) के साथ भी।

अभी भी अतिरिक्त फ़ाइल फ्लैग (एक्सेस, राइट्स, ...) के लिए जगह है। इसके अलावा, अन्य एक्सटेंशन के लिए बहुत सारे स्थान (1 क्लस्टर देखें)।

सिद्धांत रूप में, भविष्य में जर्नलिंग को लागू करना संभव है, मुझे कुछ विरोधाभासी नहीं दिख रहा है, जर्नल को एक अलग विशेष फ़ाइल या समूहों की एक श्रृंखला में लिखा जा सकता है।

एन्क्रिप्शन के साथ भी, एल्गोरिथ्म के प्रकार को बाइट चर में संग्रहीत किया जाता है, अर्थात। इन 4 के अलावा, आप अभी भी 252 अन्य एन्क्रिप्शन और हैशिंग एल्गोरिदम स्क्रू कर सकते हैं)



बन

लंबे समय से मैं अपना एनालॉग LeanFS GUI , tk बनाना चाहता था। हर बार मैन्युअल रूप से विभाजन को संकलित करना किसी भी तरह असुविधाजनक है ... और यहां तक ​​कि एफएस में भी GOST + RC4 को छोड़कर कोई एन्क्रिप्शन नहीं है (और वे अस्थायी रूप से विकास के समय के लिए अक्षम हैं)। इसलिए, एक लिखना होगा।



मैंने डेल्फी को चुना (मुझे गुस्सा नहीं आया, मैं सी / सी ++ की तरह नहीं हूं, या मैं नहीं जानता; ;-))। 2.5 दिनों के बाद मैंने इसे प्रबंधित किया, मैंने एक अलग dll के रूप में fasm पर एन्क्रिप्शन फ़ंक्शन किया और बस इसे अपने एप्लिकेशन पर भेज दिया। यह ध्यान दिया जाना चाहिए कि ब्लोफिश और आईडीईए के साथ अजीब अजीब चीजें हो रही हैं, इसलिए मैंने उन्हें इस संस्करण में बंद कर दिया, मेरे पास व्यक्तिगत रूप से पर्याप्त GOST + RC6 है।

इसलिए, लिबरटे ने कार्यक्रम को बुलाया और संक्षेप में यह न केवल मेरी फाइल सिस्टम के दर्शक को बदल दिया, बल्कि क्रिप्टोकरंसीजर :-) मैं इसे पहले से ही खुद इस्तेमाल करता हूं, मैंने खुद के लिए यह काम किया - वोल्फ्राम , लेकिन व्यक्तिगत फ़ाइलों का एन्क्रिप्शन था और यह सुविधाजनक नहीं था। अब अपने महत्वपूर्ण डेटा के लिए मैं लिबरेट का उपयोग करता हूं।



एन्क्रिप्शन गति के बारे में शिकायत न करें - मैं खुद सदमे में हूं, लेकिन सब कुछ आगे है।

मैं डाउनलोड लिंक देता हूं - nebka.ru/files/Liberte_0.1c.7z

नहीं, यहाँ एक और है, और पिछले लेख में हमने कसम खाई थी कि सर्वर कुछ गलत दे रहा था: http://yadi.sk/d/1up9km3cSBPvE



डाँटा) क्योंकि मैं इसे अपने दिमाग में लाना चाहता हूं। कंटेनर का प्रारूप स्थिर है, और कार्यक्रम पूरा किया जा सकता है।