Czas przejść na AMD? Błąd w procesorach Intela spowolni komputery o 30%

Strona główna Aktualności
image

O autorze

Pod koniec 2017 roku w grupach dyskusyjnych poświęconych bezpieczeństwu mówiło się o jakimś poważnym błędzie w popularnych hiperwizorach, związanym z nieuprawnionym dostępem do pamięci. Wszystko wskazuje na to, że to nie jest żaden poważny błąd w hiperwizorach. Mamy do czynienia z jedną z najgorszych katastrof w historii IT, sprzętowym błędem w procesorach Intela, a możliwe że i innych. Spodziewajcie się, że już niebawem Wasze komputery będą pracowały znacznie wolniej – taka jest bowiem cena software’owej łatki, przygotowanej dla Linuksa i Windowsa.

Najprawdopodobniej wszystkie systemy operacyjne będą musiały przebudować trochę architekturę swoich podsystemów zarządzania pamięcią. Szczegóły wciąż pozostają tajemnicą. Microsoft oczywiście nic nie powiedział, jedynie po cichu wprowadził poważne zmiany w Windows 10 build 17035, które trafią zapewne w kolejny drugi wtorek miesiąca do wszystkich systemów Windows. Można jednak sporo się odwiedzieć z udostępnionych łatek dla Linuksa – z których co ciekawe usunięto komentarze, by nie ułatwiać życia czarnym kapeluszom. Embargo na informację wciąż obowiązuje.

Coś jednak wyciekło. Wygląda na to, że procesy działające w przestrzeni użytkownika, na dobrą sprawę może to być kod w JavaScripcie uruchamiany w przeglądarce, mogą w jakiś sposób odkryć układ i zawartość chronionych obszarów pamięci kernela. Następuje to zapewne w trakcie przełączania między kernelem a userlandem, gdy zachodzi potrzeba przeprowadzenia jakichś systemowych operacji, np. dostępu do gniazdka sieciowego czy zapisania czegoś na dysku. I nie ma znaczenia, czy chodzi tu o Linuksa, czy o Windows, FreeBSD, macOS-a czy jakikolwiek inny system. Problem tkwić ma w samej mikroarchitekturze procesorów x86 Intela.

Niewidzialna obecność kernela

Jako że współczesne aplikacje nieustannie robią coś „systemowego”, to przełączanie się takie zostało w daleki sposób zoptymalizowane: kernel jest nieustannie obecny w przestrzeni adresowej wirtualnej pamięci procesów użytkownika. Program robi wywołanie przez API kernela, procesor przełącza się wówczas w tryb kernela, kernel robi swoje, procesor przełącza się w tryb użytkownika i wraca do procesu. Oczywiście zawartość pamięci kernela pozostaje dla programów użytkownika niewidoczna.

Jeśli w jakiś sposób proces użytkownika uzyskałby wgląd w to, co dzieje się w kernelu, uzyskałby w ten sposób do wszelkiego rodzaju chronionych danych, na czele z hasłami czy kluczami szyfrującymi. A jeśli wskutek jakiegoś błędu uzyskuje? 20 grudnia LWN.net opublikował dla swoich abonentów artykuł poświęcony obecnemu stanowi prac nad izolacją tablicy stron pamięci kernela. Ta nowa technika utwardzenia systemu, znana wcześniej jako KAISER, a obecnie KPTI (Kernel Page-Table Isolation), jest wprowadzana do Linuksa 4.15 i zostanie przeniesiona do Linuksa 4.14.1. Linuksowi hakerzy mają jednak na nią znacznie brzydszą nazwę: Forcefully Unmap Complete Kernel With Interrupt Trampolines (FUCKWIT).

Nic dziwnego, że tak brzydko. KPTI/FUCKWIT przenosi kernel w całkowicie oddzielną przestrzeń adresową, tak że nie tylko jest on niewidoczny dla procesu, kernela w ogóle tam nie ma. Oznacza to, że system nieustannie musi się przełączać między dwoma izolowanymi przestrzeniami adresowymi na każde wywołanie systemowe, na każde przerwanie. A przecież takie przełączanie nie jest za darmo, zmusza do nieustannego żonglowania zawartością buforów i przeładowywania danych z pamięci. Efekt – narzut kernela na pracę systemu znacząco wzrasta, spowalniając komputer.

Cena za zastosowanie KPTI jest jednak okropna. Z pierwszych benchmarków wynika, że może dojść do zmniejszenia wydajności procesora o nawet 30% – najgorzej będzie chyba w wypadku aplikacji wykonujących wiele operacji dyskowych i sieciowych.

Najwyraźniej nie ma jednak innego wyjścia. Z ujawnionych dotąd informacji wynika, że sprzętowy błąd w procesorach Intela mógłby pozwolić na odczytanie pamięci pokonanie mechanizmu randomizacji przestrzeni adresowej kernela (KASLR). Używany jest on do tego, by rozmieścić komponenty kernela w losowo wybranych obszarach pamięci wirtualnej, ogromnie utrudniając exploity, w szczególności te, które obchodzą zakaz uruchamiania kodu konstruując w technice ROP z obecnych w pamięci gadżetów swój własny kod. Możliwość obejścia KASLR oznacza, że ataki ROP staną się daleko łatwiejsze – malware będzie mogło po prostu odczytać, gdzie są potrzebne mu gadżety i uruchomić kod z uprawnieniami kernela. Innymi słowy kod działający w obszarze Ring-3 nagle zyska dostęp do samego rdzenia systemu, działającego w Ring-0.

Intel nawalił, a co z AMD?

Czy użytkownicy procesorów AMD mogą czuć się bezpiecznie? Niepokój wzbudził wpis na Twitterze jednego z inżynierów pracujących nad zestawem łatek grsecurity. Napisał on, że po zastosowaniu KPTI, wydajność nowego procesora AMD EPYC 7601 podczas benchmarku du -s spadła o 49%. Jeszcze gorzej niż z Intelem?

Najwyraźniej tak, tyle że AMD tych łatek w ogóle nie potrzebuje. Pod koniec grudnia Tom Lendacky z AMD wyjaśnił na liście dyskusyjnej deweloperów linuksowego kernela, że procesory AMD nie są podatne na ataki, przed którymi ma chronić izolacja tablicy stron pamięci kernela. Ich mikroarchitektura nie pozwala na odniesienia pamięci, w tym spekulatywne odniesienia, do wyżej uprzywilejowanych danych działając w mniej uprzywyilejowanym trybie. Dlatego na czipach AMD należy wyłączyć flagę X86_BUG_CPU_INSECURE.

Spekulatywne odniesienia? O co tu chodzi? No cóż, współczesne rdzenie procesorów, aby osiągnąć najwyższą wydajność, próbują zgadywać kod, który będzie uruchamiany w następnej kolejności. Z tego co pisze Lendacky, procesory Intela mogłyby właśnie w taki spekulatywny sposób uruchamiać kod, bez właściwych testów bezpieczeństwa. Exploit mógłby więc polegać na rozpoczęciu instrukcji, która byłaby normalnie zablokowana przez kernel i ukończeniu jej zanim zostanie przeprowadzone sprawdzenie uprawnień. Zapraszamy do interesującego artykułu w tym temacie autorstwa Andersa Fogha.

Wygląda więc na to, że procesory AMD nie zostaną spowolnione. Łatka jest aktywowana tylko wtedy, gdy procesor zostaje uznany za niebezpieczny, podobnie jak w wypadku błędu Pentium F00F sprzed 20 lat.

Kto ucierpi?

Już dzisiaj widać, że sprzętowy błąd będzie miał ogromne konsekwencje – i to nie tylko na naszych pecetach. Dostawcy chmur takich jak Amazon EC2, Microsoft Azure czy Google Compute Engine rozsyłają powiadomienia o rychłych przerwach w pracy, związanych z koniecznością aktualizacji. W najgorszym razie oznacza to, że software’owa poprawka znacząco spowolni obciążenia robocze. Czy klienci dostaną zwrot pieniędzy?

To jednak nie wszystko. Wygląda na to, że łatki KAISER/KPTI/FUCKWIT trafić mają do kompilacji Linuksa na 64-bitowe procesory ARM, wykorzystywane przecież we wszystkich współczesnych smartfonach. Czyżby i tam było coś nie tak z mikroarchitekturą? Spodziewajmy się więc też spowolnienia smartfonów.

© dobreprogramy

Komentarze