Co to jest błąd DRAM Rowhammer i jak go leczyć?


20

Układy DRAM są bardzo ciasno upakowane. Badania wykazały, że sąsiednie bity można losowo przerzucać.

  • Jakie jest prawdopodobieństwo losowego uruchomienia błędu w chipie DRAM klasy serwerowej z ECC ( artykuł CMU-Intel podaje np. Liczbę 9,4x10 ^ -14 dla nieznanego układu z powodu jednej awarii w ciągu roku)?
  • Skąd mam wiedzieć, czy błąd został naprawiony przed zakupem pamięci?
  • Co powinienem zrobić, aby przeciwdziałać złośliwym próbom eskalacji uprawnień przez np. Najemców lub nieuprzywilejowanych użytkowników np. CentOS 7?

Bibliografia:


2
Biorąc pod uwagę, że szczegóły exploita nie są nadal objęte embargiem, nie jestem pewien, czy będzie wiele dostępnych informacji oprócz tego, co już dał ci Google.
fukawi2

Zrozumiałem, że częstotliwość odświeżania pamięci radykalnie obniża szanse udanego przerzucenia bitów, a nowsze wersje BIOS-u obniżyły częstotliwość odświeżania, aby zmniejszyć ryzyko. Czy aktualizacja BIOS-u może być dobrym pierwszym krokiem?
Reaces

1
@ fukawi2, jakie szczegóły exploita były / są objęte embargiem? Pełny kod dla exploitów typu proof-of-concept został wydany wraz z postem na blogu.
Mark Seaborn

@ MarkSeaborn Nawet teraz nie pamiętam, to było 3 miesiące temu i ledwo pamiętam śniadanie.
fukawi2

Odpowiedzi:


19

Cytowany artykuł CMU-Intel pokazuje (na stronie 5), że poziom błędu zależy w dużej mierze od numeru części / daty produkcji modułu DRAM i zmienia się 10-krotnie. Istnieją również pewne oznaki, że problem jest znacznie mniej wyraźny w ostatnio produkowanych układach scalonych (2014).

Przytoczona liczba „9,4x10 ^ -14” została użyta w kontekście proponowanego teoretycznego mechanizmu łagodzenia o nazwie „PARA” (który może być podobny do istniejącego mechanizmu łagodzenia pTRR (pseudo Odśwież wiersz docelowy)) i nie ma znaczenia dla twojego pytanie, ponieważ PARA nie ma nic wspólnego z ECC.

Drugi artykuł CMU-Intel (strona 10) wspomina o wpływie różnych algorytmów ECC na redukcję błędów (współczynnik 10 ^ 2 do 10 ^ 5, być może znacznie więcej przy wyrafinowanych testach pamięci i „zabezpieczaniu”).

ECC skutecznie zamienia exploit Row Hammer w atak DOS. Błędy 1bit zostaną skorygowane przez ECC, a gdy tylko zostanie wykryty niemożliwy do skorygowania błąd 2bit, system zatrzyma się (zakładając SECDED ECC).

Rozwiązaniem jest zakup sprzętu obsługującego pTRR lub TRR. Zobacz aktualny wpis na blogu Cisco o Row Hammer . Przynajmniej niektórzy producenci wydają się mieć jeden z tych mechanizmów ograniczających ryzyko wbudowanych w swoje moduły DRAM, ale trzymają go głęboko ukryty w swoich specyfikacjach. Aby odpowiedzieć na twoje pytanie: zapytaj sprzedawcę.

Szybsze odświeżanie (32 ms zamiast 64 ms) i agresywne interwały Patrol Scrub również pomagają, ale miałyby wpływ na wydajność. Ale nie znam żadnego sprzętu serwerowego, który faktycznie umożliwia precyzyjne dostrojenie tych parametrów.

Wydaje mi się, że niewiele można zrobić po stronie systemu operacyjnego, oprócz kończenia podejrzanych procesów przy stałym wysokim zużyciu procesora i dużym braku pamięci podręcznej.


4

Sytuacja nadal wydaje się dość niejasna, więc nie sądzę, aby można było na nie bezpośrednio odpowiedzieć na twoje pytania, ale oto niektóre stosunkowo nowe informacje jako częściową odpowiedź. Aby uzyskać wiadomości, postępuj zgodnie z listą dyskusyjną rowhammer-dyskusji .

Nie jestem pewien, czy obecnie dzięki informacjom publicznym można uniknąć zakupu wrażliwej pamięci RAM ani łatwo przewidzieć wskaźniki awarii w istniejącym sprzęcie. Producenci nie byli otwarci na informacje na temat wpływu ich produktów. Możliwe jest przetestowanie pamięci już zakupionej za pomocą narzędzi programowych, ale należy pamiętać, że uruchamianie tych narzędzi przez znaczne okresy (godziny) może trwale obniżyć pamięć RAM i spowodować błędy w działaniu oprogramowania.

„Nienazwane firmy pamięci” podobno próbowały zapłacić łapówkę w zamian za to, że Passmark Software nie wypuściło testu młota w swoim narzędziu Memtest86.

Zgłoszono, że sprzęt Intel Skylake jest bardziej wrażliwy na młotek z powodu dodania nowej clflushoptinstrukcji. Zostało to już wykorzystane w rowhammer.js

Daniel Gruss odpowiada tutaj na niektóre pytania dotyczące łagodzenia z grudnia 2015 r. (Współautor artykułu rowhammer.js ) w tym przemówieniu :

  1. Podczas gdy niektóre pamięci RAM ECC są mniej podatne na młot wierszy niż pamięć RAM innej pamięci niż ECC, inne pamięci RAM ECC są bardziej wrażliwe niż pamięci RAM inne niż ECC ( link do pytania w filmie )
  2. Przełączenie na wyższą częstotliwość odświeżania jest wystarczające, aby zapobiec młotowi wiercącemu z większością, ale nie ze wszystkimi sprzętami - ale nie wszystkie BIOSy pozwalają na zmianę częstotliwości odświeżania ( link do pytania w filmie ).

W ramach przeciwdziałania może być możliwe wykrycie trwających ataków młotem, ale nie wiem, czy zostało to zrobione.

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.