Amikor a Windows kernel processzor cache-t korrumpáló gamma sugarakkal vette fel a harcot

 ( trey | 2018. november 26., hétfő - 12:07 )

Egy érdekes történelmi visszatekintő blogbejegyzést tett közzé a veterán Microsoft kóder, Raymond Chen nemrég arról, hogy az egyik meg nem nevezett processzorgyártó kérésére milyen kódot tettek a Windows kernel forrásába (amit aztán rövid időn belül ki is kommenteztek) annak érdekében, hogy kiküszöböljék a processzor gyorsítótárakban levő adatokat korrupttá tevő gamma sugarak kártékony hatásait. A kód ugyan ki van kommentezve, de a mai napig ott van a kernelben.

Részletek a blogbejegyzésben.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Védett atomtámadástól?

Páran írják a kommentekben, hogy az ISS-en és a magasabb helyen lévő telepeken (pl. Los Alamos) szeretnek radiation hardened (sugárzástűrő) komponenseket használni, ott teljesen érthető a kérés. Ennek ellenére nekem derült ki, pontosan miért kellett ez a kód.

Ennek ellenére nekem derült ki, pontosan miért kellett ez a kód.

pontosabban miért most. sunyi propaganda. a kommentben meg nem nevezett gyártó éppen tesztelte az egyik radhard csipjét. A press kitben van még hozzá mosolygós arc is, aki feltartja az árut. És lám, lett hír, meg fél tucat hozzászólás itt is.

ui: nem, ez nem fog megédeni, ahogyan a bugos első stepping level-ektől sem.

ja attól a kicommentelt változat nem, de bármikor vissza lehet kommenezni, amikor atomtámadás van.

Biztonság kritikus rendszerekben számolnak azzal hogy mi van ha egy részecske eltalálja a chipet. Minél kisebb a csíkszélesség annál valószínübb hogy gondot okoz. A cache elég nagy területét teszi ki egy proceszornak ezért célezerû azt védeni. Nálunk a legtöbb memória a chipen ECCvel védett.

+1

Valos gond és nagy számú szerver esetén néha 1-1 bit ugrik a memóriában tényleg és nem tudni mitől vagyis hasonló okból kifolyólag is lehet.

Persze mit számít az bármilyen Windows kiadásnak. Kap egy rebootot és megy tovább megint sokáig.

Ha jól értem a konkrét esetben az volt a gond, hogy az L1 cache csak paritással védett, nem ECC-s (latency miatt nem mindegy). Másrészt valami powersave módba küldés környékére került volna az említett utasíŧás.

Innentől spekuláció részemről:
- a cache SRAM, tehát elvileg nem kell "frissíteni", nem számít neki mennyi ideig nem néznek felé - nem ez lehetett a probléma
- a paritás miatt csak detektálni lehet a hibát, javítani nem, tehát az esetleges scrubbing leállása sem ront a helyzeten
- viszont powersave módban nem ritka, hogy lejjebb veszik a magfeszültséget - szerintem ez lehetett a baj, alacsonyabb feszültségen az SRAM cellák minden bizonnyal hajlamosabbak voltak "spontán" átbillenni, ezért érdemes volt legalább a dirty L1 cache line-okat memóriába visszaírni, a többinél meg reménykedni, hogy a paritás jelzi a hibát és memóriából újraolvassal javítható
---
Régóta vágyok én, az androidok mezonkincsére már!

Volt olyan projektem, ahol a HW sok időt töltött el nagy tengerszint feletti magasságban, és ott (spórolás/súlycsökkentés miatt hiányzó HW-es védelem miatt) az nvram bitjei tudtak ilyen okból (háttérsugárzás) átbillenni. SW-ből ECC-ztük a flasht.

:wq

Egyszerűbb szavakkal: a meg nem nevezett chipgyártó egyik termékében volt egy apró hiba, amit ez az INVD elfedett. Később ez a CPU kijavult/ patchelődött/ piaci részesedése jelentéktelenné vált.
https://blogs.msdn.microsoft.com/oldnewthing/20181120-00/?p=100275
Különös tekintettel a végén a Bonus chatter-re.

Volt egyszer egy sorozat UltraSPARC CPU, amiben a külső L3 cache chipjéhez használt szilícium alapanyaga kis mértékben szennyezett volt valami enyhén radioaktív cuccal. Ez persze már csak a gyártás és a használatba vétel után derült ki - míg egyébként egy sok-cpu-s combosabb szerverben úgy évente van 1-2 bit, amit az ECC-nek ki kell javítania, ezekben a gépekben kb. órás sűrűséggel jöttek elő ezek (valaki észrevette a messages fájlban, és bejelentette hibának, hogy azért ez mégsem szokványos - így derült ki végül). Hogy ezek ne adódjanak össze (amit ugye az ECC már nem tudna javítani), implementáltak egy szoftveres L3 cache scrubbing funkciót az egyik kernel patchben :)