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.
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_v1oraznospectre_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ć.