Linux i bezpieczny rozruch. Błąd, którego nie możemy powtórzyć

W Poprzedni artykuł Przypomniałem sobie precedens wymagający przez firmę Microsoft wymagania modułu TPM w wersji 2, aby móc korzystać z systemu Windows 11. Mam na myśli wymóg, aby komputery z preinstalowanym systemem Windows 8 korzystały z UEFI zamiast BIOS-u do programu ładującego i aby Bezpieczny rozruch moduł został preinstalowany.  Teraz opowiem o niewłaściwym, moim zdaniem, sposobie, w jaki Linux poradził sobie z problemem.

Linux i bezpieczny rozruch

Secure Boot wymaga, aby każdy uruchamiany program posiadał podpis gwarantujący jego autentyczność przechowywany w bazie danych pamięci nieulotnej płyty głównej. Istnieją dwa sposoby pojawienia się w tej bazie danych. Niezależnie od tego, czy jest dołączony przez producenta, czy dołączony przez firmę Microsoft.

Rozwiązanie osiągnięte przez niektóre dystrybucje Linuksa z Microsoft było to, że ta firma zaakceptowała podpis pliku binarnego, który będzie odpowiedzialny za uruchomienie programu ładującego każdej dystrybucji. Te pliki binarne zostały udostępnione społeczności.

Później Linux Foundation uruchomi ogólne rozwiązanie, które może zostać zaadaptowane przez wszystkie dystrybucje.

Poszukując lepszego rozwiązania, programista Red Hat zasugerował Linusowi Torvaldsowi:

Cześć Linusie,

Czy możesz dołączyć ten zestaw łatek?

Udostępnia funkcję, dzięki której klucze mogą być dynamicznie dodawane do jądra działającego w trybie bezpiecznego rozruchu. Aby umożliwić załadowanie klucza w takich warunkach, wymagamy, aby nowy klucz był podpisany przez klucz, który już posiadamy (i któremu ufamy), przy czym klucze, które „już mamy” mogą obejmować te osadzone w jądrze, te w bazy danych UEFI i sprzętu kryptograficznego.

Teraz "keyctl add" będzie już obsługiwał certyfikaty X.509 podpisane w ten sposób, ale usługa podpisywania Microsoftu będzie podpisywać tylko wykonywalne pliki binarne EFI PE.

Moglibyśmy wymagać od użytkownika ponownego uruchomienia systemu BIOS, dodania klucza, a następnie przełączenia się z powrotem, ale w niektórych przypadkach chcemy mieć możliwość zrobienia tego, gdy jądro jest uruchomione.

Sposób, w jaki wymyśliliśmy, aby to naprawić, polega na osadzeniu certyfikatu X.509 zawierającego klucz w sekcji o nazwie „.keylist” w pliku binarnym EFI PE, a następnie pobraniu pliku binarnego podpisanego przez Microsoft

Słowo Linusa

Odpowiedź Linusa (przypomnijmy, że to było przed jego duchowymi rekolekcjami, aby ponownie przemyśleć swoją postawę w relacjach z innymi ludźmi) była następująca:

UWAGA: Poniższy tekst zawiera wulgaryzmy

Chłopaki, to nie jest konkurs ssania kutasa.

Jeśli chcesz używać plików binarnych PE, kontynuuj. Jeśli Red Hat chce pogłębić swoją relację z Microsoftem, to *Twój* problem. To nie ma nic wspólnego z jądrem, którym się opiekuję. Łatwo jest mieć silnik podpisu, który analizuje plik binarny PE, weryfikuje podpisy i podpisuje powstałe klucze własnym kluczem. Kod, na litość boską, jest już napisany, jest w tej cholernej prośbie o włączenie.

Dlaczego miałoby mnie to obchodzić? Dlaczego jądro miałoby dbać o jakieś idiotyczne "podpisujemy tylko binaria PE" głupie? Obsługujemy X.509, który jest standardem podpisywania.

Można to zrobić na poziomie użytkownika. Nie ma wymówki, aby to zrobić w jądrze.

Linus

Moim zdaniem Linus choć raz miał rację. W rzeczywistości ani Linux Foundation, ani dystrybucje nie powinny być szantażowane przez Microsoft.  Prawdą jest, że użytkownicy mogli zostać zgubieni. Ale, jak się później okazało, Windows 8 okazał się porażką, a XP panował znacznie dłużej.

W rzeczywistości, gdy Microsoft staje w obliczu bitwy, jest zmuszony przestrzegać standardów. Stało się tak, gdy zawiodła z SIlverlight i została zmuszona do przyjęcia standardu internetowego HTML 5. Stało się tak, gdy musiała zrezygnować z rozwoju silnika renderującego i oprzeć Edge'a na Chromium.

Nie powinniśmy też zapominać, że aby przyciągnąć programistów, musiała zawierać tylko możliwość uruchomienia Linuksa w systemie Windows.

Dystrybucje Linuksa są w lepszej niż kiedykolwiek pozycji, aby zaoferować użytkownikom alternatywę dalszego korzystania z doskonale funkcjonalnego sprzętu.