grapheneos/hardened_mallocआधुनिक सिस्टम के लिए डिज़ाइन किया गया हार्डन्ड एलोकेटर। यह Android के Bionic libc में एकीकृत है और अन्य Linux-आधारित प्लेटफ़ॉर्म पर उपयोग के लिए musl और glibc के साथ एक डायनामिक लाइब्रेरी के रूप में बाह्य रूप से उपयोग किया जा सकता है। समय के साथ इसमें अधिक पोर्टेबिलिटी/एकीकरण जोड़ा जाएगा।
यह एक सुरक्षा-केंद्रित सामान्य प्रयोजन मेमोरी आवंटक है जो malloc API के साथ-साथ विभिन्न एक्सटेंशन प्रदान करता है। यह हीप करप्शन कमज़ोरियों के विरुद्ध पर्याप्त हार्डनिंग प्रदान करता है। सुरक्षा-केंद्रित डिज़ाइन के कारण पारंपरिक आवंटक डिज़ाइन की तुलना में बहुत कम मेटाडेटा ओवरहेड और विखंडन से होने वाली मेमोरी बर्बादी भी होती है। इसका लक्ष्य आवंटक माइक्रो-बेंचमार्क के बजाय दीर्घकालिक प्रदर्शन और मेमोरी उपयोग पर ध्यान केंद्रित करते हुए उचित समग्र प्रदर्शन प्रदान करना है। यह कॉन्फ़िगर करने योग्य संख्या में पूर्णतः स्वतंत्र एरिना के माध्यम से स्केलेबिलिटी प्रदान करता है, जिसमें एरिना के भीतर आंतरिक लॉकिंग को प्रत्येक आकार वर्ग के अनुसार और विभाजित किया गया है।
यह परियोजना वर्तमान में Bionic (Android), musl और glibc का समर्थन करती है। यह भविष्य में अन्य गैर-Linux ऑपरेटिंग सिस्टम का समर्थन कर सकती है। Android के लिए, कस्टम एकीकरण और अन्य हार्डनिंग विशेषताएँ हैं जिन्हें भविष्य में musl के लिए भी योजनाबद्ध किया गया है। glibc समर्थन malloc कार्यान्वयन को प्रतिस्थापित करने तक सीमित रहेगा क्योंकि musl निर्माण के लिए एक बहुत अधिक मज़बूत और स्वच्छ आधार है और समान उपयोग मामलों को कवर कर सकता है।
यह आवंटक OpenBSD malloc को विभिन्न अतिरिक्त सुरक्षा विशेषताओं के साथ विस्तारित करने पर आधारित पिछले कार्यान्वयन के उत्तराधिकारी के रूप में अभिप्रेत है। यह अभी भी मुख्य रूप से OpenBSD malloc डिज़ाइन पर आधारित है, हालाँकि हैश तालिका कार्यान्वयन के पुनः उपयोग के अलावा मौजूदा कोड पर नहीं। डिज़ाइन में मुख्य अंतर यह हैं कि यह पूरी तरह से बग खोजने के बजाय हार्डनिंग पर केंद्रित है, आंतरिक विखंडन को कम करने के लिए 4k से आगे जाने वाले slab आकारों के साथ बारीक आकार वर्गों का उपयोग करता है, कर्नेल में बारीक mmap रैंडमाइज़ेशन पर निर्भर नहीं करता है और बड़े पते स्थान का आक्रामक उपयोग करने के लिए केवल 64-बिट को लक्षित करता है। कार्यान्वयन दृष्टिकोण में बहुत सारे छोटे अंतर हैं। यह OpenBSD malloc में किए गए पिछले एक्सटेंशन को शामिल करता है, जिसमें canaries के लिए आवंटन में पैडिंग जोड़ना (वर्तमान OpenBSD malloc canaries से भिन्न), मुक्त करने पर मौजूदा क्लियरिंग से जुड़ी write-after-free पहचान, आवंटन को क्वारंटीन करने के लिए मौजूदा रैंडमाइज़्ड सरणियों के साथ कतारें और क्वारंटीन किए गए आवंटन के लिए उचित double-free पहचान शामिल है। अपने स्वयं के रैंडम आधारों वाले प्रति-आकार-वर्ग मेमोरी क्षेत्र PartitionAlloc में आकार और प्रकार-आधारित विभाजन से कुछ हद तक प्रेरित थे। OpenBSD malloc में नियोजित परिवर्तन अंततः बहुत व्यापक और आक्रामक हो गए, इसलिए इस परियोजना को एक नए कार्यान्वयन के रूप में शुरू किया गया जो लक्ष्यों को बेहतर ढंग से पूरा कर सके। 32-बिट के लिए, छोटे एक्सटेंशन के साथ OpenBSD malloc का एक पोर्ट इसके बजाय उपयोग किया जा सकता है क्योंकि यह आवंटक मूल रूप से उस वातावरण का समर्थन नहीं करता है।
Debian stable (वर्तमान में Debian 13) समर्थित निर्भरताओं का सबसे पुराना समूह निर्धारित करता है:
Android के लिए, Linux GKI 6.1, 6.6 और 6.12 शाखाएँ समर्थित हैं।
हालाँकि, अधिक हाल के रिलीज़ का उपयोग करने की अत्यधिक अनुशंसा की जाती है। निर्भरताओं के पुराने संस्करण इस समय संगत हो सकते हैं लेकिन उनका परीक्षण नहीं किया गया है और स्पष्ट रूप से उनका समर्थन नहीं किया जाएगा।
musl के साथ बाहरी malloc प्रतिस्थापन के लिए, musl 1.1.20 आवश्यक है। हालाँकि, भविष्य में बेहतर प्रदर्शन प्रदान करने वाला कस्टम एकीकरण होगा साथ ही C मानक लाइब्रेरी कार्यान्वयन के लिए अन्य हार्डनिंग भी।
Android के लिए, केवल वर्तमान पीढ़ी, सक्रिय रूप से विकसित रखरखाव शाखा
Android Open Source Project की समर्थित होगी, जिसका वर्तमान में अर्थ है android17-release।
preload.sh स्क्रिप्ट का उपयोग glibc या musl का उपयोग करने वाले
डायनामिक रूप से लिंक किए गए निष्पादन योग्य फ़ाइलों के साथ परीक्षण के लिए किया जा सकता है:
./preload.sh krita --new-image RGBA,U8,500,500
गार्ड स्लैब और बड़े आवंटन गार्ड क्षेत्रों के कारण होने वाले बड़ी संख्या में
मैपिंग को समायोजित करने के लिए vm.max_map_count sysctl को काफी बढ़ाना आवश्यक हो सकता है। मैपिंग की संख्या
CONFIG_GUARD_SLABS_INTERVAL में महत्वपूर्ण वृद्धि के माध्यम से भी काफी कम की जा सकती है, लेकिन
इस सुविधा की प्रदर्शन और मेमोरी उपयोग लागत कम है इसलिए इसकी अनुशंसा नहीं की जाती है।
C मानक लाइब्रेरी में एकीकृत होने पर यह थोड़ा बेहतर प्रदर्शन प्रदान कर सकता है और C मानक लाइब्रेरी और डायनामिक लिंकर कार्यान्वयन के भीतर समान हार्डनिंग के लिए अन्य अवसर हैं। उदाहरण के लिए, एक लाइब्रेरी क्षेत्र को लागू किया जा सकता है ताकि डायनामिक लाइब्रेरी के लिए समान अलगाव प्रदान किया जा सके जैसा यह एलोकेटर विभिन्न आकार वर्गों में प्रदान करता है। इरादा यह है कि यह Bionic और musl C मानक लाइब्रेरी के हार्डन्ड वेरिएंट के हिस्से के रूप में प्रदान किया जाएगा।
सरल, स्वचालित परीक्षणों का एक संग्रह प्रदान किया गया है और इन्हें make कमांड के साथ निम्नानुसार चलाया जा सकता है:
make test
seccomp-bpf फ़िल्टर में mprotect PROT_READ|PROT_WRITE
सिस्टम कॉल की अनुमति देने के लिए OpenSSH 8.1 या उच्चतर आवश्यक है, प्रक्रिया को मारने के बजाय।
GrapheneOS पर, hardened_malloc को मानक malloc कार्यान्वयन के रूप में मानक C लाइब्रेरी में एकीकृत किया गया है। अन्य Android-आधारित ऑपरेटिंग सिस्टम इसे प्रदान करने के लिए एकीकरण कोड का पुन: उपयोग कर सकते हैं। यदि वांछित हो, तो jemalloc को रनटाइम कॉन्फ़िगरेशन विकल्प के रूप में छोड़ा जा सकता है, केवल सशर्त रूप से hardened_malloc का उपयोग करके उपयोगकर्ताओं को प्रदर्शन और सुरक्षा के बीच चयन देने के लिए। हालाँकि, यह उन खतरा मॉडलों के लिए सुरक्षा कम करता है जहाँ स्थायी स्थिति अविश्वसनीय है, अर्थात सत्यापित बूट और प्रमाणन (प्रमाणन सहयोगी परियोजना देखें)।
hardened_malloc द्वारा बनाए गए बहुत बड़ी संख्या में गार्ड पेजों को समायोजित करने के लिए
vm.max_map_count को भी काफी बढ़ाना सुनिश्चित करें। यह
init.rc (system/core/rootdir/init.rc) में अन्य वर्चुअल मेमोरी
कॉन्फ़िगरेशन के पास किया जा सकता है:
write /proc/sys/vm/max_map_count 1048576
यदि आप बिल्ड कॉन्फ़िगरेशन में CONFIG_GUARD_SLABS_INTERVAL को बहुत बड़े
मान पर सेट करते हैं तो यह अनावश्यक है।
पारंपरिक Linux-आधारित ऑपरेटिंग सिस्टम पर, hardened_malloc को या तो
मानक malloc कार्यान्वयन के प्रतिस्थापन के रूप में libc कार्यान्वयन में एकीकृत किया जा सकता है या डायनामिक लाइब्रेरी के रूप में लोड किया जा सकता है। प्रत्येक निष्पादन योग्य फ़ाइल को इसके विरुद्ध लिंक करने के लिए पुनर्निर्माण करने के बजाय, इसे
/etc/ld.so.preload में प्रीलोडेड लाइब्रेरी के रूप में जोड़ा जा सकता है। उदाहरण के लिए, libhardened_malloc.so
को /usr/local/lib/libhardened_malloc.so में स्थापित करने के साथ, उस पूर्ण पथ को
/etc/ld.so.preload कॉन्फ़िगरेशन फ़ाइल में एक पंक्ति के रूप में जोड़ें:
/usr/local/lib/libhardened_malloc.so
इस कॉन्फ़िगरेशन फ़ाइल का प्रारूप व्हाइटस्पेस-पृथक सूची है, इसलिए प्रत्येक लाइब्रेरी को अलग पंक्ति पर रखना अच्छा अभ्यास है।
अधिकतम संगतता के लिए libhardened_malloc.so को
/usr/lib/ में स्थापित किया जा सकता है ताकि AppArmor प्रोफ़ाइल या systemd
ExecPaths= प्रतिबंधों के कारण होने वाली प्रीलोड विफलताओं से बचा जा सके। निम्नलिखित प्रारूप के लॉग की जाँच करें: