Downfall हमला

 (downfall.page)
1 पॉइंट द्वारा GN⁺ 2023-08-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • व्यक्तिगत और cloud कंप्यूटरों में व्यापक रूप से इस्तेमाल होने वाले Intel प्रोसेसर की CVE-2022-40982 vulnerability, जिससे उसी कंप्यूटर को साझा करने वाले दूसरे users का data चोरी किया जा सकता है
  • vulnerability का मूल कारण यह है कि memory optimization के दौरान Gather instruction speculative execution में internal vector register file की सामग्री expose कर देता है
  • हमला GDS·GVI techniques से implement होता है, और demo में AES keys, Linux Kernel data, तथा printable characters की निगरानी तक isolation boundaries के पार leakage दिखाया गया है
  • प्रभाव का दायरा Intel Core 6th gen Skylake से 11th gen Tiger Lake तक है, और cloud users पर असर पड़ सकता है भले ही वे सीधे Intel device own न करते हों
  • Intel का microcode update Gather के transient results को block करता है, लेकिन कुछ workloads में mitigation लागू होने के बाद 50% तक overhead हो सकता है

Downfall जिस vulnerability को निशाना बनाता है

  • Downfall personal computers और cloud computers में इस्तेमाल होने वाले modern processors की महत्वपूर्ण कमजोरी को target करता है
  • इस vulnerability की पहचान CVE-2022-40982 के रूप में हुई है
  • उसी कंप्यूटर को साझा करने वाले दूसरे users के data तक पहुंचकर उसे चोरी किया जा सकता है
    • App Store से लिया गया malicious app passwords, encryption keys, banking information, personal emails और messages जैसी sensitive information चुरा सकता है
    • cloud में, malicious customer उसी cloud computer को साझा करने वाले दूसरे customers का data और credentials चुरा सकता है

vulnerability का technical कारण

  • Intel processors की memory optimization capability internal hardware registers को अनजाने में software के सामने expose कर देती है
  • untrusted software उन दूसरे programs के data तक पहुंच सकता है, जिन तक उसे मूल रूप से पहुंच नहीं होनी चाहिए
  • memory में बिखरे हुए data को तेजी से पढ़ने के लिए बनी Gather instruction speculative execution के दौरान internal vector register file की सामग्री leak करती है
  • इसका फायदा उठाने वाली techniques के रूप में Gather Data Sampling(GDS) और Gather Value Injection(GVI) का इस्तेमाल होता है
  • technical details Downfall paper में संकलित हैं

demo में पुष्टि हुए leakage के मामले

  • Downfall demo दिखाता है कि अलग-अलग isolation boundaries के पार sensitive data leak हो सकता है
    • Video 7: दूसरे user की 128-bit और 256-bit AES keys चोरी करना
    • Video 8: Linux Kernel से arbitrary data चोरी करना
    • Video 9: printable characters की निगरानी

प्रभावित systems और attack conditions

  • प्रभावित devices Intel Core 6th gen Skylake से 11th gen Tiger Lake तक के processors पर आधारित computing devices हैं
  • प्रभावित processors की अधिक व्यापक list Intel की affected processors list में उपलब्ध कराई जाएगी
  • physical Intel-based device न होने पर भी cloud users प्रभावित हो सकते हैं
    • server market में Intel की हिस्सेदारी 70% से अधिक है
  • attackers passwords और encryption keys जैसे high-value credentials को target कर सकते हैं
  • credentials की चोरी confidentiality breach से आगे बढ़कर computer की availability और integrity को नुकसान पहुंचाने वाले दूसरे attacks तक ले जा सकती है
  • GDS को real-world attack के रूप में implement करना अपेक्षाकृत आसान है
    • OpenSSL से encryption key चुराने वाला end-to-end attack develop करने में 2 हफ्ते लगे
    • attacker और victim का same physical processor core share करना काफी है
    • preemptive multitasking और simultaneous multithreading implement करने वाले modern computers में ऐसा sharing अक्सर होता है

isolation boundaries, SGX, browser impact

  • Downfall सामान्य isolation boundaries को भी प्रभावित करता है
    • virtual machines
    • processes
    • user-kernel isolation
  • Intel SGX भी प्रभावित है
    • Intel SGX, malicious software से user data को protect करने के लिए Intel CPU की hardware security feature है
  • web browser के जरिए remote exploitation theoretically संभव है
    • browser में successful attack दिखाने के लिए वास्तव में additional research और engineering work की जरूरत है

exposure period और detection difficulty

  • users कम से कम 9 साल तक इस vulnerability के exposure में रहे
    • प्रभावित processors 2014 से मौजूद हैं
  • Downfall attacks detect करना कठिन है
    • execution pattern ज्यादातर normal applications जैसा दिखता है
    • theoretically, hardware performance counters का इस्तेमाल करके excessive cache misses जैसे abnormal behavior detect करने वाला system बनाया जा सकता है
    • सामान्य commercial antivirus software इस attack को detect नहीं कर सकता

mitigations और performance overhead

  • Intel ने microcode update release किया है
    • यह update Gather instruction के transient results को block करता है
    • attacker code को Gather से निकले speculative data को observe करने से रोकता है
  • mitigation का overhead इस बात पर निर्भर करता है कि program के critical execution path में Gather है या नहीं
  • Intel के अनुसार कुछ workloads में 50% तक overhead हो सकता है
  • workload Gather का इस्तेमाल नहीं करता, इसलिए mitigation बंद कर देना safe नहीं है
    • modern CPUs memory copy और register contents switching जैसे सामान्य operations को optimize करने के लिए vector registers का इस्तेमाल करते हैं
    • इस process में Gather का दुरुपयोग करने वाले untrusted code के जरिए data leak हो सकता है

disclosure schedule और reproduction code

  • यह vulnerability लगभग 1 साल तक embargo में थी
  • Intel को इसकी report 24 अगस्त 2022 को दी गई थी
  • Downfall को 9 अगस्त 2023 को BlackHat USA और 11 अगस्त 2023 को USENIX Security Symposium में present किया गया
  • reproduction code GitHub POC पर public है

दूसरे processor designers के लिए ध्यान देने योग्य बातें

  • दूसरे processors में भी core के अंदर hardware register files और fill buffer जैसी shared SRAM memory होती है
  • manufacturers को अलग-अलग security domains के बीच data leak न हो, इसके लिए shared memory units को ज्यादा सावधानी से design करना चाहिए
  • security verification और testing में ज्यादा investment करना चाहिए

नाम और related vulnerabilities

  • Downfall नाम इसलिए रखा गया क्योंकि इसका मतलब है कि यह ज्यादातर computers की basic security boundaries को गिरा देता है
  • Downfall को CPU की पिछली data leakage vulnerabilities Meltdown और Fallout का follow-up माना जा सकता है
  • इस sequence में Downfall पहले की mitigations को फिर से bypass करता है

vendor advisories और technical documents

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-08-09
Hacker News की रायें

  • शुरुआती Spectre attack के बाद भी बाहरी researchers का इसी तरह के attacks लगातार ढूंढते रहना और chip manufacturers का बाद में patch करना कुछ अजीब लगता है
    सिद्धांततः chip manufacturers ही speculative execution के experts होते हैं, chip के behavior को ठीक-ठीक जानते हैं, और उनके पास verification suites, simulators, यहां तक कि machine-readable internal specs भी होती हैं, इसलिए खोज करने में उन्हें सबसे बेहतर स्थिति में होना चाहिए
    बाहरी researchers को black box खंगालना पड़ता है और patents जैसी कहीं खराब सामग्री से reverse engineering करनी पड़ती है, फिर भी कई साल बाद भी individual या external groups ऐसी vulnerabilities खोज रहे हैं
    Spectre से पहले शायद ऐसे attack vectors पर विचार नहीं किया गया हो, लेकिन general mechanism सामने आने के बाद क्या chip manufacturers को अपने सबसे तेज लोगों को इकट्ठा करके “पूरी तरह छान मारो और दूसरे Spectre-जैसे attacks ढूंढो” नहीं कहना चाहिए था?
    हो सकता है वे पहले से सब जानते हों, लेकिन छवि और performance degradation से बचने के लिए उम्मीद कर रहे हों कि यह सार्वजनिक न हो और इसे दबाए रखा हो

    • यह survivorship bias हो सकता है। बिना सार्वजनिक हुए patch किए गए Spectre-जैसे bugs कितने हैं, यह हमें नहीं पता
    • यह तर्क असहज लगता है। इसी सोच से देखें तो memory safety errors दो बार करने वाले programmer को भी केवल मानवीय गलती नहीं, बल्कि दुर्भावनापूर्ण माना जा सकता है
      अगर कोई चीज अरबों लोग इस्तेमाल करते हैं, तो बनाने वालों से ज्यादा समस्याएं, defects और exploits बाहर के लोग खोजेंगे ही। सिर्फ इस तथ्य से कि ऐसी समस्या मौजूद है, उसके कारणों पर कोई अतिरिक्त निष्कर्ष न तो समर्थन पाता है, न खारिज होता है
    • एक संभावना जिसके बारे में अभी किसी ने नहीं कहा, यह है कि chip vendors ऐसी चीजें खोजने में ज्यादा समय इसलिए नहीं लगाते क्योंकि असल में ये बहुत महत्वपूर्ण नहीं हैं
      security researchers के पास अपनी प्रतिष्ठा बनाने के लिए कुछ खोज निकालने का incentive होता है। अक्सर वे किसी ऐसी चीज को दुनिया हिला देने वाली security vulnerability की तरह पेश करते हैं, जिसका real-world attackers के लिए ज्यादा मतलब नहीं होता
      क्या real-world environment में speculative execution attack कभी पाया गया है? शायद नहीं। अगर ऐसा है, तो chip vendor के पास इस पर बहुत पैसा खर्च करने की वजह कमजोर है
      असली customers को नुकसान नहीं होता, सिवाय तब जब कोई external researcher कार्रवाई के लिए मजबूर कर दे और performance धीमा करने वाला नया microcode जारी करवाए
      यह भी ध्यान देने लायक है कि ऐसे attacks के mitigations में हमेशा disable करने वाला switch लगा होता है। security fixes में यह आम pattern नहीं है, और कई मामलों में इसकी वजह यह है कि ये attacks खास महत्वपूर्ण नहीं हैं
      एक ही physical core या एक ही physical CPU पर चलने वाला software या तो समान trust level का होता है, या इतना मजबूत sandboxed होता है कि attack किया ही नहीं जा सकता
    • यह Kernighan के debugging law में फंसा मामला भी हो सकता है। “सब जानते हैं कि debugging, program को पहली बार लिखने से दोगुनी कठिन होती है। तो अगर आपने लिखते समय उसे जितना हो सके उतना clever बना दिया, तो फिर आप उसे debug कैसे करेंगे?”
      Intel बिना शक chips को “जितना संभव हो उतना clever” बनाता है, इसलिए परिभाषा के अनुसार उन्हें पूरी तरह debug नहीं किया जा सकता
    • CPU engineer के तौर पर कहूं तो, Spectre ने एक information leak channel उजागर किया जिसे पहले vulnerable नहीं माना जाता था। इसलिए नए exploits लगातार आए, उनके केंद्र में एक नया idea था, और दूसरे लोगों ने उसी idea पर आगे निर्माण किया
      यह बात भी महत्वपूर्ण है कि ये bugs नहीं हैं। design intended तरीके से काम कर रहा है। यह समझा गया था कि CPU का performance पहले execute हुए code के हिसाब से बदलता है, और alternatives की cost power, performance और area के लिहाज से बहुत ज्यादा मानी गई, इसलिए इसे स्वीकार किया गया। यही engineering है: alternatives को तौलकर चुनना
      इस मामले में CPU इतना तेज हो गया कि हर iteration में bit का छोटा हिस्सा attackable bandwidth बन गया, लेकिन industry को यह समझने के लिए किसी को इसे दिखाना जरूरी था। उसी ने engineering judgment बदला

  • Intel पेपर का लिंक टूट गया है, और सही लिंक यह लगता है: https://www.intel.com/content/www/us/en/developer/articles/t...
    सामान्य सावधानी के तौर पर, क्या अब भी कई cloud अलग-अलग users के workloads को एक ही physical core पर चलाते हैं? मुझे लगा था कि ज्यादातर ने कई साल पहले scheduler बदलकर hyperthreads के बीच cross-domain leaks रोक दिए थे
    यह दावा कि इससे Internet के सभी users प्रभावित होते हैं, बहुत बढ़ा-चढ़ाकर कहा हुआ लगता है. कोई browser-based exploit भी नहीं दिखा, और अगर वह मौजूद भी हो, तो सिर्फ निशाना बनाए गए बहुत ही कम users को प्रभावित करेगा. Spectre आए कई साल हो गए हैं, लेकिन असल environment में speculative execution attack कभी मिला है क्या, यह सोचता हूं
    ज्यादा दिलचस्प बात यह है कि ये speculative execution bugs लगातार microcode से patch किए जा सकने वाले दिखते हैं. जब ये पहली बार सामने आए थे, तो डर था कि शायद physical chips को बड़ी मात्रा में फेंककर replace करना पड़े, लेकिन क्या वास्तव में कभी ऐसा करना पड़ा?
    मेरी जानकारी में सभी bugs को software और microcode changes के combination से handle किया जा सका, और कुछ मामलों में सिर्फ थोड़ी performance cost देनी पड़ी. ऐसा कोई bug नहीं था जिसके लिए नया silicon चाहिए पड़ा हो. अपवाद शायद शुरुआती AMD SEV versions जैसे मामले हैं, जहां सचमुच unpatchable तरीके से jailbreak हो गया था

    • AWS/GCP/Azure जैसे बड़े cloud नहीं, ऐसे VPS providers बहुत बड़ी संख्या में हैं, और वहां जवाब “हां” है. जो जगहें ‘dedicated’ cores बेचती हैं, वहां भी अक्सर असल मतलब बस unlimited CPU usage देना होता है
    • Spectre attack को kernel में patch करना पड़ा था, और उसने Intel CPU execution speed को काफी धीमा कर दिया था: https://www.notebookcheck.net/Spectre-v2-mitigation-wreaks-h...
    • AWS के t instances का मकसद यही नहीं है क्या? मेरी समझ में वे core level पर “shared” होते हैं, और अगर ऐसा न हो तो CPU credit balance जैसी concept होने की कोई वजह नहीं है
    • मुझे लगता है कि ज्यादातर, शायद लगभग सभी cloud VMs dedicated cores देती हैं
      बेशक AWS की T series जैसी shared चीजें भी हैं और दूसरे clouds में भी ऐसी कुछ होंगी, लेकिन मेरा मानना है कि users के बीच extra “flush” डालकर tenant-to-tenant leakage रोका जा सकता है
      जाहिर है, single tenant के अंदर processes के बीच leakage cloud हो या on-premises, दोनों में समस्या है, और आखिर में आपको तय करना पड़ता है कि अपनी machine की processes के malicious न बन जाने पर आप कितना भरोसा करते हैं
    • “Internet के सभी लोगों” को प्रभावित करने की संभावना इसलिए कही गई क्योंकि ज्यादातर servers vulnerable हैं

  • अलग-अलग security domains के code को एक ही physical processor core पर चलाना ठीक से करना असंभव लगता है, और अब शायद इसे बंद कर देना चाहिए
    आम cases असल में सिर्फ दो हैं: VM और JavaScript
    VM को छोड़ना होगा. किसी खास core को किसी खास VM, या कम से कम किसी खास customer को dedicated देना होगा
    JavaScript थोड़ा ज्यादा मुश्किल है
    किसी भी तरफ, सामान्य cases में performance नहीं छोड़नी चाहिए

    • JavaScript के लिए “बस बंद कर दें” ठीक लगता है
    • यहां multicore को फिर से आगे लाने का marketing opportunity है. ज्यादातर workloads CPU में और cores जोड़ने पर diminishing returns के point तक पहुंच चुके हैं, लेकिन अगर निष्कर्ष यह निकले कि ज्यादा concurrent processes या browser tabs को safely चलाने के लिए ज्यादा cores चाहिए, तो 128-core laptop chips आ सकते हैं
    • मैं कुछ समय से सोच रहा था कि CPU को “IOPU” और “SPU” में बांटना समझ में आता है या नहीं
      IOPU system के बाकी hardware को direct करने की भूमिका निभाएगा, और उसका बहुत high performance होना जरूरी नहीं
      SPU को fast चलने वाले scalar code और branch-heavy code के लिए optimize किया जाएगा
      SPU में बस इतनी minimum security होनी चाहिए कि RAM से लाते समय arbitrary memory न पढ़ सके. एक समय में सिर्फ एक program चलेगा, इसलिए speculative execution समस्या नहीं बनेगा
      मेरे system में बहुत processing power मांगने वाले programs कम ही हैं, और जरूरत पड़ने पर भी वे intermittent होते हैं, इसलिए SPU पर task switching ज्यादा नहीं होगी
    • सही. यह तरीका अपने शिखर के बाद का दौर देख चुका है. 1960s से 1990s तक चले time-sharing systems का युग, यानी universities या ISPs के Unix systems में कई users के shell accounts होने का समय
      ऐसे CPU attacks दिखाते हैं कि जहां users arbitrary machine code चलाते हों, ऐसा safe time-sharing system अब realistic नहीं है
      time-sharing अब भी उन cases में रहेगा जहां लोग एक-दूसरे पर trust करते हैं, जैसे एक ही project के workers का build machine share करना
    • यह thermodynamics के second law जैसा है, उससे पहले जब statistical mechanics आकर उसे व्यवस्थित नहीं कर पाया था. विश्लेषणात्मक और दार्शनिक रूप से शायद यह बहुत मजबूत आधार पर न हो, लेकिन experimentally इतना मजबूत है कि इसके उलट बेचने वाला व्यक्ति बहुत संदिग्ध लगेगा
      यह विचार कि computer पर चल रहे दो programs को एक-दूसरे में झांकने से रोका जा सकता है, भी उसी स्तर का है

  • Intel security advisory: https://www.intel.com/content/www/us/en/developer/articles/t...
    Linux kernel merge: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

  • यह सिर्फ़ 11वीं पीढ़ी तक ही प्रभावित है, तो लगता नहीं कि यह vulnerability Intel को उस समय बताई गई होगी जब 12वीं पीढ़ी में इसे ठीक करने के लिए काफ़ी समय था. तो शायद किसी और चीज़ को ठीक करते हुए यह संयोग से हल हो गई होगी
    पेपर देखने पर लिखा है: “Intel ने कहा है कि Alder Lake, Raptor Lake, Sapphire Rapids जैसे नए CPU प्रभावित नहीं हैं. हालांकि यह security consideration के बजाय काफ़ी बदली हुई architecture का side effect लगता है”
    आखिरकार यह या तो संयोग से ठीक हो गया, या कम से कम यह खास exploit काम न करने लगा

    • Microarchitecture behavior हर generation में बदलता है, इसलिए side effects भी बदलते हैं. संयोग से किसी समस्या को ठीक कर देना, या संयोग से नई समस्या बना देना, दोनों ही तुलनात्मक रूप से अक्सर होते रहते हैं

  • FAQ के मुताबिक users कम से कम 9 साल तक इस vulnerability के संपर्क में थे. क्योंकि प्रभावित processors 2014 से मौजूद थे
    हैरानी की बात है कि ऐसी vulnerabilities कई साल तक नज़र नहीं आतीं, और फिर किसी को exploit code करने में सिर्फ़ 2 हफ़्ते लगते हैं

    • शुरुआत में vulnerability खोजने का समय 2 हफ़्तों से कहीं ज़्यादा रहा होगा
    • इसके public होने का मतलब सिर्फ़ इतना है कि किसी whitehat या greyhat researcher ने vulnerability खोजी. इस बीच कम ईमानदार पक्ष ने इसी flaw का दुरुपयोग किया या कितनी बार किया, यह जानने का कोई तरीका नहीं है
    • संभावना है कि यह पहले के exploits पर आधारित काम रहा हो

  • LWN article संदर्भ: https://lwn.net/Articles/940783/
    Linux में, जिन CPU के लिए updated microcode नहीं है, उनके लिए इस issue की mitigation के तौर पर AVX पूरी तरह disable कर दिया जाता है. मेरे हिसाब से यह काफ़ी कठोर है और इसका असर भी noticeable होगा. अब मन हो रहा है पता करूं कि updated microcode मिल सकता है या नहीं

    • AVX disabling सिर्फ़ तब लागू होती है जब gather_data_sampling=force इस्तेमाल किया जाए. default यह है कि AVX को वैसे ही रखा जाए और system को vulnerable के तौर पर mark किया जाए
      https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin... में देखें तो:
      gather_data_sampling=force specify करने पर, जहाँ संभव हो वहाँ microcode mitigation इस्तेमाल की जाती है, और जिन affected systems में वह mitigation शामिल करने के लिए microcode update नहीं हुआ है, उनमें AVX disable कर दिया जाता है
      संदर्भ के लिए, मैं Intel में Linux पर काम करता/करती हूं. लोगों को confuse करने वाले docs और change logs शायद मैंने ही लिखे या edit किए हों
    • [ 0.000000] microcode: updated early: 0x27 -> 0x28, date = 2019-11-12
      Haswell इस्तेमाल कर रहा/रही हूं. क्या कोई list है कि किन CPU को updated microcode मिलता है? अफ़सोस
    • यह default न भी हो सकता है. सिर्फ़ text देखकर पूरी तरह clear नहीं है

  • यह भी ध्यान देने लायक है कि GCP ने इस issue को patch कर दिया है: https://cloud.google.com/support/bulletins#gcp-2023-024

    • London में Google Cloud(GCE) SRE करने वाली adjacent teams ने समय पर patches deploy किए, इसलिए आज उन्हें बिल्कुल deserved donuts मिले
    • corresponding AWS notice: https://aws.amazon.com/security/security-bulletins/AWS-2023-...
      AWS customers का data और instances इस issue से प्रभावित नहीं हैं, और customers को कोई action लेने की ज़रूरत नहीं है
      AWS ने इस श्रेणी की problems से protection वाली infrastructure design और implement की है. Lambda, Fargate और अन्य AWS managed compute/container services सहित Amazon EC2 instances, microcode और software-based mitigations के ज़रिए GDS से customer data की रक्षा करते हैं

  • performance hit बहुत बड़ा है. दावा है कि अधिकतम 50% तक, और कहा जाता है कि latest Intel processors के 70% प्रभावित हैं

    • “Red Hat के internal performance tests में worst-case microbenchmark में बड़ी slowdown दिखी. लेकिन vector gather का उपयोग करने वाली अधिक realistic applications में सिर्फ़ low single-digit percent slowdown दिखी.”
      https://access.redhat.com/solutions/7027704
      performance impact उन applications तक सीमित है जो Intel Advanced Vector Extensions(AVX2 और AVX-512) द्वारा दिए गए gather instruction और CLWB instruction का इस्तेमाल करती हैं. असली performance impact इस पर निर्भर करता है कि application उन instructions का कितना ज्यादा इस्तेमाल करती है
      अगर user ने thorough risk analysis के बाद mitigation बंद करने का फैसला किया है, उदाहरण के लिए system multi-tenant नहीं है और untrusted code नहीं चलाता, तो mitigation disable की जा सकती है
      microcode और kernel updates apply करने के बाद kernel command line में gather_data_samping=off जोड़ने से mitigation बंद की जा सकती है. या GDS सहित सभी CPU speculative execution mitigations बंद करने के लिए mitigations=off इस्तेमाल किया जा सकता है
    • क्या वह 50% overhead “Gather” instruction के लिए है? अगर ऐसा है, तो workload में 10% instructions gather हों तो total overhead 5% होगा
    • wording है “कुछ workloads को अधिकतम 50% overhead का सामना करना पड़ सकता है”. कुछ workloads कहा गया है, तो performance hit दुर्लभ लगती है
    • missing key context यह है कि “यह इस पर निर्भर करता है कि program के core execution path में Gather है या नहीं”
    • यह “up to 70% off” देखकर उसे बहुत बड़ी sale समझने जैसा है. कई बार पूरी दुकान में 70% discount वाली चीज़ें सिर्फ़ दो ही होती हैं
      “up to” वाले claims पर हमेशा शक करना चाहिए

  • NES में ऐसा chipset था जिसमें पूरा 6502 दबा हुआ था, और एक pizza की कीमत में आप die पर mixed cores वाला Rockchip ARM chip खरीद सकते हैं। Chip manufacturers को हर edge case हमेशा के लिए solve करने की ज़रूरत नहीं है; शायद इस तरह के side-channel attack mitigation को वापस हम पर छोड़ देना ठीक हो, जो chips इस्तेमाल करते हैं।
    SMT को पूरी तरह on या पूरी तरह off करने का विकल्प बनाने के बजाय, अविश्वसनीय code को “घटिया core” पर भेजें, और customer से “proof” करवाएँ कि उसे SMT वाले core पर promote किया जा सकता है—कैसा रहेगा?
    कोई भी उस chip को खराब नहीं करना चाहता जो बेहद critical payroll job चला रही है और जहाँ board पर कोई और चीज़ नहीं लगाई जा सकती। लेकिन जिन चीज़ों को SMT पर सुरक्षित रूप से चलाया जा सकता है उन्हें tag करने के लिए मजबूर होना, और वरना ज्यादा सुरक्षित core से बाँध दिया जाना—यह ठीक है।
    कोई intern जिसे इसका बिल्कुल अंदाज़ा नहीं है, search करते-करते सीख सकता है कि यह attack vector असल में क्या है, और defense plan बना सकता है।
    क्या मैं अजीब हूँ?

    • मुझे यह market की समस्या लगती है।
      performance cores × efficiency cores संभव हैं।
      लेकिन trust cores × “घटिया” untrusted cores propose करने वाला कोई नहीं बनना चाहेगा। फायदे चाहे जितने हों, यह “डर फैलाने” वाली narrative में दब जाएगा। ज़िंदगी ऐसी ही है।