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

Najprawdopodobniej wszystkie systemy operacyjne będą musiałyprzebudować trochę architekturę swoich podsystemów zarządzaniapamięcią. Szczegóły wciąż pozostają tajemnicą. Microsoftoczywiście nic nie powiedział, jedynie po cichu wprowadził poważnezmiany 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 łatekdla Linuksa – z których co ciekawe usunięto komentarze, by nieułatwiać życia czarnym kapeluszom. Embargo na informację wciążobowiązuje.

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

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

Jeśli w jakiś sposób proces użytkownika uzyskałby wgląd wto, co dzieje się w kernelu, uzyskałby w ten sposób do wszelkiegorodzaju chronionych danych, na czele z hasłami czy kluczamiszyfrującymi. A jeśli wskutek jakiegoś błędu uzyskuje? 20grudnia LWN.net opublikował dla swoich abonentów artykułpoświęcony obecnemu stanowi prac nad izolacją tablicy stronpamięci kernela. Ta nowa technika utwardzenia systemu, znanawcześniej jako KAISER, a obecnie KPTI (Kernel Page-Table Isolation),jest wprowadzana do Linuksa 4.15 i zostanie przeniesiona do Linuksa4.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 wcałkowicie oddzielną przestrzeń adresową, tak że nie tylko jeston niewidoczny dla procesu, kernela w ogóle tam nie ma. Oznacza to,że system nieustannie musi się przełączać między dwomaizolowanymi przestrzeniami adresowymi na każde wywołanie systemowe,na każde przerwanie. A przecież takie przełączanie nie jest zadarmo, zmusza do nieustannego żonglowania zawartością buforów iprzeł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 pierwszychbenchmarków wynika, że może dojść do zmniejszenia wydajnościprocesora o nawet 30% – najgorzej będzie chyba w wypadku aplikacjiwykonujących wiele operacji dyskowych i sieciowych.

Najwyraźniej nie ma jednak innego wyjścia. Z ujawnionych dotądinformacji wynika, że sprzętowy błąd w procesorach Intela mógłbypozwolić na odczytanie pamięci pokonanie mechanizmu randomizacjiprzestrzeni adresowej kernela (KASLR). Używany jest on do tego, byrozmieścić komponenty kernela w losowo wybranych obszarach pamięciwirtualnej, ogromnie utrudniając exploity, w szczególności te,które obchodzą zakaz uruchamiania kodu konstruując w technice ROPz 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ą potrzebnemu gadżety i uruchomić kod z uprawnieniami kernela. Innymi słowykod działający w obszarze Ring-3 nagle zyska dostęp do samegordzenia systemu, działającego w Ring-0.

Czy użytkownicy procesorów AMD mogą czuć się bezpiecznie?Niepokój wzbudził wpisna Twitterze jednego z inżynierów pracujących nad zestawem łatekgrsecurity. Napisał on, że po zastosowaniu KPTI, wydajność nowegoprocesora 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 niepotrzebuje. Pod koniec grudnia Tom Lendacky z AMD wyjaśniłna liście dyskusyjnej deweloperów linuksowego kernela, żeprocesory AMD nie są podatne na ataki, przed którymi ma chronićizolacja tablicy stron pamięci kernela. Ich mikroarchitektura niepozwala na odniesienia pamięci, w tym spekulatywne odniesienia, dowyżej uprzywilejowanych danych działając w mniej uprzywyilejowanymtrybie. Dlatego na czipach AMD należy wyłączyć flagęX86_BUG_CPU_INSECURE.

Spekulatywne odniesienia? O co tu chodzi? No cóż, współczesnerdzenie procesorów, aby osiągnąć najwyższą wydajność, próbujązgadywać kod, który będzie uruchamiany w następnej kolejności. Ztego co pisze Lendacky, procesory Intela mogłyby właśnie w takispekulatywny sposób uruchamiać kod, bez właściwych testówbezpieczeństwa. Exploit mógłby więc polegać na rozpoczęciuinstrukcji, która byłaby normalnie zablokowana przez kernel iukoń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 zaniebezpieczny, podobnie jak w wypadku błędu Pentium F00F sprzed 20lat.

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

To jednak nie wszystko. Wygląda na to, że łatkiKAISER/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ą? Spodziewajmysię więc też spowolnienia smartfonów.