Pe scurt - memoriile DDR3 au un mic bug în care un proces citind în mod repetat (hammering) din aceiași locație (memory row), poate modifica valorile din celulele alăturate de memorie.
Multe citiri repetate cu cache-ul disablat vor descărca tare condensatorii din DRAM - și pe cei citiți, dar și pe cei din row-urile alăturate. Valorile sunt “refăcute” la CAS refresh, dar numai pe randul de pe care s-a făcut citirea, nu și de pe cele alăturate. La RAM Low-Power și dacă refresh-ul la RAM este făcut încet (portabil pe baterie care vrea să consume puțin), informația din celulele alăturate se modifică.
Bug-ul se repară prin aruncarea la gunoi și folosirea unui computer cu memorie ECC cu refresh rapid sau a unui computer mai vechi cu RAM DDR2 sau mai încet.
Cine încearca testul pe un MacBook cu DDR3 in timp ce stă pe baterie ? Pe Mini-ul meu Late 2012 (cu DDR3 Crucial CT2C8G3S160BM), după 1000+ iterații nu am reușit să reproduc.
Codul sursă la rowhammer-test https://github.com/google/rowhammer-test
(trebuie să aveți XCode instalat ca să-l puteți compila - de aia am pus thread-ul ăsta la Programare)
Cu memorii Crucial, hai și Kingston, pe un Mac, care trec un Memtest burn-in de măcar 24 de ore, presupun că sunt extrem de scăzute șansele să zboare bitu’ (la urma urmei Memtest tot cam asta face, dar mai distribuit).
Ar trebui încercat cu memorii de calitate slabă, pe un mobo Biostar, cu frecvența CAS tunată un pic. Gen.
Când intrăm în zona asta de fizică descoperim ce înseamnă calitatea din spatele diverselor branduri.
Aici se vede de exemplu diferența între transceiverul unei plăci de rețea D-link și una Intel sau 3Com, ultimele funcționând binișor peste limitele din standarde.
Sau acele teste de scriere continuă pe SSD-urile Samsung în care începeau să pice după un PetaByte scris, de vreo zece ori mai mult decât garanția oficială.
Iteration 98 (after 230.75s) 49.397 nanosec per iteration: 2.13395 sec for 43200000 iterations check (check took 0.230972s) Iteration 99 (after 233.12s) 49.384 nanosec per iteration: 2.1334 sec for 43200000 iterations check error at 0x11db41198: got 0xfffffffffffeffff (check took 0.240620s) ** exited with status 256 (0x100)
Model Mac: Mac mini “Core 2 Duo” 2.53 (Late 2009)
Producator RAM 3rd party: Kingston
Model RAM 3rd party: KVR1066D3S7/4G ValueRam 1 x 4GB 204-PIN SO-DIMM MODULE
Capacitate MB modul RAM 3rd party: 4096
Tip/Viteza RAM 3rd party: PC3-8500 DDR3 CL7 SDRAM/1066 Mhz
Testul de rowhammer a fost introdus doar în ultima versiunea 6.0 Memtest și este mai “cuminte” decât cel din link-ul dat de mine - testele normale memtest sunt secvențiale.
Atenție - Kingston nu sunt producători, ci doar re-packageri. Nu au fabrica lor ci cumpără chip-urile de la alții. Așa că dacă un model de Kingston e ok, altul s-ar putea să nu fie.
Hmm, acu văd că e la noroc, am lansat din nou testul pe același Mini, e la iterația 900 and counting. În orice caz se adeverește ce ziceau autorii, faptul că nu obții eroarea pe o mașină nu înseamnă neapărat că nu e vulnerabilă.
În paralel îl rulez sub Ubuntu butat de pe stick pe un laptop HP EliteBook , Core i5 gen3, un so-dimm AData de 4GB PC3L-12800S, e la iterația 1810 and counting.
Am uitat să precizez că rulez double_sided_rowhammer_test.
Iteration 1160 (after 2768.68s) 49.126 nanosec per iteration: 2.12223 sec for 43200000 iterations check (check took 0.228615s) Iteration 1161 (after 2771.03s) 44.923 nanosec per iteration: 1.94066 sec for 43200000 iterations check error at 0x1130164a0: got 0xffefffffffffffff (check took 0.224148s) ** exited with status 256 (0x100)
Știi cum căutam eu așa în subconștient motive să strâng bani de MacPro ?
În paralel îl rulez sub Ubuntu butat de pe stick pe un laptop HP EliteBook , Core i5 gen3, un so-dimm AData de 4GB PC3L-12800S, e la iterația 1810 and counting.
A doua zi dimineață, iterația 41620 and counting. L-am oprit.
Carevasăzică, memorii AData, selecționate HP.
Eu nu mă mai joc. Crapă și pe Mini 2011.
Tot Kingstoane, KVR1333D3S9/8G.
Iteration 287 (after 324.30s) 22.983 nanosec per iteration: 0.992881 sec for 43200000 iterations check (check took 0.121592s) Iteration 288 (after 325.42s) 21.984 nanosec per iteration: 0.949717 sec for 43200000 iterations check error at 0x111696098: got 0xffff7fffffffffff (check took 0.121377s) ** exited with status 256 (0x100)
Evident, l-am lansat a doua oară. Mini 2011, tot double_sided_rowhammer.
De data asta a crăpat mult mai târziu, după aproape 8000 de iterații:
Iteration 7897 (after 8977.75s) 23.387 nanosec per iteration: 1.01034 sec for 43200000 iterations check (check took 0.119446s) Iteration 7898 (after 8978.88s) 21.546 nanosec per iteration: 0.930783 sec for 43200000 iterations check error at 0x11e00cfb0: got 0x7fffffffffffffff (check took 0.119289s) ** exited with status 256 (0x100)
Concluzie, o mie - două de iterații nu spun nimic. Dacă după ceva gen 50.000 de iterații nu a crăpat ( aproximativ 12 ore, o noapte ) atunci putem spune că sistemul trece cu steagul sus.
