Nie instaluj misiu podejrzanych programów (do tego o x86 i Secure Boot)

Na samym początku platforma x86 nie miała żadnych zabezpieczeń, jeżeli chodzi o ochronę kodu przed zmianą przez inny kod. Procesory były wtedy bardzo proste i obsługiwały wyłącznie tzw. tryb rzeczywisty (real mode), co oznaczało, że każdy proces miał dostęp do całej przestrzeni adresowej i wszystkich zasobów sprzętowych.

Potem zdecydowano, że konieczna jest ochrona. Wprowadzono tryb chroniony (protected mode). Pierwsze sprzętowe implementacje były proste, i stąd np. w procesorze 80286 można było go włączyć, ale już powrót do trybu rzeczywistego (bodajże) we wszystkich wypadkach wymagał restartu systemu. W wielkim uproszczeniu dostaliśmy wtedy dwa poziomy uprawnień, i pojawiło się coś takiego jak tryb jądra (kod uruchomiony w tym trybie może zarządzać innymi procesami) i tryb użytkownika (procesy mogą działać tylko w obrębie otrzymanych uprawnień), jak również obsługa pamięci wirtualnej (część dysku może działać jak RAM).

Platforma się rozbudowywała. Oprócz trybu 16-bitowego pojawił się również tryb 32-bitowy, w którym można było obsłużyć aż do 4GB RAM. Ilość tranzystorów rosła, a stopień skomplikowania spowodował, że nawet Intel na początku miał z tym problemy (część pierwszych procesorów 80386 działała poprawnie tylko z kodem 16-bitowym). Doszła obsługa wieloprocesorowości, producenci dodawali też coraz więcej rdzeni w obrębie jednego układu scalonego (konieczne było rozwiązanie np. różnych problemów współbieżności).

Co jednak ważne przez lata, BIOS praktycznie wszędzie nie miał żadnej ochrony. Pojawiały się kolejne wirusy, które potrafiły go zmieniać albo kasować, a producenci nie implementowali nawet prostego microswitcha, który to blokował. Podobnie mieliśmy do czynienia z różnymi cyfrowymi mikrobami, które modyfikowały zawartość sektorów rozruchowych dysków czy dyskietek. Kilka firm stworzyło wtedy inicjatywę Secure Computing, w ramach której zaczęto przygotowywać mechanizmy, które miały m.in. temu przeciwdziałać. Powstały takie rozwiązania jak TPM (Trusted Platform Module) czy Secure Boot (kontrola tego, czy oprogramowanie startowe nie uległo zmianie). O pierwszym z nich zaczęło być głośno w kontekście Windows 11 (system w większości przypadków, jeśli nie zawsze, ma wymagać modułu TPM 2.0), a drugie jest o tyle ciekawe, że domyślnie to Microsoft decyduje, które oprogramowanie (tzn. z jakim podpisem cyfrowym) można wystartować.

Zatrzymajmy się w tym momencie. Współczesna platforma x86 to sprzęt, w którym dostępne jest co najmniej kilka rdzeni procesora (w następstwie błędów, o ile nich nie załatamy, wątki i procesy mogą podkradać dane innym), mamy też różne kanały szybkiej transmisji (teoretycznie bezpieczne, a czasami podatne na włamania – wystarczy wspomnieć problemy z Thunderbolt czy USB), interfejsy do debugowania, (zbyt) rozbudowane UEFI, opcje wirtualizacji czy (w przypadku systemów z Intelem) Intel ME, czyli nadrzędny procesor , który może robić co chce z „właściwą” częścią (i masy właściwie nie wiedzą co tam siedzi).

W tym tygodniu zostałem przywołany do tablicy i skarcony, że nie powinienem proponować instalowania oprogramowania z nieznanych źródeł. Zasada ogólnie dobra, ale… jak zawsze diabeł tkwi w szczegółach. Pomińmy w tym momencie oczywistą oczywistość, że nikt nie powinien się ślepo słuchać jakiegoś kolesia z Internetu.

Sprawa dotyczyła Ubuntu odpalonego na laptopie produkowanym przez Clevo. Pisałem o oprogramowaniu dostarczanym przez firmę Tuxedo Computers. Mają oni repozytoria z kodem źródłowym na GitHub i proponują również skompilowane wersje binarne. Ich domena tuxedocomputers.com jest ważna od 2008. Załóżmy teraz, że nie kupili jej od nikogo na targu, i używają jej od nowości.

Jak widać, mamy firmę, która sprzedaje laptopy, dodaje do nich własne oprogramowanie i jest na rynku od 13 czy 14 lat (zależy jak liczyć). Oprogramowanie powstało na podstawie oryginalnych aplikacji Clevo, które udostępniono pod Windows (zrobiono tzw. reverse engineering). Służy m.in. do kontroli prędkości wentylatorów. Teoretycznie powinienem oczywiście skorzystać do tego zadania z domyślnego interfejsu oferowanego pod Linuxem przez lm-sensors czy fancontrol, ale tego nie ma dla Clevo. Mógłbym zmienić odpowiednie opcje w BIOS/UEFI, ale tych nie ma w przypadku mojego laptopa.

Tak więc podsumowując – mamy firmę działającą od kilkunastu lat. Nie dostarczyła (jeszcze?) standardowego interfejsu, i w sumie biję się w piersi, że np. nie zacząłem od analizy każdej linijki ich kodu źródłowego. Jeżeli przejść na ten poziom bezpieczeństwa, to powinienem też sprawdzić i skompilować od zera każdy pakiet dostarczany przez Ubuntu (przypomnijmy sobie aferę, w której jeden z uniwersytetów podobno w celach badawczych celowo umieszczał błędny kod w jądrze Linuxa). Wskazane byłoby pewnie też usunięcie UEFI i wgranie do laptopa „wolnej” jego implementacji (powinna pasować od Lemura Pro, i potrzebowałbym tylko programatora). Wtedy miałbym jednakże jeszcze problem z Intel ME, mikrokodem procesora czy firmware dysku (nie wiadomo, co tam siedzi, prawda?)

Shall we begin?

No dobrze, uznajmy, że nie będziemy aż takimi „geekami”. Ważne jest tutaj jedno – w wielu dystrybucjach Linuxa mamy pełno opcji do kontrolowania sprzętu (prędkości CPU, działania układu chłodzenia czy dysku). Zgadzam się z autorem wymienionego komentarza, że mogłem napisać o cpupower (czy czymś innym, co daje dostęp do standardowych interfejsów), tylko po co, skoro Tudexo Control Center udostępnia również to?

Tak się składa, że kontrola sprzętem wymaga sporych uprawnień, a ja się uparłem, żeby włączyć również Secure Boot. Na wspomnianym laptopie (Hyperbook L14) bez żadnych problemów załadowałem domyślną bazę certyfikatów (jest w niej „błogosławieństwo” dla kodu od Ubuntu, a jakby nie było, to i tak mógłbym uczynić zaufanym odpowiedni plik), a potem po załadowaniu softu od Tuxedo wystarczyło z terminala wydać komendę

sudo update-secureboot-policy --enroll-key

zrestartować sprzęt, potwierdzić chęć ładowania „zmienionego” kodu i cieszyć się pełną funkcjonalnością (to samo np. trzeba robić, gdy instalujemy starowniki od NVidii).

Z jednej strony wygląda to może kiepsko (niektórym się może nie spodobać, że to my decydujemy o to, co jest dobre, a co złe), z drugiej strony każda kolejna warstwa zabezpieczeń cieszy i pewnie lepszy taki Linux z pakietami przeglądanymi przez tysiące programistów i „niezaufanym” otwartym kodem od Tuxedo niż Windows z czyimś antywirusem (który ma dostęp do wszystkiego) i masą binarnych aplikacji, w których tak naprawdę może siedzieć cokolwiek. Powiem więcej - w świecie Open Source zdarza się, że jakaś wersja „niestabilna” jest udostępniana nawet przez kilka czy kilkanaście lat, i właśnie taka wersja jest o wiele lepsza niż „przetestowany” zamknięty odpowiednik. Sama platforma x86 ma różne słabe punkty, i pingwin daje do tego chyba szersze możliwości ich eliminacji niż wspomniany system operacyjny dla mas (mój ulubiony przykład – po publikacji mikrokodu przez Intela możemy się nim cieszyć już tego samego dnia).

A tak swoją drogą to ciekawe, jak wielu (szczególnie nietechnicznych) użytkowników ślepo wierzy w to, że tylko rzeczy od dużych korporacji dają bezpieczeństwo. Zdarzały się w przeszłości sytuacje, gdy udostępniano fabrycznie malware albo ładowano go przez BIOS. Podobne szopki odstawiano szczególnie kiedyś z DRM.  Jeżeli mam być szczery, przy prawdziwym dbaniu o bezpieczeństwo pewnie nie możnaby brać pod uwagę x86, Windows, MacOS czy Linuxa, a należałoby się bardziej skierować np. w stronę Qubes OS, ale to już temat na zupełnie inną historię.

Czy tak czy inaczej, siłą komputerów ogólnego przeznaczenia jest możliwość korzystania z różnych programów (i każdy poniekąd sam powinien decydować, co jest „bezpieczne”, a co nie). Ja życzę rozsądku.