Linux. Czołowy opiekun jądra ostro krytykuje procesory Intela
– Dążąc do rozwiązania problemów z bezpieczeństwem procesorów Intela, nie mam nic do ofiarowania prócz krwi, znoju, łez i potu. Tak mógłby zacząć swoją przemowę Greg Kroah-Hartman, jeden z opiekunów jądra Linux, rozpoczynając wykład na Open Source Summit Europe – zdaniem ZDNet.
To parafraza słów Winstona Churchilla, które ten wypowiedział w Izbie Gmin, gdy obejmował urząd premiera w maju 1940 roku i szykował się do wojny z Niemcami.
Znamienne, prawda? Kroah-Hartman obawia się, że problemy z bezpieczeństwem czipów Intela nie skończą się tak długo, jak producent drastycznie nie zmieni modelu wykonywania spekulatywnego. Jak powiedział, przewidywanie następnych rozkazów rzeczywiście jest bardzo szybkie, ale ujawnia po drodze większość danych. Już lokalnie to sporego kalibru problem, a co dopiero, gdy przełamana zostanie bariera między maszynami wirtualnymi w środowiskach chmury.
Wspólna geneza, wzajemne przenikanie
Deweloper zwraca uwagę na wspólną genezę. – Te problemy będą z nami bardzo długo, nie znikną. Bo wszystkie są błędami procesora. W pewnym sensie wszystkie są tym samym problemem – zauważył Kroah-Hartman. – MDS, RIDL, Fallout, Zombieload są wariantami tego samego podstawowego błędu [wykonywania spekulatywnego – przyp. red.] – wyjaśnił.
Padł przykład tego, jak luki RIDL i Zombieload mogą się przenikać, połączony jednocześnie z krytyką stosowanej powłoki izolacyinej: – Mogą kraść dane między aplikacjami, maszynami wirtualnymi, a nawet bezpiecznymi enklawami w pamięci. To ostatnie jest naprawdę zabawne, ponieważ Intel Software Guard Extensions ma właśnie przed tego rodzaju atakami chronić szczególnie, ale jest bardzo dziurawe i można to dokładnie zobaczyć.
System operacyjny nie ma tu nic do rzeczy
Kroah-Hartman słusznie twierdzi, że aby naprawić każdy pojawiający się u niebieskich problem bezpieczeństwa, należy załatać zarówno jądro Linux, jak i BIOS komputera oraz mikrokody. Przy czym nie jest to oczywiście problem z samym Linuksem, bo inne systemy mają ten sam.
Nieprzypadkowo za wyjaśnienia wziął się ten właśnie programista. To on jest autorem pomysłu na wyłączenie wielowątkowości współbieżnej (SMT), który został powszechnie przyjęty w środowisku Linuksa, pomimo oczywistych spadków wydajności. A te wynikają nie tylko z braku SMT, ale także konieczności opróżnienia buforów za każdym razem, gdy następuje zmiana kontekstu, a więc na przykład przy przejściu z jednej maszyny wirtualnej na drugą. Pochłania to kolejne cykle zegarowe, naświetlił sprawę Kroah-Hartman.
Spadek wydajności warunkują zastosowania
Ile się na tym traci? To zależy od zastosowania. Opiekun jądra Linux wyjawił, że w przypadku typowej pracy biurowej jest to około 2 proc., ale już kompilacja kernela jest mniej wydajna o 20 proc. Wszystko zależy od częstotliwości przełączania kontekstu i wpływu, jaki ma na dane zadanie SMT.
– Złą rzeczą jest to, że musisz teraz wybierać: wydajność lub bezpieczeństwo – podsumował dodając jeszcze, że "czasem wyboru dokonuje za nas dostawca usługi".
Tymczasem to wciąż nie wszystko. Odpowiednie łatki dla jądra i mikrokodów muszą przede wszystkim w ogóle zostać wydane. Według Kroaha-Hartmana, każdy system niegwarantujący długoterminowego i szybkiego wsparcia jest skrajnie niebezpieczny. Jak stwierdził, tylko największe dystrybucje, takie jak Debian, Red Hat, Suse czy Ubuntu, są w stanie sprostać pojawiającym się regularnie zagrożeniom. Reszta miesiącami pozostaje narażona na atak. I problem ten będzie ponoć towarzyszyć nam dopóki Intel nie zrewolucjonizuje całej koncepcji spekulatywnej.
