Dnia 29-07-2020 do publicznej wiadomości zostały podane informacje na temat podatności BootHole, która to za sprawą bootloader'a GRUB2 w różnych dystrybucjach linux'a jest w stanie obejść mechanizm bezpieczeństwa EFI/UEFI, tj. Secure Boot. Z informacji, które opublikował Debian, sprawa nie wygląda miło, jako że poza aktualizacją GRUB2, shim, jądra linux, Fwupdate oraz Fwupd, unieważnieniu podlegają również klucze dystrybucji Debian/Ubuntu, przez co praktycznie cały soft podpisany tymi kluczami (w tym systemy live) przestaną działać w trybie Secure Boot. Czy jest się czego obawiać i co użytkownik korzystający z mechanizmu SB powinien w takiej sytuacji zrobić?

Jakiś czas temu opisywałem konfigurację własnych kluczy EFI/UEFI, którymi można zastąpić te wbudowane standardowo w firmware naszego komputera. W tamtym artykule napotkałem jednak dość dziwny problem, za sprawą którego nie można było zaktualizować zmiennych PK , KEK , db i dbx przy pomocy efi-updatevar z poziomu działającego linux'a. Gdy próbowało się te zmienne przepisać, dostawało się błąd typu Operation not permitted . Niby system został uruchomiony w trybie Setup Mode ale z jakiegoś powodu odmawiał on współpracy i trzeba było te zmienne aktualizować bezpośrednio z poziomu firmware EFI/UEFI, co było trochę upierdliwe. Szukając wtedy informacji na ten temat, jedyne co znalazłem, to fakt, że sporo osób ma podobny problem i najwyraźniej firmware mojego laptopa jest ździebko niedorobiony, przez co efi-updatevar nie mógł realizować swojego zdania. Rzeczywistość okazała się nieco inna, a rozwiązanie samego problemu było wręcz banalne.

Przeniesienie mojego Debiana z laptopa mającego konfigurację BIOS i tablicę partycji MBR/MS-DOS do maszyny wyposażonej w firmware EFI/UEFI nie było jakoś stosunkowo trudnym zadaniem. Nawet kwestia włączenia Secure Boot okazała się o wiele mniej skomplikowana niż w rzeczywistości mogłoby się człowiekowi wydawać. Problem jednak pojawił się w przypadku płytek czy pendrive z systemami live. Nie chodzi przy tym o uruchamianie nośników z dopiero co wypalonymi obrazami ISO/IMG, bo te również nie sprawiają kłopotów. Chodzi bardziej o rozwiązanie multiboot, które oferuje wgranie wielu obrazów live na jedno urządzenie i odpalanie tego systemu, który sobie użytkownik w danym momencie zażyczy. Do tej pory korzystałem z projektu GLIM i może on posiada wsparcie dla EFI/UEFI ale już wsparcia dla Secure Boot mu zabrakło. W efekcie w konfiguracji EFI/UEFI + Secure Boot, GLIM stał się bezużyteczny i trzeba było rozejrzeć się za nieco innym rozwiązaniem. Okazało się, że nie trzeba daleko szukać, bo rEFInd jest w stanie natywnie uruchomić system z obrazu ISO praktycznie każdej dystrybucji linux'a (Ubuntu/Debian/Mint/GParted/CloneZilla) i w zasadzie trzeba tylko nieco inaczej przygotować nośnik, by móc na nowo cieszyć się korzyściami jakie oferuje pendrive multiboot.

W środowiskach linux'owych Secure Boot nie jest zbyt mile widziany i raczej postrzegany jako źródło wszelkiego zła na świecie. Sporo użytkowników linux'a dopatruje się w Secure Boot zamachu na wolność decydowania o swoim sprzęcie, który ma być serwowany przez Microsoft. Niemniej jednak, odsądzanie tego mechanizmu od czci i wiary jest moim zdaniem lekko nie na miejscu. Niewielu użytkowników linux'a zdaje sobie sprawę, że od prawie dekady istnieje taki wynalazek jak shim (no i jest też PreLoader), który umożliwia dystrybucjom linux'a (jak i ich końcowym użytkownikom) zaimplementowanie Secure Boot we własnym zakresie. Niemniej jednak, można całkowicie się obejść bez tych dodatków usuwając wbudowane w firmware EFI/UEFI certyfikaty i dodając na ich miejsce własnoręcznie wygenerowane klucze kryptograficzne. Takie podejście sprawia, że kod podpisany tylko i wyłącznie przez nas będzie mógł zostać uruchomiony przez firmware komputera w trybie Secure Boot, co może ździebko poprawić bezpieczeństwo naszego systemu. Poniższy artykuł ma na celu pokazać w jaki sposób zastąpić wbudowane w firmware EFI/UEFI klucze swoimi własnymi przy wykorzystaniu dystrybucji Debiana.

Instalacja linux'a w trybie EFI/UEFI nieco inaczej wygląda niż tradycyjna instalacja systemu, zwana często dla odróżnienia trybem BIOS, przynajmniej przy wykorzystaniu debootstrap Jeśli kupujemy nowego desktopa czy laptopa, to zwykle będziemy mieli na dysku twardym zainstalowanego windows'a i tym samym przygotowany cały układ partycji niezbędny do prawidłowego uruchomienia systemu w trybie EFI/UEFI. Co jednak w przypadku, gdy kupimy komputer bez systemu operacyjnego? W takiej sytuacji trzeba będzie ręcznie podzielić dysk na partycje oraz zainstalować menadżer rozruchu (rEFInd) lub też bootloader (grub/grub2/syslinux/extlinux) i skonfigurować wszystkie te elementy samodzielnie. Prawdopodobnie instalator Debiana jest w stanie za nas te kroki przeprowadzić automatycznie ale my nie będziemy korzystać z automatycznych rozwiązań, bo one nieco odmóżdżają. Spróbujemy za to stworzyć sobie uniwersalną konfigurację, która pozwoli nam zainstalować i odpalić dowolną dystrybucję linux'a w trybie EFI/UEFI.

Zapewne każdy z nas słyszał o narzędziu do testowania pamięci operacyjnej RAM zwanym memtest86. W Debianie są dostępne dwa pakiety memtest86 (strona projektu) oraz memtest86+ (strona projektu) , które można sobie zainstalować w systemie. Niemniej jednak, jak się popatrzy na daty ostatnich wersji obu tych aplikacji (rok 2014), to mamy do czynienia z dość starym oprogramowaniem. Tak czy inaczej, jeśli dany soft działa, to bez znaczenia powinno być jak stary on jest. Problem w przypadku memtest86 dostarczanego w tych dwóch pakietach jest taki, że działa on w zasadzie jedynie w konfiguracji BIOS, a nie EFI/UEFI. Dodatkowo, oryginalny memtest86 został sprzedany PassMark'owi, który od wersji 5.0 uczynił go własnościowym softem. To dlatego w Debianie nie będzie już nowszej wersji memtest86. W dalszym ciągu memtest86 może działać w konfiguracji EFI/UEFI ale potrzebna nam jest wersja, która to EFI/UEFI wspiera. Memtest86 zaczął wspierać EFI/UEFI od wersji 5.0. Jeśli nam nie przeszkadza licencja własnościowa, to możemy sobie przygotować memtest86, tak by można go było bez problemu odpalić z menadżera rozruchu rEFInd.

Szukając informacji na temat uruchamiania mojego zaszyfrowanego Debiana (LUKSv2+LVM) na laptopie z EFI/UEFI, natrafiłem na dość ciekawy mechanizm zwany kernel EFI boot stub, czasem też zwany kernel EFISTUB. Zadaniem tego mechanizmu jest uruchomienie linux'a bezpośrednio z poziomu firmware EFI z pominięciem czy też bez potrzeby stosowania dodatkowych menadżerów rozruchu (rEFInd) czy bootloader'ów (grub/grub2/syslinux/extlinux). Jakby nie patrzeć bardzo ciekawa alternatywa, która wymaga, by się z nią zapoznać i ocenić jej przydatność pod kątem użyteczności.

Mając możliwość skonfigurowania EFI/UEFI na moim laptopie, postanowiłem jak najbardziej się za to przedsięwzięcie zabrać. Okazało się jednak, że w przypadku takiej dystrybucji linux'a jak Debian, to zadanie może być nieco problematyczne, zwłaszcza gdy chce się korzystać jedynie z menadżera rozruchu jakim jest rEFInd, czyli bez dodatkowego bootloader'a (grub/grub2/syslinux/extlinux) instalowanego bezpośrednio na dysku twardym i jednocześnie posiadając w pełni zaszyfrowany system (LUKSv2 + LVM). Rzecz w tym, że w takiej sytuacji w konfiguracji rEFInd trzeba podawać ścieżki bezpośrednio do plików initrd.img oraz vmlinuz (obecnych na partycji /boot/ ). W Debianie nazwy tych plików mają format initrd.img-x.x.x-x-amd64 i vmlinuz-x.x.x-x-amd64 . Za każdym razem, gdy wypuszczany jest nowy kernel, to ten numerek ( x.x.x-x ) ulega zmianie, co pociąga za sobą potrzebę ręcznego dostosowania konfiguracji rEFInd. Może i aktualizacje kernela w Debianie nie są jakoś stosunkowo częste ale może istnieje sposób, by ten problem z dostosowaniem konfiguracji rozwiązać?