Morfitronik Security & Privacy

Linux kernel EFI boot stub i zaszyfrowany Debian (LUKS+LVM)

Ostatnia aktualizacja: 2020-03-02
Morfik

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.

Czym jest linux kernel EFI boot stub

Zgodnie z tym co można wyczytać w dokumentacji kernela linux, EFI boot stub to umiejętność tworzenia obrazu kernela w taki sposób, by podawał się on za obraz PE/COFF (Portable Executable/Common Object File Format). Firmware EFI widząc taki plik interpretuje go jako wykonywalny plik bootloader'a i go uruchamia. W ten sposób można zrezygnować z tradycyjnego podejścia przy uruchamianiu systemu, który zakłada wykorzystanie czy to jakiegoś menadżera rozruchu, czy też pełnowymiarowego bootloader'a. W zasadzie z racji, że EFI boot stub przeprowadza szereg zadań charakterystycznych dla programu rozruchowego, to można by pokusić się o nazwanie go bootloader'em.

Konfiguracja kernela

By być w stanie wygenerować obraz kernela, który ma być uruchomiony przez firmware EFI, musimy mieć w kernelu włączoną opcję CONFIG_EFI_STUB . Warto też włączyć opcję CONFIG_EFI_VARS jako, że umożliwi ona zarządzanie zmiennymi EFI za sprawą narzędzia efibootmgr. Jeśli korzystamy z dystrybucyjnego kernela dostarczanego przez deweloperów dystrybucji Debian, to on ma już stosowne opcje włączone i nic nie musimy dodatkowo konfigurować. Niemniej jednak, jeśli budujemy własny kernel, to trzeba te opcje mieć na uwadze.

Brak wsparcia dla systemu plików ext[,2,3,4]

Pierwsza niedogodność płynąca z uruchamiania systemu za sprawą EFI boot stub to brak wsparcia dla natywnego systemu plików linux'a, tj. ext2, ext3 czy ext4. Do tego EFI boot stub może w zasadzie uruchomić jedynie pliki z partycji ESP.

Warto w tym miejscu zaznaczyć, że partycja ESP może zostać zamontowana jako /boot/ zamiast standardowo jako /efi/ . W takim układzie linux będzie widział partycję /efi/ jako jako partycję /boot/ i standardowo będzie umieszczał w niej obrazy kernela i initrd przy instalacji/aktualizacji jądra operacyjnego. Niemniej jednak, będziemy ograniczeni przez system plików FAT, a ma to znaczenie choćby w przypadku tworzenia dowiązań symbolicznych do plików vmlinuz i initrd.img, by uniknąć ciągłej zmiany konfiguracji ilekroć zostanie wypuszczony nowy kernel. W systemie plików FAT możemy zapomnieć o dowiązaniach, bo zwyczajnie on ich nie wspiera.

Mamy zatem do wyboru dwie opcje. W pierwszej z nich używamy dwóch partycji, tj. /efi/ sformatowana jako fat16/fat32 i /boot/ sformatowana jako ext4 i kopiujemy obraz kernela/initrd między nimi. W drugiej opcji używamy jednej partycji /boot/ sformatowanej jako fat32 i przepisujemy nazwy plików obrazu kernela/initrd za każdym razem jak tylko w systemie pojawi się aktualizacją jądra operacyjnego. Nie ważne którą opcję wybierzemy, to raczej bez dodatkowej automatyzacji tego procesu się nie obejdzie. W moim przypadku wykorzystywana była osobna partycja /efi/ .

Obraz z końcówką .efi

W Debianie obraz kernela znajduje się standardowo na partycji /boot/ pod nazwą vmlinuz-x.x.x-x-amd64 . Po skopiowaniu go na partycję ESP trzeba mu zmienić nazwę dopisując na jej końcu rozszerzenie .efi .

Ja nie miałem pojęcia o tym i skopiowałem jedynie obraz kernela na partycje ESP i uruchomiłem system. Kernel się załadował, a system uruchomił się bez problemu. Wygląda na to, że niekoniecznie trzeba dopisywać do nazwy obrazu kernela końcówkę .efi . Może to kwestia implementacji EFI, kto wie. Tak czy inaczej, jeśli w naszym przypadku system nie chce się uruchomić, to sprawdźmy czy ta końcówka coś pomoże.

Ograniczona liczba wpisów

W przypadku mojego laptopa było zdefiniowanych 24 różnych wpisów w konfiguracji EFI. Poniżej znajduje się pełna ich lista:

# efibootmgr -v
BootCurrent: 000A
Timeout: 0 seconds
BootOrder: 000A,0000,0001,0002,0003,000D,0007,0008,0009,000B,000C,000E,000F,0010,0011,0012
Boot0000  Setup	FvFile(721c8b66-426c-4e86-8e99-3457c46ab0b9)
Boot0001  Boot Menu	FvFile(126a762d-5758-4fca-8531-201a7f57f850)
Boot0002  Diagnostic Splash Screen	FvFile(a7d8d9a6-6ab0-4aeb-ad9d-163e59a7a380)
Boot0003  Lenovo Diagnostics	FvFile(3f7e615b-0d45-4f80-88dc-26b234958560)
Boot0004  Startup Interrupt Menu	FvFile(f46ee6f4-4785-43a3-923d-7f786c3c8479)
Boot0005  ME Configuration Menu	FvFile(82988420-7467-4490-9059-feb448dd1963)
Boot0006  Rescue and Recovery	FvFile(665d3f60-ad3e-4cad-8e26-db46eee9f1b5)
Boot0007  USB CD	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,86701296aa5a7848b66cd49dd3ba6a55)
Boot0008  USB FDD	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,6ff015a28830b543a8b8641009461e49)
Boot0009  ATAPI CD0	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35401)
Boot000A* ATA HDD0	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f600)
Boot000B* ATA HDD1	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f601)
Boot000C* ATA HDD2	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f602)
Boot000D* USB HDD	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,33e821aaaf33bc4789bd419f88c50803)
Boot000E  PCI LAN	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,78a84aaf2b2afc4ea79cf5cc8f3d3803)
Boot000F  ATAPI CD1	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35404)
Boot0010  Other CD	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a35406)
Boot0011* ATA HDD3	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f604)
Boot0012  Other HDD	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f606)
Boot0013* IDER BOOT CDROM	PciRoot(0x0)/Pci(0x16,0x2)/Ata(0,1,0)
Boot0014* IDER BOOT Floppy	PciRoot(0x0)/Pci(0x16,0x2)/Ata(0,0,0)
Boot0015* ATA HDD	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,91af625956449f41a7b91f4f892ab0f6)
Boot0016* ATAPI CD:	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,aea2090adfde214e8b3a5e471856a354)
Boot0017* PCI LAN	VenMsg(bc7838d2-0f82-4d60-8316-c068ee79d25b,78a84aaf2b2afc4ea79cf5cc8f3d3803)

Do końca jeszcze nie znam przeznaczenia ich wszystkich ale jeśli chcemy mieć możliwość odpalania linux'a bezpośrednio przez EFI, to trzeba dodać kolejny wpis.

W tym przypadku mogłem dodać maksymalnie 4 nowe wpisy. To bardzo niewiele. Na starym laptopie w konfiguracji syslinux/extlinux mam tych wpisów ponad 10, każdy ma nieco inny zestaw parametrów, tak bym mógł w przypadku zaistnienia różnych niecodziennych zdarzeń bez problemu odzyskać swój system.

Pewnie nie wszystkie wpisy są potrzebne i kilka slotów można by odzyskać usuwając zbędne pozycje ale trzeba też zaznaczyć tutaj fakt, że część wpisów nie może zostać usunięta. Po tym jak się je usunie, to są tworzone na nowo po restarcie maszyny. Można zatem przyjąć, że w przypadku tego laptopa, użytkownik ma do dyspozycji tylko 4 pozycje na określenie systemu, który chce bezpośrednio uruchomić.

Parametry kernela

Gdy w grę wchodzi standardowy bootloader, parametry kernela zwykłe podaje się bezpośrednio w konfiguracji samego bootloader'a lub też w plikach systemowych, z których te parametry zostaną podebrane przez bootloader. W przypadku EFI boot stub parametry kernela trzeba na sztywno zdefiniować we wpisie, który dodawany jest za sprawą narzędzia efibootmgr z uruchomionego systemu. By zmienić parametry kernela, trzeba usunąć cały wpis i stworzyć go na nowo dodając lub zmieniając pożądane parametry i ich opcje.

Możemy też zapomnieć o tymczasowej zmianie parametrów przez edycję kernel cmd podczas rozruchu systemu, tak jak to jest standardowo odstępne przez wciśnięcie klawisza Tab w okienku bootloader'a.

Bardzo niewygodna edycja wpisów

W przypadku bootloader'a, zwykle dodanie nowego wpisu nie stanowi problemu. Wystarczy edytować konkretny plik, skopiować zwrotkę odpowiedzialną za jeden wpis wyświetlany w fazie startu i przerobić go zgodnie z potrzebą. Z wpisami w EFI boot stub nie ma tak łatwo i trzeba używać tylko i wyłączenie poleceń shell'owych, w których to trzeba zawsze definiować wszystkie parametry. Takie polecenia mogą być naprawdę długie. Poniżej przykład:

# efibootmgr --disk /dev/sda --part 5 --create --label "Debian EFISTUB" --loader \
             '\EFI\BOOT\vmlinuz-5.4.0-4-amd64' --unicode 'root=/dev/mapper/sd_debian-root \
             ro initrd=\EFI\BOOT\initrd.img-5.4.0-4-amd64' --verbose

To bardzo podstawowy przykład, do odszyfrowania mojego systemu na bazie LUKSv2 + LVM i nie zawiera całej masy opcji kernela, których na co dzień używam w swojej starej maszynie. Gdybym je wszystkie musiał tutaj określić, to ta linijka była by trzy razy dłuższa.

Czasami parametr initrd= nie zadziała

Mój system jest w pełni zaszyfrowany i by móc go odpalić wymagany jest obraz initrd. Używając tradycyjnego bootloader'a mogę wskazać dowolny plik/pliki za sprawą parametru initd= i problem mam z głowy. A jak wygląda sprawa w przypadku EFI boot stub? Ano tak, że ten parametr initrd= jest specyficzny dla firmware EFI i niekoniecznie może być wspierany w tej konkretnej implementacji. Akurat w przypadku mojego laptopa jest. Zatem mój system da radę odszyfrować wykorzystując ten mechanizm. Niemniej jednak, trzeba mieć na uwadze, że nie wszędzie i nie zawsze się to uda zrobić.

Odwrócone ukośniki

Z reguły w linux'ach do określania ścieżek korzysta się ze slash'a ( / ) , np. /home/morfik/ ale do określania wpisów w EFI boot stub trzeba używać odwróconych ukośników, tj. backslash'a ( \ ). Może ktoś uzna, że się czepiam ale popatrzcie na to powyższe polecenie dodawania wpisów. W niektórych parametrach są normalne ukośniki, a w innych te odwrócone -- ten kto zaprojektował ten mechanizm był idiotą... :]

Interpretacja dodanych wpisów

Gdy już dodamy kilka wpisów na listę możliwych do uruchomienia systemów, to czasem chcielibyśmy podejrzeć tę listę, by się upewnić, że zostanie załadowany ten kernel, który jest nam potrzebny. Czasami wpisy mogą się różnić jedynie parametrami i zwykle nazwa, która nadaliśmy wpisowi, nam nic nie powie. Z okna wyboru systemu podczas startu za bardzo nic się nie dowiemy, bo tam widnieje jedynie, tylko krótka nazwa i podejrzeć parametrów nie sposób. W zasadzie to widać tylko tyle co na poniższym obrazku:

Ale nie o tym chciałem pisać, bo przecie istnieje narzędzie efibootmgr , które jest nam w stanie zwrócić ładnie przeformatowaną listę opcji rozruchu, tak jak to było widać na początku, prawda? No chyba, że się tam doda wpis z linux. Wtedy to wyjście wyglądać zaczyna tak:

Boot0018* Debian EFISTUB	HD(5,GPT,9d090ca2-e968-4399-9af1-adb80ba4b924,0x38b4000,0xff800)/File(\EFI\BOOT\vmlinuz-5.4.0-4-amd64)r.o.o.t.=./.d.e.v./.m.a.p.p.e.r./.s.d._.d.e.b.i.a.n.-.r.o.o.t. .r.o. .i.n.i.t.r.d.=.\.E.F.I.\.B.O.O.T.\.i.n.i.t.r.d...i.m.g.-.5...4...0.-.4.-.a.m.d.6.4.

Co się tam pan czepiasz, przecie system idzie uruchomić...

Próbowałem znaleźć jakieś rozwiązanie tego problemu ale póki co mi się nie udało, a że ten mechanizm EFI boot stub ma już i tak całą masę wad, to raczej wątpię, że przeznaczę jeszcze czas na znalezienie rozwiązania problemów, których w normalnych menadżerach rozruchu się nie spotyka, nie mówiąc już o bohaterskich próbach ich przezwyciężenia...

Podsumowanie

Mi jakoś niespecjalnie ten cały EFI boot stub przypadł do gustu. Może znajdzie on zastosowanie w przypadku przeciętnego Kowalskiego, który chce jedynie podnieść swój system jak najszybciej i bez zbędnych pytań czy zagłębiania się w aspekty konfiguracyjne. No dobrze, że taki mechanizm istnieje. Jego zaletą jest na pewno fakt, że jest on za free, nie wymaga instalowania żadnego dodatkowego oprogramowania i działa OOTB nie oferując przy tym w zasadzie żadnej konfiguracji. No ja jednak potrzebuję czegoś bardziej zaawansowanego i zwyczajnie EFI boot stub nie spełnia moich oczekiwań i tych nawet podstawowych wymagań. Jeśli jednak ktoś korzysta z jednego systemu i nie miesza w nim, to ten EFI boot stub jak najbardziej może mu się przydać ale jeśli tylko coś bardziej zaawansowanego będziemy chcieli robić z naszym systemem, to trzeba rozejrzeć się za pełnoprawnym menadżerem rozruchu czy bootloader'em.


Komentarze

Zawartość wpisu