AMD का रैंडम नंबर जेनरेटर 0 नहीं बना सकता?

मूल लेख ↗ Hacker News चर्चा ↗

AMD CPUs में एक bug दिखाई देता है जहाँ कुछ generations का hardware random number instruction (विशेषकर Zen 2 `rdrand16`) लगभग कभी true 0 नहीं बनाता, या zero outputs को failure के रूप में गलत तरीके से चिह्नित करता है, जिससे उन values में bias की चिंता उठती है जिन्हें uniformly random होना चाहिए। Commenters बताते हैं कि अधिकांश systems इन hardware numbers का सीधे उपयोग नहीं करते, बल्कि इन्हें stronger software RNGs के seeds के रूप में लेते हैं, और modern kernels multiple entropy sources mix करते हैं, इसलिए एक flawed source आम तौर पर catastrophic नहीं होना चाहिए—हालाँकि इतिहास दिखाता है कि छोटे RNG biases भी वास्तविक vulnerabilities बन सकते हैं। यह discussion आगे opaque, vendor-implemented RNGs पर भरोसे, kernels bad या malicious entropy sources से कैसे बचाव करते हैं, और user space में custom cryptographic RNGs लिखने के जोखिमों तक फैल जाती है.

AMD RNG बग की प्रकृति

  • रिपोर्टें Zen 1/2-युग के CPUs पर केंद्रित हैं, जहाँ RDRAND16 कभी 0 वापस न देने जैसा दिखता है, जबकि RDRAND32/64 ऐसा करते हैं।
  • नज़दीकी परीक्षण दिखाते हैं कि RDRAND16 आंतरिक रूप से 0 उत्पन्न कर सकता है, लेकिन जब ऐसा होता है, तो carry flag (CF) 0 पर सेट होता है, जो “failure / retry” संकेत देता है।
    • सामान्य wrappers फिर इन परिणामों को discard कर देते हैं और loop करते हैं, इसलिए user code को व्यावहारिक रूप से कभी 16-बिट zero नहीं दिखता।
  • CF=0 “failures” की दर 1/65536 से मेल खाती है और ऐसे सभी failures 0 वापस करते हैं, जो शुद्ध रूप से 0 की अनुपस्थिति की बजाय एक व्यवस्थित व्यवहार का संकेत देता है।
  • नए generations (Zen 3/4) में tests में यह issue नहीं दिखता; Zen 5 में एक संबंधित RDSEED erratum है, जहाँ CF=1 के साथ all-zero result समान workarounds को जन्म दे सकता है, जिससे “never zero” जैसा व्यवहार फिर से आ जाता है।

पिछली hardware RNG समस्याओं से संबंध

  • Zen 2 के पहले के microcode bugs के कारण RDRAND अपडेट होने तक हमेशा all 1s वापस करता था।
  • चिंता यह है कि microcode “fixes” ने एक error pattern (all 1s) के बदले दूसरा (कोई 0 नहीं) दे दिया हो सकता है।
  • कुछ system operators ने Linux kernel में CPU RNG पर भरोसा करना बंद कर दिया, क्योंकि AMD की इन तरह की glitches रही हैं।

Security impact और randomness quality

  • एक पक्ष: व्यावहारिक प्रभाव न्यूनतम है क्योंकि:
    • Hardware RNG आम तौर पर केवल CSPRNG, जैसे kernel pool, को seed करने के लिए उपयोग होता है।
    • 2^16 (या 2^32/2^64) में से 1 value खोने से key space मुश्किल से ही घटता है।
  • दूसरा पक्ष: कोई भी systematic bias एक red flag है:
    • Cryptographic इतिहास दिखाता है कि छोटे biases कुछ protocols में exploitable हो सकते हैं।
    • भले ही यह विशिष्ट bias संभवतः harmless हो, ऐसी flaws को नज़रअंदाज़ करना जोखिमपूर्ण माना जाता है।
  • Thread मूल बातें दोहराता है:
    • Desired output एक discrete uniform distribution है; “never 0” bias है।
    • Predictability का मतलब सिर्फ “हमेशा same value नहीं” नहीं, बल्कि “कोई value या predicate preferential नहीं है।”

Entropy mixing और hardware पर भरोसा

  • व्यापक सहमति: किसी एक opaque hardware RNG पर निर्भर न रहें; multiple sources को एक strong construction (CSPRNG, sponge, या XOF) के जरिए mix करें।
  • इस पर बहस कि:
    • क्या एक “bad” लेकिन non-malicious source कभी good pool को worse बना सकता है (अधिकांश का कहना है नहीं; अन्य ऐसे attacks का हवाला देते हैं जहाँ malicious source जो अन्य inputs देखता है, output को bias कर सकता है)।
    • क्या हमेशा kernel interfaces (/dev/urandom, getentropy/getrandom) का उपयोग करना बेहतर है या userland RNGs बनाना।
  • कुछ लोग custom RNGs के खिलाफ़ ज़ोर देते हैं (वास्तविक दुनिया की failures का इतिहास); अन्य mature, लंबे समय से tested custom XOF-based designs का बचाव करते हैं, खासकर cross-platform या embedded use के लिए।

Validation, testing, और यह कैसे छूट गया

  • कई commenters को आश्चर्य है कि इतना सरल distribution bug hardware validation से कैसे निकल गया; hypotheses में शामिल हैं:
    • अधूरी verification plans (0 के लिए कोई specific coverage bin नहीं)।
    • Off-by-one errors।
  • Practical note: सभी 65,536 16-bit outputs की histogramming एक आसान black-box test है, जो इस प्रकार की गलती पकड़ लेनी चाहिए थी।