💻 computer science

Dynamic Rowhammer Threshold Management:Temperature-Aware Threshold Degradation for In-DRAM Defenses

यह शोध पत्र डायनेमिक रोहैमर थ्रेशोल्ड मैनेजमेंट (Dynamic Rowhammer Threshold Management) का प्रस्ताव करता है, जो एक डिफेंस-अग्नोस्टिक (defense-agnostic) रनटाइम लेयर है जो एक लीनियर मॉडल और गार्डबैंड का उपयोग करके वास्तविक समय के तापमान के आधार पर इन-डीआरएएम (in-DRAM) रोहैमर मिटिगेशन थ्रेशोल्ड को अनुकूलित करता है, जिससे कम लेटेंसी बनाए रखते हुए SALT-C, PRAC और TRR सुरक्षा प्रणालियों में सुरक्षा उल्लंघनों को काफी कम किया जा सकता है।

मूल लेखक: Aziz Alajmi, Hoeseok Yang

प्रकाशित 2026-07-15

📖 5 मिनट में पढ़ें🧠 गहराई से पढ़ें

CC BY 4.0

मूल लेखक: Aziz Alajmi, Hoeseok Yang

मूल पेपर CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) के तहत लाइसेंस किया गया है। ✨ नीचे दिए गए पेपर की यह व्याख्या AI से तैयार की गई है। इसे लेखकों ने न तो लिखा है, न इसका समर्थन किया है। तकनीकी सटीकता के लिए मूल पेपर देखें। पूरा डिस्क्लेमर पढ़ें

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

समस्या यह है कि इन गार्डों को फैक्ट्री में एक एकल, निश्चित संख्या के आधार पर कैलिब्रेट किया गया था: "यदि एक अलमारी को 1,000 बार हिलाया जाता है, तो बटन दबाएं।" लेकिन यह लेख बताता है कि यह संख्या वास्तव में स्थिर नहीं है। यह तापमान के साथ बदलती है। ठीक वैसे ही जैसे गर्मी में रबर बैंड कमजोर हो जाता है, मेमोरी की अलमारियाँ गर्मी के साथ और भी नाजुक हो जाती हैं। एक अलमारी जो 65°C पर 1,000 झटकों को झेल सकती है, वह 85°C की गर्मी में केवल 760 झटकों के बाद टूट सकती है।

वर्तमान गार्ड जिद्दी हैं। वे तब भी 1,000 तक गिनते रहते हैं जब मेमोरी गर्म और नाजुक होती है। इससे एक "स्टेलेनेस विंडो" (stale window/पुरानापन अंतराल) पैदा होता है—एक खतरनाक अंतर जहाँ मेमोरी वास्तव में टूट रही होती है, लेकिन गार्ड सोचता है कि वह अभी भी सुरक्षित है।

नया समाधान: एक स्मार्ट, तापमान-जागरूक कोच

लेखक एक नया "कोच" लेयर प्रस्तावित करते हैं जो मेमोरी और गार्ड के बीच स्थित होता है। यह कोच गार्डों को हटाता नहीं है; यह बस हर कुछ मिलीसेकंड (जिसे epoch कहा जाता है) में उनके नियमों को अपडेट करता है।

यह कोच कैसे काम करता है:

थर्मामीटर की जाँच करें: कोच मेमोरी के तापमान सेंसर को पढ़ता है।
गणित लगाएँ: यह एक सरल सूत्र का उपयोग करता है कि गर्मी के कारण मेमोरी कितनी कमजोर हुई है।
सुरक्षा बफर जोड़ें: क्योंकि मेमोरी थोड़ी अप्रत्याशित है (जैसे पासा फेंकना), कोच अतिरिक्त सावधानी के लिए एक गार्डबैंड (सुरक्षा मार्जिन) जोड़ता है।
गार्ड को अपडेट करें: यह गार्ड को बताता है, "अरे, आज गर्मी है। 1,000 बार झटकों का इंतज़ार करने के बजाय, 760 झटकों पर रिफ्रेश बटन दबाएँ।"

यह हर 10 मिलीसेकंड (सिमुलेशन में 1.6 मिलियन चक्र) में होता है, जो गर्मी के साथ तालमेल बिठाने के लिए पर्याप्त तेज़ है लेकिन कंप्यूटर को धीमा करने के लिए पर्याप्त धीमा है।

सिमुलेशन ने क्या दिखाया

शोधकर्ताओं ने इस विचार का परीक्षण एक कंप्यूटर सिमुलेशन में किया (वास्तविक भौतिक चिप्स पर नहीं) जिसमें तीन प्रकार के गार्डों का उपयोग किया गया: PRAC, SALT-C, और TRR।

PRAC (प्रति-पंक्ति काउंटर): यह गार्ड गर्मी के प्रति सबसे अधिक संवेदनशील था। सिमुलेशन में, जब मेमोरी 85°C पर गर्म चली, तो पुराने "निश्चित" गार्ड ने 72 किताबें गिरने दीं (उल्लंघन)। नए डायनेमिक कोच ने इसे पूरी तरह से ठीक कर दिया, जिससे उल्लंघन घटकर शून्य हो गया।
SALT-C (समन्वित रिफ्रेश): इस गार्ड में पुराने सेटिंग्स के साथ 85°C पर 10 उल्लंघन हुए। नया कोच इसे घटाकर केवल 2 कर दिया (जो केवल स्टार्टअप ग्लिच थे जिन्हें "बूटस्ट्रैप" ट्रिक से ठीक किया जा सकता था)। इसकी लागत क्या थी? कंप्यूटर थोड़ा धीमा हो गया, जिसमें उच्च गर्मी पर औसत रीड लेटेंसी (read latency) में 5.1% की वृद्धि हुई। हालाँकि, ठंडी 65°C पर, यह नया तरीका पुराने "सुपर-सेफ" स्टैटिक सेटिंग की तुलना में 3.6% तेज़ था क्योंकि इसने उतनी बार रिफ्रेश नहीं किया जितनी इसकी आवश्यकता नहीं थी।
TRR (ट्रैकर): यह गार्ड उन "स्लॉट्स" द्वारा सीमित है जिनका उपयोग वह अलमारियों को ट्रैक करने के लिए करता है। सिमुलेशन ने दिखाया कि नए कोच के साथ भी, यह गार्ड विफल रहा क्योंकि इसके पास स्लॉट्स खत्म हो गए थे, न कि इसलिए कि तापमान नियम गलत था। कोच यहाँ एक नैदानिक उपकरण (diagnostic tool) की तरह कार्य कर रहा था, जिसने दिखाया कि गार्ड को केवल अधिक स्लॉट्स की आवश्यकता है, न कि एक स्मार्ट तापमान नियम की।

कमी और भविष्य

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

साथ ही, वास्तविक कंप्यूटरों पर इसके काम करने के लिए, कंप्यूटर के मुख्य प्रोसेसर (होस्ट) को मेमोरी के आंतरिक "नियम पुस्तिकाओं" (rule books) में लिखने की अनुमति मिलनी चाहिए। वर्तमान में, मानक इसकी अनुमति आसानी से नहीं देता है। लेखक दो मार्ग सुझाते हैं: या तो उद्योग मानक को अपडेट करे ताकि इसकी अनुमति मिले, या मेमोरी चिप स्वयं अपने अंतर्निहित थर्मामीटर का उपयोग करके गणित को आंतरिक रूप से करे।

निचोड़

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

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

तकनीकी सारांश: डायनेमिक रोहैमर थ्रेशोल्ड मैनेजमेंट (Dynamic Rowhammer Threshold Management)

समस्या विवरण (Problem Statement)
रोहैमर भेद्यता (Rowhammer vulnerability), जो रोहैमर थ्रेशोल्ड ( $T_{RHD}$ )—यानी बिट फ्लिप प्रेरित करने के लिए आवश्यक न्यूनतम पंक्ति सक्रियण (row activations) की संख्या—द्वारा लक्षित है, प्रत्येक DRAM पीढ़ी के साथ तीव्र हुई है, जो 2014 में ~139K से गिरकर आधुनिक DDR4 में 4.8K से नीचे और DDR5 के लिए 1K से कम हो गई है। वर्तमान इन-DRAM सुरक्षा उपाय (TRR, PRAC, और SALT-C) सक्रियणों को ट्रैक करके और एक निश्चित थ्रेशोल्ड से अधिक होने पर विक्टिम रोज़ (victim rows) को रिफ्रेश करके इसे कम करते हैं।

हालाँकि, ये सुरक्षा उपाय निर्माण के समय एक स्थिर $T_{RHD}$ मान का उपयोग करके पैरामीटराइज किए जाते हैं। यह एक महत्वपूर्ण "थ्रेशोल्ड स्टेलेनेस" (threshold staleness) भेद्यता पैदा करता है क्योंकि वास्तविक $T_{RHD}$ रनटाइम ऑपरेटिंग स्थितियों, विशेष रूप से तापमान के साथ काफी बदल जाता है। SpyHammer [6] के संकलित डेटा से पता चलता है कि बिट एरर रेट (BER) और तापमान (50–95°C) के बीच लगभग रैखिक निर्भरता है, जिसके परिणामस्वरूप मॉड्यूल के भीतर BER में 3.3× तक का अंतर आता है। इसके अलावा, VRD [7] दर्शाता है कि थ्रेशोल्ड समय के साथ स्टोकेस्टिक (stochastic) रूप से उतार-चढ़ाव करते हैं। फलस्वरूप, एक 65°C के नाममात्र वातावरण के लिए कैलिब्रेट किया गया डिफेंस, उच्च तापमान (जैसे 85°C) पर संचालित होने पर चुपचाप कम सुरक्षा प्रदान कर सकता है, जिससे एक ऐसा शोषण योग्य विंडो (exploitable window) बन जाता है जहाँ कॉन्फ़िगर किया गया थ्रेशोल्ड वास्तविक भौतिक स्थितियों के लिए बहुत ढीला होता है।

कार्यप्रणाली (Methodology)
लेखक डायनेमिक रोहैमर थ्रेशोल्ड मैनेजमेंट का प्रस्ताव करते हैं, जो एक डिफेंस-एग्नोस्टिक (defense-agnostic) रनटाइम लेयर है जो मौजूदा काउंटर-आधारित सुरक्षा उपायों को रेट्रोफिट (retrofit) करती है। यह एक नया डिफेंस मैकेनिज्म होने के बजाय, प्रत्येक एपोक (epoch) (डिफ़ॉल्ट 10 ms) में देखे गए तापमान के आधार पर प्रत्येक डिफेंस के लिए थ्रेशोल्ड पैरामीटर को गतिशील रूप से पुन: स्रोत (re-source) करता है।

कार्यप्रणाली में तीन घटक शामिल हैं:

डायनेमिक $T_{RHD}$ मॉडल: प्रभावी थ्रेशोल्ड ( $T_{RHDeff}$ $T_{R H D e f f}$ ) की गणना इस प्रकार की जाती है:
$T_{RHDeff}(t) = T_{RHDinit} \cdot f_{temp}(T) \cdot g$
- तापमान कारक ( $f_{temp}$ ): SpyHammer [6] डेटा के लीनियर रिग्रेशन से प्राप्त, जो तापमान बढ़ने के साथ $T_{RHD}$ के क्षरण को मॉडल करता है। यह मॉडल मैन्युफैक्चरर आईडी (MID) के आधार पर लुकअप टेबल का उपयोग करके वेंडर-विशिष्ट विविधताओं (जैसे सैमसंग का इनवर्टेड साइन) को संभालता है।
- गार्डबैंड ( $g$ ): एक मल्टीप्लिकेटिव डेरेटिंग फैक्टर (प्रायोगिक रूप से 0.9 निर्धारित) जो स्टोकेस्टिक टेम्पोरल वेरिएशंस (VRD [7]) और प्रति-रो डिस्पर्शन को ध्यान में रखता है जिसे जनसंख्या-औसत तापमान मॉडल द्वारा कैप्चर नहीं किया जा सकता है।
पर-एपोक अपडेट प्रक्रिया: कंट्रोलर SPD-साइड सेंसर्स (DDR4) या SPD-Hub सेंसर्स (DDR5) से तापमान का नमूना लेता है, $T_{RHDeff}$ की गणना करता है, और इस मान को सक्रिय डिफेंस के विशिष्ट थ्रेशोल्ड वेरिएबल पर प्रोजेक्ट करता है।
थ्रेशोल्ड प्रोजेक्शन: यह लेयर गणना की गई $T_{RHDeff}$ $T_{R H D e f f}$ को प्रत्येक डिफेंस के विशिष्ट सुरक्षा अनुबंध (security contract) पर मैप करती है:
- SALT-C: एक्टिवेशन पर मिनट (APM) पैरामीटर की पुनर्गणना करता है ताकि यह सुनिश्चित हो सके कि अधिकतम सक्रियण ($MaxACT$) क्षरित भौतिक थ्रेशोल्ड से नीचे रहे।
- PRAC: ABO ग्रेस बजट में से $T_{RHDeff}$ को घटाकर प्रति-रो अलर्ट थ्रेशोल्ड ( $ATH_{PRAC}$ ) को समायोजित करता है।
- TRR: फिक्स्ड-डेप्थ ट्रैकर थ्रेशोल्ड को $T_{RHDeff}/2$ में समायोजित करता है।

महत्वपूर्ण रूप से, यह लेयर केवल थ्रेशोल्ड को सख्त (tighten) करती है (कभी भी ढीला/relax नहीं करती), जिससे अंतर्निहित डिफेंस के शुद्धता तर्कों (correctness arguments) को बनाए रखा जा सके।

प्रमुख योगदान (Key Contributions)

एक डिफेंस-एग्नोस्टिक रनटाइम लेयर: एक तंत्र जो थ्रेशोल्ड पैरामीटर को स्थिर मैन्युफैक्चरिंग कांस्टेंट से अलग करता है, जिससे इसे कोर डिफेंस लॉजिक को बदले बिना रनटाइम थर्मल स्थितियों के अनुकूल बनाया जा सकता है।
एकीकृत मूल्यांकन ढांचा (Unified Evaluation Framework): एक "डिकपल्ड ओरैकल" (decoupled oracle) का उपयोग करके तीन अलग-अलग डिफेंस आर्किटेक्चर (SALT-C, PRAC, TRR) पर मूल्यांकन। यह ओरैकल वास्तविक दुनिया की भिन्नता को टेस्ट करने के लिए भौतिक $T_{RHD}$ को प्रति-DIMM एक स्टोकेस्टिक कारक $\delta \sim N(1, \sigma)$ से स्केल करता है, जिससे मॉडल की आंतरिक धारणाओं के बजाय वास्तविक भिन्नता का परीक्षण सुनिश्चित होता है।
हार्डवेयर व्यवहार्यता विश्लेषण: पेपर दो परिनियोजन पथों को रेखांकित करता है: एक होस्ट-साइड कार्यान्वयन जिसके लिए JEDEC मानक अपडेट की आवश्यकता है (प्रति-बैंक थ्रेशोल्ड रजिस्टरों को एक्सपोज़ करना) और एक ऑन-डाई कार्यान्वयन जो मौजूदा आंतरिक थर्मल सेंसर्स और ROM टेबल्स का उपयोग करता है, जिससे नए होस्ट-राइटेबल रजिस्टरों से बचा जा सके।

परिणाम (Results)
मूल्यांकन 7M साइकल के दौरान डबल-साइडेड रोहैमर ट्रेस (600K एक्टिवेशन) के साथ DRAMSim3 का उपयोग करके किया गया था।

PRAC: नाममात्र-स्थिर (nominal-static) कॉन्फ़िगरेशन (65°C पर कैलिब्रेट किया गया) 85°C पर 72 उल्लंघन (breaches) का शिकार हुआ। डायनेमिक लेयर ने इसे $\sigma=0$ पर 0 उल्लंघन तक कम कर दिया। स्टोकेस्टिक वेरिएंस ( $\sigma=0.10$ ) के साथ भी, गार्डबैंड ( $g=0.9$ ) के साथ डायनेमिक लेयर ने उल्लंघनों को 38.4 (जब $g=1.0$ था) से घटाकर 9.6 कर दिया।
SALT-C: नाममात्र-स्थिर कॉन्फ़िगरेशन में 85°C पर 10 उल्लंघन हुए। डायनेमिक लेयर ने इसे 2 उल्लंघन तक कम कर दिया (जो पहले-एपोक ट्रांजिएंट्स के कारण थे), जिन्हें बूटस्ट्रैप पॉलिसी का उपयोग करके 0 तक समाप्त कर दिया गया। डायनेमिक ऑपरेशन ने 85°C पर नाममात्र-स्थिर की तुलना में 5.1% का लेटेंसी कॉस्ट लिया, लेकिन यह 65°C पर सबसे खराब स्थिति वाले स्टेटिक कॉन्फ़िगरेशन (85°C के लिए कैलिब्रेट किया गया) की तुलना में 3.6% सस्ता था।
TRR: लेयर मुख्य रूप से TRR के लिए एक डायग्नोस्टिक टूल के रूप में कार्य करती है। एक छोटे ट्रैकर डेप्थ ( $K=4$ ) पर, TRR क्षमता सीमाओं (इविक्शन) के कारण विफल हुआ, जिससे कैलिब्रेशन के बावजूद उच्च उल्लंघन संख्या देखी गई। लेयर तभी प्रभावी हुई जब ट्रैकर डेप्थ को बढ़ाया गया ( $K \ge 16$ )।
ओवरहेड: गणना की लागत नगण्य है (<1 ns)। प्रमुख लागत प्रति-बैंक रजिस्टरों में नए थ्रेशोल्ड लिखने के लिए आवश्यक मेमोरी बैंडविड्थ है, जिसका अनुमान ~260 ns प्रति 10 ms एपोक (0.003% DRAM बैंडविड्थ) है।

महत्व और दावे (Significance and Claims)
पेपर दावा करता है कि डायनेमिक रोहैमर थ्रेशोल्ड मैनेजमेंट उस "थर्मल-स्टेलेनेस" गैप को भरता है जो स्थिर डिफेंस को गर्म ऑपरेटिंग वातावरण में असुरक्षित बनाता है। यह प्रदर्शित करता है कि एक पतला रनटाइम लेयर DRAM आर्किटेक्चर या डिफेंस एल्गोरिदम के मूल डिजाइन को बदले बिना मौजूदा डिफेंस के पैरामीटराइजेशन को रेट्रोएक्टिवली ठीक कर सकता है।

लेखक स्पष्ट रूप से सीमाओं का उल्लेख करते हैं:

परिणाम सिम्युलेशन-आधारित हैं; तैनाती के लिए तापमान बनाम $HC_{first}$ (पहले बिट फ्लिप के लिए एक्टिवेशन काउंट) का ऑन-सिलिकॉन लक्षण वर्णन आवश्यक है।
लीनियर टेम्परेचर मॉडल DDR4 डेटा से प्राप्त है और प्रोसेस परिवर्तनों के कारण DDR5 के लिए बिना री-फिटिंग के सामान्यीकृत नहीं हो सकता है।
दृष्टिकोण यह मानता है कि देखा गया तापमान वास्तविक सेल तापमान को दर्शाता है, जो इसे सेंसर स्पूफिंग या थर्मल मैनिपुलेशन हमलों के प्रति संवेदनशील बनाता है, हालांकि ऑन-डाई सेंसर कार्यान्वयन इसे कम करता है।
यह लेयर गैर-काउंटर-आधारित डिफेंस (जैसे रो-स्वैप) या ब्लैकस्मिथ (Blacksmith) या ज़ेनहैमर (ZenHammer) जैसे विशिष्ट अटैक पैटर्न को संबोधित नहीं करती है, हालांकि यह उनके प्रति ऑर्थोगोनल (orthogonal) होने की उम्मीद है।

अंततः, यह कार्य स्वयं को एक नए डिफेंस के रूप में नहीं, बल्कि एक आवश्यक रनटाइम मैनेजमेंट लेयर के रूप में प्रस्तुत करता है जो यह सुनिश्चित करता है कि काउंटर-आधारित डिफेंस के पैरामीटर गतिशील थर्मल स्थितियों के तहत वैध बने रहें।

नया समाधान: एक स्मार्ट, तापमान-जागरूक कोच

सिमुलेशन ने क्या दिखाया

कमी और भविष्य

निचोड़

इसी तरह के और पेपर