Na czym polega błąd w procesorach Intela, AMD i ARM? I czy faktycznie spowolni mój komputer?

Na czym jednak konkretnie znaleziony błąd polegał? Z czego wynika spowolnienie działania komputera i czy rzeczywiście będzie ono tak uciążliwe? Spróbujmy to wyjaśnić.

We współczesnych systemach operacyjnych powszechne jest rozwiązanie zapewniające bezpieczeństwo uruchamianego kodu, znane pod nazwą protection rings (ang. kręgi bezpieczeństwa). Polega ono na oddzieleniu w jak najściślejszy sposób kodu uruchamianego na różnych poziomach zabezpieczeń. Takie oddzielenie ma na celu uniemożliwienie uruchamiania kodu (np. przez złośliwe programy) na poziomie przywilejów wyższym niż przeznaczony. Jest to istotne dla bezpieczeństwa, dlatego posiada wsparcie na poziomie sprzętowym, czyli w procesorach. Do tego jeszcze wrócimy, bo ma związek właśnie z problemem, jaki mają procesory Intela, AMD i ARM.

Typowe poziomy przywilejów zaczynają się od wewnętrznego kręgu, poziomu zerowego. To poziom jądra systemu operacyjnego, działający z największymi uprawnieniami. Kolejne poziomy 1 oraz 2 to poziomy sterowników sprzętowych. Poziom trzeci to poziom aplikacji - tutaj działa kod, którego właścicielem jest użytkownik.

Poprawnie zaimplementowana separacja poziomów przywilejów powinna uniemożliwić nienadzorowane uruchamianie kodu z niższego poziomu. Oczywiście jest to konieczne: dla przykładu przeglądarka (aplikacja użytkownika działająca na poziomie 3) musi mieć dostęp do sieci (poziom 2 - sterowniki sprzętu). Jest to realizowane w kontrolowany i predefiniowany sposób, za pomocą specjalnych bramek, którymi zarządza system operacyjny.

I tutaj jest pies pogrzebany. Za każdym razem bowiem, gdy kod użytkownika (o najniższym poziomie przywilejów) musi poprosić system operacyjny o wykonanie operacji o wyższym poziomie przywilejów (transfer danych, operacje wejścia-wyjścia), następuje przełączenie z trybu użytkownika w tryb jądra. Po zakończeniu operacji jądra następuje przełączenie z powrotem w tryb użytkownika. Ta operacja jest wspierana przez współczesne procesory w taki sposób, aby maksymalnie ją usprawnić, wykonywana jest ona bowiem wielokrotnie w trakcie działania aplikacji. W tym celu część danych jądra pozostaje w pamięci procesora, jednak powinna pozostać niewidoczna w trybie użytkownika.

W dużym uproszczeniu można stwierdzić, że błąd jaki odkryto w procesorach polega na tym, że informacje te nie są do końca odseparowane od procesów działających w trybie użytkownika. Systemy operacyjne (Linux, Windows, ale również i macOS) zakładały, że będzie to załatwione przez warstwę sprzętową, nie były więc przygotowane na tę ewentualność.

Gdy problem wyszedł na jaw, twórcy systemów musieli znaleźć sposób i okazał się on pracochłonny. Po każdej operacji zmiany trybu pracy przepisują oni ręcznie tablice danych jądra, aby ukryć je przed wyższymi warstwami uruchomieniowymi. Nie jest to rozwiązanie idealne, ale działa. Niestety, kosztuje również czas - tym więcej, im aplikacja intensywniej używa operacji systemowych.

Odpowiednie łatki już są przygotowane i zostaną zaaplikowane w najbliższym czasie, bądź już zostały wdrożone (np. dla macOS znalazły się w wersji 10.13.2 wdrożonej w grudniu ubiegłego roku).

Gdy wczytamy się w dokumentację systemów operacyjnych, możemy zauważyć, że dane jądra są przechowywane w nieprzewidywalnych miejscach. Na tyle na ile to możliwe, twórcy systemów operacyjnych wdrożyli metodę umieszczania ich w losowych (lub pseudolosowych) adresach, aby utrudnić do nich dostęp na wypadek wpadki tego typu, jaki właśnie obserwujemy w ostatnich dniach. Na czym więc polega problem? Przecież niebezpieczeństwo powinno być zminimalizowane dzięki tej metodzie (zwanej Kernel Address Space Randomization).

Informacje o metodach wykorzystania tej luki nie były szeroko publikowane, ale serwis The Register zanalizował e-mail wysłany przez inżyniera AMD, z którego wynikało, że luka może być użyta dzięki funkcji procesorów Intela zwanej speculative execution. Na czym ona polega? W celu zwiększenia wydajności przełączania się między trybami pracy procesor stara się przewidzieć, jaki kod będzie uruchamiany jako następny po przełączeniu się trybów.

Prawdopodobnie na tym dokładnie polegał błąd w procesorach Intela. Podejrzewa się, że odpowiednio napisany program jest w stanie podstawić kod, który zostanie wywołany po przełączeniu się z powrotem w tryb użytkownika. Ten kod zostanie uruchomiony bez odpowiednich sprawdzeń i uzyska dostęp do danych jądra.

Podejrzenia te zostały potwierdzone. Użytkownik Twittera @brainsmoke zademonstrował dosłownie kilka godzin temu program, które uzyskuje w ten sposób dostęp do danych z trybu jądra:

W nocy inżynierowie z Google'a opublikowali stronę, na której podano dalsze szczegóły ataków (Meltdown - na ten podatne są procesory Intela; Spectre - na ten podatne są procesory Intela, AMD i ARM). Udowodniono również dostęp do pamięci hosta z wirtualnej maszyny, a poprzez to dostęp do innej wirtualnej maszyny. Jest to naruszenie jednej ze świętości wirtualizacji, czyli kompletnej izolacji maszyn.

Najprawdopodobniej niezauważalnie, o ile używasz swojego komputera do typowych zadań konsumenckich oraz gier. To dobra wiadomość. Tym bardziej, że użytkownicy macOS nie zauważyli znaczących spowolnień, mimo iż ich system już zawiera odpowiednią łatkę. Testy wykonane przez portal PCGamer wskazują, że na wydajność gier łatka nie wpływa wcale lub wpływa w sposób nieznaczący.

Skąd więc podawana w mediach wartość od 5 do 30 procent? Wynika ze sprawdzenia najgorszego możliwego scenariusza, w którym aplikacja często wymaga od systemu przełączania się między trybami. Niestety istnieją takie aplikacje. Dla przykładu, bazy danych i aplikacje uruchamiane na maszynach wirtualnych. Jeden z programistów pracujących nad serwerem PostgreSQL wyliczył, że spowolnienie operacji dla tej bazy to od 17 do 23 procent. Załatany błąd wpłynie najbardziej na dużych graczy na rynku chmur i Infrastucture as a Service, czyli Amazon, Azure, Google Cloud. To dość paradoksalna sytuacja, w której naprawienie błędu powoduje tak dużo kłopotów.

Czy jest więc czym się martwić? Najprawdopodobniej nie. Jeśli jednak pracujesz z bazami danych lub masz specyficzne, wymagające na przykład wielu operacji wejścia-wyjścia aplikacje, możesz spodziewać się wyraźnego spowolnienia tych operacji przez konieczność przepisywania danych jądra w pamięci za każdym razem.

AMD udostępniło wyniki swoich eksperymentów dotyczących błędu i informacji udostępnionych przez Google. Przy okazji potwierdzono że atak przeprowadzany jest za pomocą speculative execution, co już wcześniej było sygnalizowane również przez AMD. Najważniejszą informacją od AMD jest następujące podsumowanie:

Oznacza to, że procesory AMD są zupełnie niepodatne na atak typu Meltdown, który może umożliwić odczytanie danych jądra procesom użytkownika. W przypadku Spectre nie wykluczono zupełnie ryzyka, podano jednak, że jak dotąd nie udało się go zademonstrować, co może oznaczać, że nawet przy wiedzy na temat architektury procesora jest on ekstremalnie trudny do przeprowadzenia.