Najbezpieczniejszy z systemów wyłącza wielowątkowość w procesorach Intela
Jeśli ktoś myśli, że mydlana opera o lukach tkwiących wsprzętowej architekturze Intela skończyła się wraz z wydaniemwszystkich możliwych łatek na systemy operacyjne i poprawionegomikrokodu procesorów, to jest w błędzie. Twórcy uważanego zaekstremalnie bezpieczny systemu OpenBSD właśnie zdecydowali sięwyłączyć w czipach Intela mechanizm wielowątkowości(Hyper-Threading), ze względu na ryzyko, jakie ma się z nim wiązać.
Na łamach listy dyskusyjnej deweloperów OpenBSD pojawiła sięinformacjao łatkach na kernel i sterownik procesora, które wyłączająwielowątkowość typu SMT – czyli jednoczesne uruchamianie dwóchwątków na jednym fizycznym rdzeniu. Odpowiedzialny za to opiekunsystemu Mark Kettenis wyjaśnia, że istniejące implementacje takiejwielowątkowości dzielą między sobą bufor TLB (tablicy fragmentówstron pamięci) oraz pamięć cache L1. Znacząco to ułatwia atakina cache procesora i zdaniem deweloperów OpenBSD otwiera drogę dogroźnych exploitów na miarę Spectre.
Najgorzej sytuacja wygląda z implementacją Intela, znaną jakoHyper-Threading, gdzie dochodzi do jednoczesnego uruchamiania różnychdomen bezpieczeństwa w różnych wątkach na tym samym rdzeniu.Zaradzenie temu na poziomie planisty kernela nie jest sprawątrywialną, więc uznano, że lepiej jest z Hyper-Threadingucałkowicie zrezygnować. Jako jednak że większość nowychkomputerów nie pozwala na wyłączenie Hyper-Threadingu z poziomuUEFI/BIOS-u, zdecydowano się zrobić to software’owo.
Domyślnie OpenBSD wyłącza wielowątkowość na procesorachIntela. Użytkownik może ponownie ją włączyć, przełączająckontrolkę hw.smt, ale nie jest to zalecane. Mark Kettenisprzypomina, że wcale nie należy się obawiać utraty wydajności: wwiększości obciążeń roboczych na procesorach mających więcejniż dwa rdzenie Hyper-Threading ma wręcz spowalniać komputer.
A co z procesorami AMD? No cóż, implementacja SMT w Ryzenach teżnajwyraźniej nie została uznana za bezpieczną. W planach jestwyłączenie wielowątkowości także w procesorach innych niż Intelproducentów, także na innych niż x86-64 architekturach.
Wyjaśnienia są jak widać dość lakoniczne, ale najwyraźniejprzeprowadzono w tej sprawie głębsze badania. Kilka dni temu PhilipGuenther, również z drużyny OpenBSD, wspomniało konieczności czyszczenia rejestrów ogólnego przeznaczenia (GPR)przy wejściu do kernela z przestrzeni użytkownika, aby podsunięteprzez użytkownika wartości nie mogły brać udziału wspekulatywnym wykonywaniu instrukcji, które zostaną odrzucone, alebędą miały widoczne efekty w cache. To samo zrobionow systemie DragonFly BSD, a w wiadomościwysłanej do szefa OpenBSD Theo de Raadta, na końcu znalazł siędopisek: wyłączcie Hyper-Threading Intela tam gdzie go nietrzeba, póki nie będziemy wiedzieli więcej.
O problemie wspominateż na łamach listy dyskusyjnej OSS-SEC niezależny haker LoganadenVelvindron, pisząc że do oficjalnego ujawnienia miałoby dojść 27czerwca. Jeśli faktycznie do tego dojdzie, wszystkie systemyoperacyjne musiałyby zmodyfikować działanie swoich planistów, byuniknąć przenikania się domen bezpieczeństwa w niebezpiecznysposób.
Nieciekawie to wygląda dla Intela – od niepamiętnych czasówfirma z Santa Clara dumna była z Hyper-Threadingu, zawsze wspecyfikacji procesorów wspominając o liczbie rdzeni i liczbiejednocześnie uruchamianych wątków (a więcej to przecież lepiej).Marketing i PR zdołały jakoś zneutralizować rynkowy efekt Spectrei Meltdowna, ale czy zdołają drugi raz zrobić wrażenie naklientach tą samą sztuczką?
