przystajnik

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=offzombie 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ć.

Post navigation

4 comments for “Głupota uszczęśliwia, czyli mam gdzieś Spectre, Meltdown i MDS

  1. 26 Maj, 2019 at 0:51

    — Jak przetestować wydajność „przed” i „po”? jakich narzędzi użyć?
    — Czy mogę to wrzucić do modprobe.d czy *musi* być w bootloaderze (systemd-boot w moim przypadku)?

  2. 26 Maj, 2019 at 5:53

    Kernel musi być uruchomiony z powyższymi parametrami, zatem ewidentnie należy to dodać do bootloadera.

    Jak sprawdzić wydajność? W zależności od procesora, kernela, itp. zmiany będą widoczne „na oko” w zachowaniu się pulpitu (render okien, reakcja na klikanie, itp.), a w niektórych wypadkach dopiero laboratoryjne testy pozwolą zobaczyć różnicę (np. stress-ng).

  3. Majster Klepa
    26 Maj, 2019 at 7:56

    „Otóż deweloperzy Linuksa pozostali nam furtkę”
    pozostawili^

  4. 29 Maj, 2019 at 22:01

    no właśnie miałem napisać to samo pytanie czy jest o co walczyć

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Translate »