Dwie wiadomości dotyczące pre-bootloadera

Są to tłumaczenia dwóch postów, które James Bottomley zamieścił na swoim blogu. Pierwszy post został opublikowany 1 lutego i nosi tytuł „LCA2013 and Restruifying the Secure Boot”

Przez chwilę byłem cicho, więc nadszedł czas, aby zaktualizować informacje o tym, co dzieje się z Bezpiecznym programem ładującym Linux Foundation (zwłaszcza, że ​​był on prezentowany na LCA2013). (Link do slajdów)

Istotą problemu jest to, że GregKH (programista jądra Greg Kroah-Hartman) odkrył na początku grudnia, że ​​proponowany Pre-BootLoader nie będzie działał w swojej obecnej formie z Gummiboot. Było to nieco zniechęcające, ponieważ oznaczało, że nie spełniał misji Linux Foundation polegającej na aktywowaniu wszystkich programów ładujących. W badaniach powód był prosty: Gummiboot został stworzony, aby zademonstrować, że można stworzyć mały i prosty program ładujący, który wykorzystywałby wszystkie usługi dostępne na platformie UEFI, zamiast być ogromnym programem ładującym łącza, takim jak GRUB. Niestety oznacza to, że uruchamiasz jądra za pomocą funkcji BootServices-> LoadImage (), co oznacza, że ​​ładowane jądro musi przejść przez bezpieczne testy rozruchowe na platformie UEFI. Pierwotnie Pre-BootLoader, jak shim (Bootloader Mathew Garretta), został napisany tak, aby używał ładowania łącza PE / Coff w celu pokonania bezpiecznego sprawdzania rozruchu. Niestety oznacza to, że coś uruchamianego przez Pre-BootLoader musi również korzystać z ładowania łącza, aby pokonać sprawdzanie bezpiecznego rozruchu wszystkiego, co chce załadować, a zatem Gummiboot, który celowo nie jest programem ładującym łącza, nie będzie działał pod tym schemat.

Musiałem więc zrestrukturyzować i przepisać: problem obejmował teraz „jak utworzyć program ładujący łącza podpisany przez firmę Microsoft, który przestrzega ich zasad”, do „jak umożliwić wszystkim elementom podrzędnym programu ładującego korzystanie z funkcji BootServices-> LoadImage () sposób przestrzegania ich zasad. Na szczęście istnieje sposób na przechwycenie infrastruktury podpisującej platformę UEFI poprzez zainstalowanie własnego protokołu bezpieczeństwa architektury. Niestety specyfikacja inicjalizacji platformy nie jest w rzeczywistości częścią specyfikacji UEFI, ale na szczęście jest zaimplementowana w każdym systemie Windows 8, jaki można znaleźć. Nowa architektura przechwytuje ten protokół i dodaje własną kontrolę bezpieczeństwa. Istnieje jednak drugi problem: podczas gdy jesteśmy w trakcie wywołania zwrotnego protokołu bezpieczeństwa architektury, niekoniecznie jesteśmy właścicielami ekranu systemu UEFI, co całkowicie uniemożliwia wykonanie testu użytkownika w celu autoryzacji wykonania pliku binarnego. Na szczęście istnieje nieinteraktywny sposób, aby to zrobić, a jest nim mechanizm SUSE Machine Owner Key (MOK). Dlatego Linux Foundation Pre-BootLoader ewoluował, aby używać standardowych zmiennych MOK do przechowywania autoryzowanych binarnych skrótów.

Rezultatem tego wszystkiego jest to, że możesz teraz używać Pre-BootLoader z Gummiboot (tak jak to było zrobione w wersji demonstracyjnej na LCA2013). Aby uruchomić, musisz dodać 2 skróty: jeden dla samego Gummiboot, a drugi dla jądra, które chcesz załadować, ale w rzeczywistości jest to dobra rzecz, ponieważ teraz masz jedną politykę bezpieczeństwa kontrolującą całą sekwencję rozruchową. Sam Gummiboot został również załatany, aby rozpoznać awarię z powodu bezpiecznego rozruchu i wyświetla komunikat z informacją, który skrót do zarejestrowania.

Zrobię osobny post wyjaśniający, jak działa nowa architektura, ale pomyślałem, że lepiej będzie wyjaśnić, co wydarzyło się w zeszłym miesiącu.

Drugi post, który napisał wczoraj i nosi tytuł „Uruchomił system bezpiecznego rozruchu Linux Foundation”

Zgodnie z obietnicą, oto system bezpiecznego rozruchu Linux Foundation. W rzeczywistości został on udostępniony nam przez firmę Microsoft 6 lutego, ale podczas podróży, konferencji i spotkań nie miałem czasu, aby sprawdzić wszystko do dzisiaj. Pliki to:

Preloader.efi (md5sum 4f7a4f566781869d252a09dc84923a82)
HashTool.efi (md5sum 45639d23aa5f2a394b03a65fc732acf2)
Utwórz także bootowalny obraz mini-USB; (Musisz zainstalować go na USB za pomocą dd; obraz ma partycje GPT, więc wykorzystuje cały dysk). Ma powłokę EFI tam, gdzie powinno znajdować się jądro i używa gummiboot do jego załadowania. Znajdziesz go tutaj (md5sum 7971231d133e41dd667a184c255b599f).

Aby użyć obrazu mini-USB, musisz wprowadzić skróty dla loader.efi (w folderze \ EFI \ BOOT) i shell.efi (w folderze głównym). Zawiera również kopię KeyTool.efi, musisz wprowadzić hash, aby uruchomić.

Co się stało z KeyTool.efi? Pierwotnie miał być częścią naszego sygnowanego zestawu. Jednak podczas testów Microsoft odkrył, że z powodu błędu w jednej z platform UEFI, można go użyć do programowego usunięcia klucza platformy, co zrujnowałoby system bezpieczeństwa UEFI. Dopóki tego nie rozwiążemy (mamy prywatnego dostawcę w pętli), odmówili podpisania KeyTool.efi, chociaż możesz go autoryzować dodając zmienne MOK, jeśli chcesz go uruchomić.

Daj mi znać, jak to się dzieje, ponieważ jestem zainteresowany zbieraniem opinii na temat tego, co działa, a co nie. W szczególności obawiam się, że nadpisywanie protokołu bezpieczeństwa może nie działać na niektórych platformach, dlatego szczególnie chcę wiedzieć, czy na nich nie działa.

Źródła:

http://blog.hansenpartnership.com/lca2013-and-rearchitecting-secure-boot/

http://blog.hansenpartnership.com/linux-foundation-secure-boot-system-released/

Zdecyduj, czy to dobra, czy zła wiadomość.