shim:  mniej problemów z uruchamianiem Linuksa na komputerach z Windows 8

Niepokój twórców linuksowych dystrybucji tylko wzrósł po tym,gdy Fundacja Linuksa wyjawiła, z jakiminiedogodnościami wiąże się uzyskanie kluczakryptograficznego, pozwalającego na stworzenie zgodnego zmechanizmem Secure Boot bootloadera dla innych niż Windows 8systemów operacyjnych. Wyglądało na to, że zabezpieczenia(utrudnienia?) wprowadzone przez Microsoft skutecznie zablokujeinstalowanie mniej popularnych, hobbystycznych dystrybucji Linuksa(nie mówiąc już o *BSD czy innych alternatywnych OS-ach) na nowychkomputerach z logotypem Windows 8. W teorii poprawna implementacjaSecure Boot dawałaby możliwość uruchomienia innych bootloaderów,ale już wiadomo, że nie musi tak być w praktyce. Na przykładLenovo Thinkcentre M92p odmawia uruchomienia czegokolwiekinnego niż Windows 8 lub RHEL. Taką dla przykładu Fedorę udałosię zainstalować, ale wystartowanie było już niemożliwe, z winytwórców firmware, którzy po prostu sprawdzali, czy wpisy wbootloaderze są zgodne z ciągami „Windows Boot Manager” lub„Red Hat Enterprise Linux”.Takich przypadków będzie pewnie więcej – twórcy firmware'u,pracujący dla producentów płyt głównych, znani są z tego, żewydają oprogramowanie nadziewane bugami niczym sernik rodzynkami.Dlatego bootloader, który pozwoliłby każdemu na uruchomieniedowolnego wybranego przez siebie systemu operacyjnego na zniewolonychprzez Secure Boot komputerach to narzędzie bardzo potrzebne.Narzędzie takie stworzył były pracownik Red Hata, Matthew Garret,deklarując: nadającą się do użytku wersję shim można jużpobrać (…) jest ona przeznaczona dla dystrybucji, które chcądziałać na Secure Boot, ale nie chcą wchodzić w układy zMicrosoftem.RozwiązanieGarreta niewiele ma wspólnego z tym, co opracowywano dla Fedory(nad którą deweloper od lat pracuje). Przypomnijmy, że Fedoramiała mieć swójklucz, uzyskany od VeriSigna, w płatnym procesiecertyfikacyjnym, z wykorzystaniem klucza Microsoftu. Takie podejściemoże być dobre dla linuksowych potentatów, Red Hata czyCanonicala, ale dla mniejszych, robionych często hobbystyczniedystrybucji, nie wchodzi w grę. Bootloader shim korzysta więc zarchitektury opracowanej przez deweloperów SUSE. Jak wyjaśnia jeden z nich, Vojtěch Pavlík, bootloader SUSE ma swoją własnąbazę kluczy, w dodatku do klucza UEFI/Microsoftu, pozwalającego muuruchomić się na zabezpieczonym przez Secure Boot sprzęcie.Następnie bootloader sprawdza, czy dostępny jest bootloader GRUB2,podpisany już domyślnym kluczem SUSE, lub ewentualnie innymikluczami, należącymi do właściciela komputera (tylko osobasiedząca przed konsolą może zmienić klucz). Ostatecznie GRUB2(lub inny bootloader) ładuje jądro Linuksa. [img=mok2]Garret do drugiego etapudziałania bootloadera SUSE dorobił wygodny interfejs, pozwalającyużytkownikowi przejrzeć listę dostępnych systemów plików,wybrać klucz, dodać go do bazy i oznaczyć, że binaria podpisanetym kluczem będą zaufane. W praktyce każdy twórca linuksowejdystrybucji będzie mógł teraz umieścić na swoim obrazieinstalacyjnym gotowy bootloader shim, własny klucz oraz podpisanynim bootloader UEFI grubx64.efi. Użytkownik będzie musiał tylko zapierwszym razem po uruchomieniu komputera dodać klucz ten do bazyshima – domyślniedostarczana wersja shima nie zawiera żadnych wbudowanych kluczy,poza tym, którym podpisano samą bazę kluczy. Krytycy zapewne stwierdzą, żenie jest to idealne rozwiązanie. Dla „ideologicznych”dystrybucji, takich jak Debian, umieszczenie na nośnikachinstalacyjnych zamkniętego kodu nie wchodzi w grę. Jednakpozostałym powinno się przydać – wśród deweloperów Archa,Mandrivy czy Sabayona nie widać jakiejś wielkiej ochoty do męczeniasię z procesem certyfikacji Microsoftu.