GrapheneOS ने ARM MTE से Bluetooth memory corruption का पता लगाया
(grapheneos.social)- Pixel 8·Pixel 8 Pro में hardware memory tagging सपोर्ट ने Android 14 QPR2 में Bluetooth LE में नया आया memory corruption bug उजागर किया
- कारण Bluetooth LE का upstream use-after-free bug निकला, और GrapheneOS ने fix patch तैयार किया है जिसे अगली release में शामिल किया जाएगा
- Samsung Galaxy Buds2 Pro के Bluetooth LE mode में समस्या को reproduce करने वाले यूज़र ने fix के काम करने की पुष्टि की, और stock Pixel OS भी इससे प्रभावित है
- GrapheneOS का मानना है कि Bluetooth एक बड़ा attack surface है, इसलिए उस process के लिए memory tagging बंद करने वाला workaround अल्पकाल में भी उपयुक्त नहीं है
- Android Bluetooth code का कुछ हिस्सा Rust में port किया गया है, लेकिन बाकी code migration और HWASan·MTE builds की real-device testing अभी और ज़रूरी है
Android 14 QPR2 का Bluetooth LE bug और fix
- GrapheneOS ने Pixel 8 और Pixel 8 Pro में hardware memory tagging सपोर्ट के ज़रिए Android 14 QPR2 के Bluetooth LE memory corruption bug का पता लगाया
- यह समस्या सभी Bluetooth devices में नहीं होती, बल्कि केवल कुछ खास Bluetooth LE devices पर reproduce होती है
- GrapheneOS नई जोड़ी गई functionality को fix करने या अस्थायी रूप से disable करने के तरीकों की जांच कर रहा है
- कारण Bluetooth LE का upstream use-after-free bug पाया गया, और GrapheneOS ने patch विकसित किया है
- प्राथमिकता यह है कि इस fix वाली GrapheneOS release को जल्दी deploy किया जाए
- इसे Android security bug के रूप में report किया जाएगा
- यह fix BLE audio regression को भी हल कर सकता है
- Bluetooth LE mode में Samsung Galaxy Buds2 Pro का उपयोग कर समस्या reproduce करने वाले यूज़र ने पुष्टि की कि fix काम करता है
- वही समस्या stock Pixel OS को भी प्रभावित करती है
- GrapheneOS ने hardened_malloc के memory tagging support से इसे detect किया और copy किए जा सकने वाले report के साथ MTE crash notification जोड़ा
MTE लागू करने का तरीका और Android Bluetooth code की चुनौतियाँ
- GrapheneOS इस process में memory tagging बंद करने वाले workaround को अल्पकाल में भी उपयुक्त नहीं मानता
- Bluetooth, इस bug के वास्तविक exploitation की संभावना से अलग भी, एक बड़ा attack surface है
- Android ने Bluetooth code का एक बड़ा हिस्सा Rust में port किया है, लेकिन बाकी code migration के लिए और resources चाहिए
- वास्तविक वातावरण में अलग-अलग Bluetooth devices पर HWASan और MTE builds की testing अभी और ज़रूरी है
- Pixel devices में बड़े hardware security feature के रूप में MTE मौजूद है, लेकिन default OS इसे 3.125% memory·cache usage reduction के कारण enable नहीं करता
- यह गणना tagged memory के हर 16 byte पर 4-bit tag के आधार पर है
- heap MTE में asynchronous mode में performance overhead लगभग 0% के करीब है, और asymmetric mode में इसकी लागत SSP जैसे मौजूदा mitigations से कम है
- GrapheneOS default OS के साथ compatibility ज्ञात user-installed apps पर MTE को default रूप से enable करता है
- Settings > Security में सभी user-installed apps के लिए इसे opt-in के रूप में चालू किया जा सकता है
- यह crash report को copy करने वाली notification और per-app toggle उपलब्ध कराता है
- GrapheneOS का hardened_malloc MTE implementation standard random tag और dedicated free tag का उपयोग करता है, और पिछले tag तथा वर्तमान या पिछले adjacent tag को dynamic रूप से exclude करता है
- Chromium integration को fix किया गया है, और PartitionAlloc में भी सुधार की योजना है
1 टिप्पणियां
Hacker News की राय
यह अजीब है कि Pixels में MTE जैसा बड़ा hardware security feature मौजूद है, फिर भी OS इसे सिर्फ़ 3.125% memory/cache usage बचाने के लिए चालू नहीं करता
मैं सच में देखना चाहूँगा कि Pixel टीम इस फ़ैसले को कैसे सही ठहराती है, और इतने मामूली performance फ़ायदे के लिए इतना महत्वपूर्ण security feature बंद रखने की सोच क्या थी
फिर भी GrapheneOS एक शानदार project है, लेकिन यह लगभग 11 devices को ही support करता है, जबकि AOSP changes में कहीं बड़े OEM ecosystem को ध्यान में रखना पड़ता है
हम हमेशा Android को बेहतर बनाने के तरीके खोजते रहते हैं, लेकिन किसी feature rollout की आलोचना करते हुए बड़े OEM ecosystem को नज़रअंदाज़ करना थोड़ी संकीर्ण सोच लगती है
यह feature चालू न होने की वजह memory/cache के 3% होने की संभावना बहुत कम लगती है, और शायद दूसरे factors भी रहे होंगे
feature को चालू करना है या नहीं, यह तय करते समय शायद यही ज़्यादा बड़ा factor रहा होगा
कहा जा रहा है कि दूसरे OS भी अभी MTE enabled होकर ship नहीं करते, इसलिए इसे चालू करना या न करना शायद अधिक सूक्ष्म निर्णय है
Google के लोगों ने शुरू से hardware MTE को आगे बढ़ाया था, और इसकी शुरुआत ASAN, syzkaller आदि में शामिल टीमों से हुई थी
वे Android टीम का हिस्सा नहीं थे, लेकिन Android की ओर से मदद और support था, और ARM जैसी कंपनियों के साथ सहयोग भी स्वाभाविक था
उस समय मैं उन टीमों का नेतृत्व कर रहा था, इसलिए मैं इन trade-offs को अच्छी तरह जानता हूँ; बात सिर्फ़ memory या cache की नहीं है
MTE को dynamically on/off किया जा सकता है, और इसे लगभग शून्य performance cost के साथ design किया गया था, लेकिन उस समय इसका मुख्य उपयोग sampling-based bug finding था
अगर पूरे device fleet में इसे सिर्फ़ 1% समय के लिए भी चालू किया जाए, तो बड़े scale पर bugs बहुत तेज़ी से पकड़े जा सकते हैं, और internal testing में भी इसका उपयोग हो सकता है
यानी लक्ष्य यह था कि ज़रूरत पड़ने पर ASAN-जैसी capability को चालू और बंद किया जा सके
इसे हमेशा-on security mitigation के रूप में इस्तेमाल करना एक द्वितीयक संभावना थी, और memory overhead के अलावा भी इसमें समस्याएँ हैं
उदाहरण के लिए, अचानक user-visible crashes बहुत बढ़ सकते हैं, और MTE वाले फ़ोन पर crash हो सकता है जबकि बिना MTE वाले फ़ोन पर नहीं, इसलिए consistency भी नहीं रहती
developer के नज़रिए से भी, जब MTE-enabled फ़ोन लगभग सिर्फ़ एक ही हो, तो सबको उसी फ़ोन पर test करने के लिए मजबूर करना सुखद नहीं होगा
यह security exploits को रोक सकता है, और exploitation की जगह crash करा सकता है
यह harmless bugs भी पकड़ सकता है
लेकिन जैसा मैंने कहा, मैं यह नहीं मानूँगा कि इसका उपयोग नहीं हो रहा; बल्कि यह मानना ज़्यादा सही होगा कि इसे production में हमेशा on नहीं रखा जाता
अगर किसी को ऐसे hardware features लाने का अनुभव है, तो वह कहेगा कि system का boot होना, चलना, और सिर्फ़ कुछ खास operations में ही MTE के तहत crash होना, अपने-आप में इस बात का अच्छा संकेत है कि इसका उपयोग पहले से हो रहा है
अगर इसका उपयोग नहीं हो रहा होता, तो शायद एक लाख बार crash हो चुका होता
और जोड़ूँ तो, यह भी स्पष्ट नहीं है कि runtime mitigation के रूप में यह सबसे अच्छा विकल्प है
डिफ़ॉल्ट Pixel शायद इसे end users के लिए default enabled state में न दे, लेकिन चाहें तो कोई भी developer options में Memory Tagging Extensions चालू कर सकता है
इसे बंद करने तक चालू रखा जा सकता है, या किसी specific app की testing के लिए सिर्फ़ एक session के लिए भी चालू किया जा सकता है
default Pixel OS में developer options से memory tagging support चालू करने का मतलब सिर्फ़ इसे available state में लाना है, वास्तव में इसका उपयोग नहीं करना
Android Debug Bridge(ADB) shell में
setpropके साथ heap memory tagging भी चालू करनी पड़ती हैअगर allocations पर tags नहीं लगाए जाते, तो सिर्फ़ enable होने का कोई मतलब नहीं है
default allocator implementation Scudo के ज़रिए default OS में userspace heap MTE को पूरी तरह चालू किया जा सकता है, लेकिन फ़िलहाल यह कोई विशेष रूप से hardened implementation नहीं है
MTE backend इस्तेमाल करने वाला KASan भी
setpropसे इस्तेमाल किया जा सकता है, लेकिन अभी इसे hardening के लिए design नहीं किया गया है, और आगे भी होगा या नहीं यह स्पष्ट नहीं हैkernel के लिए संभवतः KASan के किसी हिस्से के बजाय अलग MTE implementation चाहिए होगी, और GrapheneOS ने भी अभी तक ऐसा नहीं किया है, इसलिए मौजूदा MTE hardening एक userspace feature है
GrapheneOS hardened_malloc के लिए अपनी hardware memory tagging implementation इस्तेमाल करता है, और इसकी security properties अधिक मज़बूत हैं
इसे default OS में default enabled बनाने के लिए, इस issue सहित कई समस्याओं को ठीक करना या bypass करना पड़ता
main cores पर asynchronous MTE इस्तेमाल करने के बजाय यह सभी cores पर asymmetric mode इस्तेमाल करता है
asymmetric mode में writes के लिए asynchronous और reads के लिए synchronous behavior होता है, इसलिए exploit के सफल होने की कोई window नहीं बचती और इसे ठीक से block किया जाता है
system calls पर checks होते हैं, और io_uring, जो एक और bypass route हो सकता है, Android में SELinux restrictions के कारण सिर्फ़ 2 core system processes को ही allowed है
fastbootd सिर्फ़ installation के दौरान इस्तेमाल होता है, और snapuserd update लागू होने के बाद core OS में इस्तेमाल होता है
GrapheneOS उन apps के लिए हमेशा heap MTE इस्तेमाल करता है जिनकी default OS के साथ compatibility सत्यापित हो चुकी है
user-installed apps में, जो compatibility database में नहीं हैं और जिन्होंने खुद को compatible के रूप में mark नहीं किया है, उनके लिए per-app MTE toggle दिया जाता है
user चाहें तो सभी user-installed apps पर default रूप से MTE enforce कर सकते हैं, या सिर्फ़ incompatible apps को बाहर रख सकते हैं
इसे वास्तव में उपयोगी बनाने के लिए user-visible crash reporting system की ज़रूरत थी, और developers के लिए उपयोगी crash reports को आसानी से copy करके भेजने की सुविधा लागू की गई
settings में Memory Tagging Extensions खोजने पर दिखता है कि यह है, तो लगा शायद कहीं छिपा हुआ है, लेकिन पता चला कि यह सिर्फ़ Pixel 8 phones के लिए है: https://news.ycombinator.com/item?id=38125379
GrapheneOS सुरक्षा के मामले में दूसरों से इतना आगे है कि Pixel हार्डवेयर के अलावा कुछ और चुनना सवालों के घेरे में लगता है
लेकिन सच में replaceable battery चाहिए
समझ नहीं आता आजकल हर चीज़ इतनी खराब क्यों है
दूसरे Android डिवाइस उसके आसपास भी नहीं पहुँचते
hardware memory tagging support, Pixel के कई बड़े security advantages में से एक है
आधिकारिक hardware requirements list यहाँ है: https://grapheneos.org/faq#future-devices
ये requirements 8वीं पीढ़ी के Pixel में पूरी तरह पूरी होती हैं
6/7वीं पीढ़ी के Pixel में सिर्फ MTE, BTI, PAC नहीं हैं, जिनमें hardware requirements list में MTE सबसे मूल्यवान feature है
सही security patches इससे भी ज़्यादा महत्वपूर्ण हैं, और Pixel के बाहर वे उसी तरह उपलब्ध नहीं कराए जाते
Android में monthly, quarterly, और yearly releases होते हैं
दूसरे Android OEM, monthly security backports में सिर्फ Critical/High severity fixes ही पूरी तरह देते हैं, और privacy fixes सहित अधिकांश Moderate/Low severity fixes ज़्यादातर नहीं देते
alternative OS इस्तेमाल करने से और ऐसे patches देने से यह कुछ हद तक कम हो सकता है, लेकिन उन डिवाइसों के लिए alternative OS अक्सर कई तरीकों से security को पीछे ले जाते हैं
firmware और बहुत-सा device support code वास्तव में OEM से आता है
Android 12 kernel/drivers के ऊपर Android 14 QPR2 चलाना संभव है, लेकिन इससे OS के बड़े हिस्सों के security improvements छूट जाते हैं
Pixel battery को डिवाइस को नुकसान पहुँचाए बिना बदलना आसान तो नहीं है, लेकिन यह officially supported है और official parts भी उपलब्ध हैं: https://www.ifixit.com/Device/Google_Pixel
हम ऐसे असुरक्षित डिवाइसों को support नहीं कर सकते जिनमें बुनियादी चीज़ें भी पूरी नहीं हैं
हमारी hardware requirements list में एक साथ वे बहुत बुनियादी चीज़ें शामिल हैं जो ज़्यादातर Android OEM नहीं देते, और MTE जैसे advanced features भी, जिन्हें अब हम proper security की बुनियादी requirement मानते हैं
हम दूसरे डिवाइसों को भी support करना चाहते हैं, लेकिन उन डिवाइसों को ये requirements पूरी करनी होंगी
memory tagging, standard Cortex ARMv9 cores द्वारा समर्थित एक बुनियादी feature है
Qualcomm का इसे implement न करना, और ऐसे SoC इस्तेमाल करने वाले OEM का भी इसे enable न करना, निराशाजनक है
CPU architecture में feature मौजूद हो लेकिन SoC या OEM की वजह से उसे इस्तेमाल न कर पाना, वाकई दुखद है
फिर भी अच्छा है कि Pixel 8 को 7 साल का support मिलने वाला है
Apple और Samsung पर भी भरोसा करना मुश्किल है, और Google ही सबसे बेहतर विकल्प बन गया है
अच्छा होगा अगर GrapheneOS इस्तेमाल करने वाला कोई जवाब दे
लेकिन हाल ही में जब मैं अपनी पत्नी के साथ Orlando, Florida में Disney World और Universal Studios गया था, तब sandboxed Google Play Services के साथ apps ज़्यादातर चल रहे थे, फिर भी कुछ परेशान करने वाली समस्याएँ थीं
My Disney Experience app में location से जुड़ी काफी errors थीं, और बीच-बीच में यह दिखाता था कि कुछ ज़रूरी काम करने के लिए आपको अमेरिका या कनाडा में होना चाहिए, इसलिए मुझे पत्नी के फोन को workaround की तरह इस्तेमाल करना पड़ा
Universal app में मैं account login नहीं कर पाया, जबकि मेरी पत्नी के सामान्य Samsung Galaxy पर वह ठीक चल रहा था, इसलिए यह GrapheneOS की समस्या लगी
और अगर आप Google Wallet से credit card payment करना चाहते हैं, तो वह supported नहीं है क्योंकि Google GrapheneOS को certify नहीं करता
Wallet के बाकी features काम करते हैं
Uber बिना किसी समस्या के काम करता है
इसके अलावा मैं proprietary apps इस्तेमाल नहीं करता
अगर आप मुख्य रूप से free/open source apps इस्तेमाल करने वाले हैं, तो कोई समस्या नहीं होगी
ज़्यादातर proprietary apps sandboxed Google Play Services के साथ काम करती हैं, लेकिन अगर उनमें से कोई app आपके काम के लिए बहुत महत्वपूर्ण है, तो Universal Studio और My Disney Experience में मिली दिक्कतों जैसी परेशानियाँ आ सकती हैं
मैंने सामान्य USB cable और Linux command line का
adbइस्तेमाल किया, लेकिन recommended तरीका Chromium के WebUSB का है और non-technical लोगों के लिए वह आसान होना चाहिएहालांकि मेरे मामले में वह ठीक से काम नहीं किया
sandboxed Google Play Services होने की वजह से आप वे तमाम proprietary apps install कर सकते हैं जो आधुनिक जीवन को व्यावहारिक बनाती हैं, और साथ ही Google Play को पूरे फोन पर असीमित access भी नहीं मिलता, इसलिए दोनों तरफ़ के फायदे मिलते हैं
अगर आप और isolation चाहते हैं, तो अलग user बना सकते हैं और Google Play से जुड़ी चीज़ें उस account में चला सकते हैं
मैंने थोड़ी देर ऐसा करके देखा, लेकिन मुझे हर बार user switch करना झंझट लगा
फोन कभी crash नहीं हुआ, और banking apps भी काम करती हैं
device Pixel 6a है
आप preinstalled device भी खरीद सकते हैं, लेकिन web installer लगभग हर कोई इस्तेमाल कर सकता है
Android, ChromeOS, macOS पर यह खास तौर पर आसान है, और Windows में driver install करना पड़ता है इसलिए थोड़ा अधिक पेचीदा है
desktop Linux में
udevrules install करने पड़ते हैं, और जिन कुछ distributions में software versions fixed होते हैं, उनमें एक buggy service बाधा बन सकती हैnon-technical लोग भी इसे कर सकते हैं, बस WebUSB support करने वाला browser चाहिए
किसी खास software की ज़रूरत नहीं है
रोज़मर्रा के इस्तेमाल में sandboxed Google Play के साथ यह लगभग stock Pixel OS जैसा है, और app compatibility भी लगभग उतनी ही है
संभवतः आपको crash अर्थपूर्ण रूप से ज़्यादा नहीं मिलेंगे
इसमें user-facing crash reporting है जो base OS में नहीं होती, इसलिए आप ऐसे crashes नोटिस कर सकते हैं जिनका पता आपको वरना न चलता
जिन apps में memory corruption वाले buggy issues हों, वे per-app compatibility mode चालू करने तक crash हो सकती हैं, खासकर अगर आप सभी user-installed apps पर MTE force करने का विकल्प चुनते हैं
banking apps तब काम करेंगी जब bank Google-certified न होने वाले OS को अनुमति देता हो, और अभी अधिकांश देते हैं
लेकिन banks धीरे-धीरे Google-certified न होने वाले OS को block कर रहे हैं, इसलिए यह मूल रूप से एक anti-competitive regulatory issue के रूप में लिया जाना चाहिए
तब तक वे banks को https://grapheneos.org/articles/attestation-compatibility-guide इस्तेमाल करने के लिए मनाने की कोशिश कर रहे हैं
extra security features, sandboxing settings, और hardened memory allocator की वजह से यह हल्का-सा धीमा और stock Android इस्तेमाल करते हुए हर data access request पर OK दबा देने से थोड़ा ज़्यादा झंझटी है
शुरुआती setup में भी थोड़ा समय लगता है, और यह समझने में भी कि GrapheneOS में क्या अलग है और security features का इस्तेमाल कैसे करना है
4 साल इस्तेमाल करने में मुझे crash नहीं मिला
कम से कम system-wide crash तो नहीं हुआ, और कई दिनों तक debug करने लायक crashes मेरे अनुभव में नहीं होते क्योंकि Pixel hardware और software एक-दूसरे के साथ अच्छी तरह tuned हैं
banking apps app पर निर्भर करती हैं
कुछ apps Play Services के बिना भी चलती हैं, ज़्यादातर sandboxed Play Services के साथ चलती हैं, और बहुत कम apps बिल्कुल नहीं चलतीं
अगर आप बताएं कि कौन-सा bank इस्तेमाल करते हैं, तो दूसरा user उसके काम करने की पुष्टि कर सकता है
मुश्किल तरीका भी बस इतना है कि फोन को USB से जोड़ें, power/volume buttons थोड़े दबाएँ, फिर terminal commands की दो-तीन lines copy-paste कर दें
आसान तरीका तो सिर्फ फोन को computer से जोड़ना और Chrome browser में चलने वाले one-click install button को दबाना है
Google Pixel 6 आने के तुरंत बाद से मैं इसे लगभग लगातार daily-driver OS की तरह इस्तेमाल कर रहा हूँ, और एक बार भी crash नहीं हुआ
कभी ऐसा नहीं हुआ कि कोई bug आया हो या debug, fix, या maintenance की ज़रूरत पड़ी हो
मैंने जितनी apps आज़माईं, वे stock Android की तरह ही बस काम करती रहीं, और सच कहूँ तो मुझे शायद ही कोई फ़र्क महसूस हुआ
कभी-कभी तो मैं यह भी भूल जाता हूँ कि यह फोन के साथ मूल रूप से आया हुआ OS नहीं है
मेरे मामले में banking app Discover काम करती है, लेकिन बाकी apps के बारे में पक्का नहीं कह सकता
फिर भी Google Play services मौजूद हैं और install के बाद bootloader lock हो जाता है, इसलिए शायद ज़्यादातर apps काम करेंगी
2024 में seL4 की सोच को आगे बढ़ाते हुए उससे भी अधिक सख्त स्तर के formally verified operating systems, applications, और tools की ज़रूरत है
आज के समय में बस हल्के-फुल्के tested overengineered codebases और कमजोर व खतरनाक भाषाओं को जोड़कर चलाना ऐसा है कि कोई विदेशी actor hack करके users की जान तक ले सकता है, और साथ ही ढेर सारे परेशान करने वाले bugs, malware, और hacking attack surface भी बनते हैं
इसके ऊपर एक साफ-सुथरा, integrated user experience और उपयोगी functionality भी देनी होगी, नहीं तो पूरी engineering बेकार हो जाएगी
Qubes OS को देख लें
क्या कोई अच्छा single-board computer है जिसमें Arm MTE लागू हो? जैसे नवीनतम Raspberry Pi वगैरह
RasPi 5 quad A76 है और v8.2 extensions का उपयोग करता है, जबकि MTE v8.5 है
MTE की तुलना CHERI से कैसी है?
MTE संभावित security bugs खोजने के लिए है, यह वास्तविक protection नहीं है
tags सिर्फ 4-bit के हैं और application उन्हें forge कर सकती है, इसलिए अगर हमलावर को सही tag का अनुमान लगाना हो, तो random चुनने पर भी 1/16 संभावना से सही हो सकता है
MTE लागू करने का विचार यह है कि कभी-कभी हमलावर न होने पर भी गलत access हो जाता है, और ऐसे मामलों को पकड़ा जा सकता है जो वास्तव में खराब परिणाम नहीं बनाते
एक सामान्य buffer overflow को देखें तो buffer के ठीक बाद वाले words शायद किसी दूसरे काम में उपयोग न हो रहे हों, इसलिए व्यवहार में वह चल भी सकता है
MTE ऐसे access का पता लगाता है और उन्हें weaponized exploit बनने से पहले जाँचने और patch करने देता है
हालांकि reserved tags के जरिए मजबूत deterministic security properties दी जा सकती हैं
untagged चीज़ों का tag 0 होता है, और tagged चीज़ों के पास default exclusion के कारण सामान्यतः non-zero tag होता है
दूसरे tags को भी instructions के जरिए statically और dynamically exclude किया जा सकता है, लेकिन अगर 0 tag को freed memory जैसे internal use के लिए इस्तेमाल करें, तो किसी भी tagged pointer से उस तक access नहीं हो सकता
hardened_malloc allocation slots के लिए adjacent tags और पहले उपयोग किए गए tags को dynamically exclude करता है
इससे linear overflow और छोटे overflows के खिलाफ deterministic protection मिलती है
use-after-free के मामले में, freed allocation को point करने वाला pointer उसके freed रहने के दौरान या दोबारा allocate होने के तुरंत बाद access नहीं कर सकता, और उसे अगली बार फिर assign होने तक इंतज़ार करना पड़ता है; तब भी सही tag होने की संभावना 1/15 होती है
यह hardened_malloc की दूसरी security properties के साथ अच्छी तरह जुड़ता है
slab allocation और virtual memory के लिए FIFO/random quarantine zones रखे जाते हैं, ताकि reuse और देर से हो और deterministic न रहे
128k से ऊपर जाने तक अलग-अलग allocation size classes के बीच memory locations कभी reuse नहीं की जातीं, हर class अलग region में होती है, और metadata पूरी तरह एक अलग reserved region में रहता है
सामान्य स्थिति में MTE अभी सिर्फ 4-bit है, इसलिए bypass की संभावना लगभग 1/15 है
इसे 8-bit support तक आसानी से बढ़ाया जा सकता है, और अगर PAC का उपयोग न हो तो दूसरे spare bits भी हैं
सिद्धांत रूप से सामान्य 39-bit address space में, 48-bit address space या उससे ऊपर के लिए अधिकतम 16-bit MTE भी support किया जा सकता है
अभी यह 4-bit पर fixed है; सुना है 8-bit की जगह इसे इसलिए चुना गया ताकि ECC parity memory में अतिरिक्त bits store किए जा सकें
लेकिन यह CHERI जितनी reliability से detect नहीं करता
tags के लिए protection नहीं है और tag space भी छोटा है (2^4)
मुख्यधारा hardware को 2015 Solaris SPARC या उससे पहले की memory tagging architecture की बराबरी करते देख, उस दिन का इंतज़ार है जब memory corruption समस्या को आखिरकार काबू किया जा सकेगा
बेशक, अक्सर इन्हें ऐसे टाल दिया जाता है मानो ये समस्याएँ सिर्फ अयोग्य developers ही बनाते हों
यह “अयोग्य developers” की समस्या नहीं, सबकी समस्या है
memory corruption लगभग C/C++ की language feature जैसी है
यह धारणा फैलाना अच्छा नहीं कि यह सिर्फ बेवकूफ लोगों की वजह से होता है
लगभग कोई भी खुद को बेवकूफ नहीं समझता, और मैंने सच में बेहतरीन coders को भी अजीब memory bugs बनाते देखा है
यह बस उन भाषाओं के दायरे का हिस्सा है, और सवाल “अगर” का नहीं बल्कि “कब” का है
मुझे यह पसंद आया कि उसमें हल्के से यह बात डाली गई कि Android ने Bluetooth code का काफी हिस्सा Rust में स्थानांतरित कर दिया है, और बाकी code को भी Rust में ले जाने के लिए अधिक resources लगाने चाहिए
मैंने कई साल C और C++ इस्तेमाल की हैं, लेकिन Rust का अनुभव नहीं है, इसलिए जिज्ञासा है कि C से Rust में port करते समय कितना refactoring चाहिए
सवाल को बाँटें तो, 1. C का Rust में कितना सीधा translation हो सकता है? क्या Rust structural reorganization या refactoring की माँग करता है?
2. Google इसे कैसे approach कर रहा है? क्या वह इसे जितना संभव हो उतना करीब “translate” करने की कोशिश कर रहा है, या इसे बड़े rewrite/refactoring के अवसर की तरह देख रहा है?
यह भी जिज्ञासा है कि क्या Android Bluetooth stack कभी standard Linux distribution desktop systems पर इस्तेमाल करने लायक होगी
उसमें circular references बहुत थीं, इसलिए modules callbacks वाले “signal bus” के ज़रिए एक-दूसरे से बात करते थे, और Rust मदद करने से ज़्यादा लड़ता हुआ लगा
C++ में जहाँ data inline store कर सकते थे, वहाँ भी heap pointers यानी Box की बहुत ज़रूरत पड़ी
निष्कर्ष यह है कि अगर यह एक साधारण command-line tool हो या request-response structure हो, तो Rust port शायद आसान होगा
अधिक सामान्य रूप से, अगर code structure arena allocation के साथ अच्छी तरह फिट बैठता है, तो references पर lifetime tags लगाने वाले ढाँचे में ले जाना बहुत बड़ी समस्या नहीं है
लेकिन अगर आपने C programmer की शैली में circular references वाला, मानता हूँ, बदसूरत code लिखा है, तो Rust चढ़ाई जैसा लगेगा और वहीं से शुरू करना अच्छी जगह नहीं है
पहले C++ code structure बदलकर ownership को किसी common parent में ले जाना होगा
तब शायद चीज़ें बेहतर होंगी
मैं Rust को बार-बार और सीखते हुए, तब तक C++ में काम जारी रखूँगा जब तक code Rust के साथ बेहतर मेल न खाने लगे
जो आप लिख रहे हैं उसका बड़ा हिस्सा फिर से architect करना पड़ेगा
Rust जिस तरह memory safety सुनिश्चित करता है, उसकी वजह से इससे बचा नहीं जा सकता