Głupota uszczęśliwia, czyli mam gdzieś Spectre, Meltdown i MDS

Bezpieczeństwo naszych danych jest ważne. Tak samo jak istotne jest utrzymanie w przyzwoitym zabezpieczeniu informacji personalnych, haseł i numerów kont. Żyjemy w czasach kiedy roztropnie jest umieć posługiwać się całą tą elektroniką, systemami, stronami bankowymi, itp. A tu zasady są proste – bądź pewien, że wiesz gdzie i co robisz. Dlatego jeżeli nie jesteś Czytelniku pewien swoich umiejętności, pomiń poniższe dywagacje oburzonym prychnięciem. Bowiem za chwile rozbroimy Linuksa z wszystkich ostatnio nałożonych nań zabezpieczeń chroniących komputer przed podatnościami Spectre, Meltdown czy MDS.

Zaraz, zaraz, czy ja właśnie napisałem, że deaktywujemy zabezpieczenia? Oto krótkie wprowadzenie do tej pokrętnej koncepcji.

Wraz z wykrywaniem nowych podatności „sprzętowych” i głównie w procesorach Intela, z nadzieją oczekiwaliśmy szybkiej reakcji i naprawienia problemu. I doczekaliśmy się, łatki pojawiły się bardzo szybko, deweloperzy uzupełnili programowe uchybienia w logice konstruktorów procesorów. A my zauważyliśmy, że poprawka za poprawką i nasz Linux działa coraz wolniej. Apogeum bezpieczeństwa za wszelką cenę pojawiło się wraz z podatnością MDS i zaleceniem, by wyłączyć w procesorach Hyper-Threading. Niektórzy z nas wiedzą, czym to pachnie. Pozostali z dnia na dzień będą musieli przyzwyczaić się do swojego nowego grymasu twarzy „czego to wszystko trwa jak dojrzewanie najprzedniejszej whisky…”.

Bezpieczeństwo versus wydajność. O ile w przypadku konkretnych programów lub nawet systemów jest to konieczność, o tyle wyrywanie problemu z korzeniami i kastrowanie procesora jest… Trudne do zaakceptowania. Oczywiście o ile nie wykonujemy kontraktów dla strategicznych gałęzi biznesu lub wręcz rządu. Wtedy wyboru raczej nie mamy.

W każdym innym przypadku garść poniższych parametrów kernela może być wybawieniem z odmętów dylematu „jak nie ten system, to może inny będzie szybszy”. Otóż deweloperzy Linuksa pozostawili nam furtkę, której należy jednak używać z rozwagą. Wspomniane parametry uczynią nas bezbronnymi w obliczu tytułowych podatności. Ale gry będą działały szybciej. Według przeróżnych obliczeń, na naprawę uchybień konstruktorów procesorów nasz system musi poświęcić około 15% do 30% swojej nominalnej wydajności.

Zestaw parametrów nie jest adekwatny dla wszystkich kerneli i procesorów. Lecz nie musimy się o to martwić. Jeżeli nasz kernel nie obsługuje danego przełącznika, to po prostu go pominie. Ale do rzeczy.

noibrs noibpb nopti nospectre_v2 nospectre_v1 l1tf=off nospec_store_bypass_disable no_stf_barrier mds=off mitigations=off

Brzmi enigmatycznie? Poczekajcie na próbę opisania tych parametrów w naszym narzeczu.

• noibrs – nie chcemy spekulacji nad kierunkiem rozważań (przewidywanie następnych rozkazów procesora),
• noibpb – nie potrzebujemy również granic w przewidywaniu barier tych rozważań,
• nospectre_v1 oraz nospectre_v2 – To nic, że niektóre programy mogą odczytać dane z innych programów, nawet jeśli nie powinny,
• l1tf=off – nie opróżniajmy pamięci podręcznej L1, nawet jeśli ktoś może ją przejąć,
• nospec_store_bypass_disable – używamy zapisanych wartości,
• no_stf_barrier – żadnych barier pomiędzy oprogramowaniem,
• mds=off – zombie load to nic strasznego,
• mitigations=off – żadnych sytuacji wyjątkowych (powyższych – działa dopiero w kernelu 5.xx).

Pomogło? Wątpię. Jednak według dokumentacji kernela to właśnie te parametry odłączają skrupulatne nadrabianie zaległości procesora. Są one zaprzeczeniem tego, o co walczymy codziennie. Ale niestety, jeżeli potrzebujemy więcej mocy musimy zaprzedać duszę wiadomo komu.

Wspomniane opcje należy dodać do linii kernel w menu startowym. Jeżeli nie wiesz, gdzie to dopisać – powyższe dywagacje nie są dla Ciebie, niestety. Ale po doklejeniu ich do /etc/default/grub w odpowiednim miejscu, należy teraz wygenerować jego (gruba) konfigurację ponownie. Gotowe.

Pytaniem otwartym pozostanie, czy było warto i kiedy zaczniemy tego żałować.