Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Skazani na firmware. Serwer na ARM64? Tak, to możliwe! S07E03

480 views

Published on

Przedstawiamy firmware UEFI, dzięki któremu możliwe jest coraz śmielsze wkraczanie architektury ARM64 do świata urządzeń serwerowych, czyli królestwa władanego przez Intel. Standardy, ich założenia i realizacja zostałą przybliżona na przykładzie dodawania wsparcia dla n

Published in: Software
  • Login to see the comments

  • Be the first to like this

Skazani na firmware. Serwer na ARM64? Tak, to możliwe! S07E03

  1. 1. Skazani na firmware S07:E03 “Serwer na ARM64? Tak, to możliwe!”
  2. 2. Plan prezentacji ● UEFI - wprowadzenie ● EDK2 Build System - jak zbudować swój firmware? ● UEFI Driver model ● Aplikacje w UEFI ● Interakcje UEFI/OS ● Co z tego wyszło?
  3. 3. ARM64 jako serwer lub PC? ● ARM wychodzi poza embedded ● Potrzebna unifikacja rozwiązań - nowe standardy wokół ARMv8 ○ Server Base System Architecture (SBSA) ○ Server Base Boot Requirements (SBBR) ● Serwery - Qualcom Falkor i Cavium Thunder X2 ● Próby ARM PC - Socionext/Gigabyte i Marvell
  4. 4. SBBR ● UEFI 2.5 lub wyżej w implementacji EDK2 ● UEFI uruchomione na EL1/EL2 ● Odpowiedni format plików binarnych - PE/COFF ● Boot services ● Runtime services ● ACPI 6.0 ● SMBIOS 3.0
  5. 5. UEFI (Unified Extensible Firmware Interface) ● Specyfikacja standardu interfejsu między poszczególnymi etapami uruchamiania systemu komputerowego; ● Unified od 2006 roku; ● EDK2 - najbardziej popularna implementacja specyfikacji UEFI. Opublikowana na licencji BSD, mocno wykorzystywana przez współczesnych producentów firmware’u (np. AMI). Dostępna pod adresem https://github.com/tianocore/edk2. ● Od kilku lat aktywny udział ARM
  6. 6. Boot-flow ARMv8 Na podstawie https://www.slideshare.net/linaroorg/lcu14-500-arm-trusted-firmware
  7. 7. UEFI vs U-Boot vs GRUB Copyright © by Semihalf, 2017 UEFI (EDK2) U-Boot GRUB2 Specyfikacja interfejsu bootloadera Bootloader Boot-manager/ Bootloader RuntimeServices brak brak ACPI brak brak SMBIOS brak brak Bootmanager wbudowany/ aplikacje + konsola Bootowanie OS przez konsolę Bootmanager wbudowany Posiada shell Posiada shell Posiada shell Skalowalne (Protokoły + Handle) Skalowalność rozszerzana (DT + frameworki) -
  8. 8. Plan prezentacji ● UEFI - wprowadzenie ● EDK2 Build System - jak zbudować swój firmware? ● UEFI Driver model ● Aplikacje w UEFI ● Interakcje UEFI/OS ● Co z tego wyszło?
  9. 9. Kod platformowy w EDK2 - zależności ● edk2 - wyłącznie kod generyczny (prawie :) ) ● edk2-platforms - właściwy kod platformowy ● edk2-non-osi - kod platformowy niezgodny z licencjami BSD ● Zależności definiowane przy użyciu zmiennych $PACKAGES_PATH i $WORKSPACE
  10. 10. Etapy budowy EDK2 1. AutoGen - parsowanie metadanych w wyniku czego powstają pliki z kodem C oraz pliki Makefile 2. Make - kompilacja kodu źródłowego, stworzenie wynikowych plików PE32/PE32+/COFF 3. ImageGen - przetwarzanie plików wynikowych z poprzedniego etapu w celu stworzenia obrazów UEFI gotowych do wgrania do pamięci flash
  11. 11. Najważniejsze typy plików EDK2 ● .DSC - opis platformy, jej bibliotek i komponentów ● .DEC - deklaracje interfejsów platformy ● .FDF - opis budowy końcowego pliku binarnego ● .INF - definicja modułu
  12. 12. Package Declaration File (.DEC) ● Deklaruje informacje na temat zawartości danej paczki (grupy plików) ● Max jeden plik .DEC per Package ● Od strony praktycznej - pliki .DEC wykorzystywane są przez build system EDK2 do tworzenia plików AutoGen.c oraz AutoGen.h ● Zawiera sekcję [Includes], której wpisy wykorzystywane są do wyszukiwania plików nagłówkowych przez kompilatory ● Przypisanie wartości GUID do obiektów w C
  13. 13. Platform Description File (.DSC) ● Plik opisuje jakie komponenty, moduły i biblioteki zostaną wykorzystane podczas budowy platformy ● Definiuje biblioteki wykorzystane podczas linkowania modułów ● Innymi słowy - zbiór plików INF, które opisują poszczególne moduły ● Inicjalizacja PCD ● Opcjonalnie może zmieniać konfigurację budowy poszczególnych modułów
  14. 14. Flash Description File (.FDF) ● Opisuje, co zawiera binarny plik wyjściowy platformy ● Opisuje layout wyjściowego pliku binarnego platformy ● Ścieżka do tego pliku podawana jest w .DSC
  15. 15. Module Information File (.INF) ● Definicja typu ● Lista plików źródłowych ● Lista wykorzystywanych PCD ● Lista wykorzystywanych protokołów
  16. 16. Platform Configuration Database (PCD) ● Celem jest zastąpienie #define preprocesora ● PCD definiują parametry modułów ● Redukują potrzebę zmian w kodzie - są definiowane w plikach konfigurujących platformę ● Maksymalizacja wykorzystania modułów pomiędzy różnymi platformami ● Udostępnione API, które pozwala dostawać się do wartości PCD w trakcie wykonywania programu ● PCD wykorzystywane są do przechowywania informacji na temat platformy ● Zdefiniowane w .DEC, inicjalizowane wartościami w .DSC, wylistowane w pliku .INF modułu. Podczas dodawania nowych PCD trzeba pamiętać o tym, że wymaga to edycji kilku plików konfigurujących
  17. 17. Plan prezentacji ● UEFI - wprowadzenie ● EDK2 Build System - jak zbudować swój firmware? ● UEFI Driver model ● Aplikacje w UEFI ● Interakcje UEFI/OS ● Co z tego wyszło?
  18. 18. UEFI driver model - założenia Środowisko sterowników w UEFI charakteryzują następujące podstawowe cechy: ● Brak SMP ● Mało współbieżności ● Sterowniki komunikują się z generycznym kodem przez: ○ globalne struktury gBS, gDS, gRS ○ interfejsy (protokoły) ○ eventy ● Identyfikacja “trwałych” elementów przez GUID ● Brak userspace
  19. 19. UEFI driver model – kolejność inicjalizacji Faza wykonywania zdefiniowana przez MODULE_TYPE w pliku INF. Możliwe wartości to m.in.: ● PEIM ● DXE_DRIVER ● UEFI_DRIVER ● UEFI_APPLICATION Kolejność przyłączania sterowników DXE jest zdefiniowana przez wyrażenia DEPEX (w pliku INF danego modułu).
  20. 20. UEFI driver model – producent-konsument Z punktu widzenia piszącego sterownik: ● chcemy skorzystać z jakichś już dostępnych funkcjonalności. ● chcemy udostępnić nowe funkcjonalności UEFI standaryzuje interakcje między sterownikami poprzez protokoły (interfejsy): ● koncepcyjnie – protokół może być produkowany (sterownik udostępnia funkcjonalność) lub konsumowany (korzysta z czyjejś funkcjonalności) ● technicznie – protokół to struktura w C, która zawiera wskaźniki na funkcje + parę skojarzonych definicji
  21. 21. UEFI driver model – handle Handle, czyli “uchwyt” na jakiś obiekt. Koncepcyjnie: ● handle reprezentuje sterownik, urządzenie, plik binarny – jakiś obiekt w modelu ● handle można rozumieć jako kolekcję protokołów skojarzonych ze sobą ● handle są zgromadzone w płaskiej strukturze; hierarchia pomiędzy urządzeniami reprezentowanymi przez handle może być ustalona poprzez protokół DevicePath (ale nie musi) Każdy sterownik ma skojarzony ze sobą Driver Image Handle, na którym instaluje swoje protokoły. Na handle’u może być wiele protokołów – aby powiązać sterownik z urządzeniem, instalujemy na jego uchwycie dodatkowy protokół DevicePath, który ustala hierarchię urządzeń.
  22. 22. UEFI driver model - przykładowa hierarchia Ctrl[30] Edkii Emmc Host Controller Ctrl[83] VenHw(0D51905B-B77E-452A-A2C0-ECA0CC8D514A,000078F20000000000)/eMMC(0x0)/Ctrl(0x0) Ctrl[86] FAT File System Ctrl[87] VenHw(0D51905B-B77E-452A-A2C0-ECA0CC8D514A,000078F20000000000)/eMMC(0x0)/Ctrl(0x0)/HD(2,MBR,0x6882A0AF,0x200800,0x400000) Ctrl[88] VenHw(0D51905B-B77E-452A-A2C0-ECA0CC8D514A,000078F20000000000)/eMMC(0x0)/Ctrl(0x0)/HD(3,MBR,0x6882A0AF,0x600800,0x133800) Ctrl[84] VenHw(0D51905B-B77E-452A-A2C0-ECA0CC8D514A,000078F20000000000)/eMMC(0x0)/Ctrl(0x1) Ctrl[85] VenHw(0D51905B-B77E-452A-A2C0-ECA0CC8D514A,000078F20000000000)/eMMC(0x0)/Ctrl(0x2) Ctrl[32] VenHw(D3987D4B-971A-435F-8CAF-4967EB627241)/Uart(115200,8,N,1) Ctrl[76] Tty Terminal Serial Console Ctrl[6C] Primary Console Input Device Ctrl[6D] Primary Console Output Device Ctrl[6E] Primary Standard Error Device Ctrl[3C] MAC(000000000001,0x1) Ctrl[8A] MNP (MAC=00-00-00-00-00-01, ProtocolType=0x806, VlanId=0) Ctrl[93] PXE Controller Ctrl[8B] MNP (MAC=00-00-00-00-00-01, ProtocolType=0x800, VlanId=0) Ctrl[8D] IPv4 (SrcIP=0.0.0.0) Ctrl[8E] IPv4 (SrcIP=0.0.0.0) Ctrl[90] UDPv4 (SrcPort=68, DestPort=67) Ctrl[94] PXE Controller Ctrl[92] UDPv4 (Not started) Ctrl[98] PXE Controller [...]
  23. 23. UEFI driver model – handle technicznie Handle “pod maską” – wskaźnik na strukturę IHANDLE. Przy tworzeniu nowego uchwytu: ● Inicjalizacja listy Protocols ● Dodanie adresu AllHandles do globalnej listy ● Wypełnienie sygnatury, klucza, instalacja protokołów Wszystkie te operacje wykonują się w generycznym kodzie UEFI. Sterownik po prostu woła odpowiednią funkcję (np. InstallMultipleProtocolInterfaces).
  24. 24. UEFI driver model – device driver Każdy sterownik ma swój entry point – funkcję inicjalizującą jego zasoby, która wywołuje się dokładnie raz. Typowy schemat postępowania: 1. Sterownik w entry point instaluje protokół Driver Binding 2. W trakcie bootowania UEFI dispatcher wywołuje funkcję Supported dla każdego controller handle. Sterownik zwraca, czy ten handle mu odpowiada (np. sprawdza protokoły) 3. Jeśli handle jest dobry, wywoływana jest funkcja Start z dobrym handlem jako parametrem. W funkcji Start driver otwiera niezbędne mu protokoły. 4. Podczas etapu ExitBootServices wywołuje się funkcja Stop
  25. 25. UEFI driver model – bus driver Sterownik magistrali zachowuje się prawie tak samo jak sterownik urządzenia, lecz dodatkowo w funkcji Start() tworzy nowe uchwyty dla dzieci i instaluje na nich protokoły IO. Przykład: sterownik magistrali SPI na każdym uchwycie instaluje protokół SPI IO oraz Device Path, po czym wywołuje ConnectController na danym handle. Przyłączone dzieci korzystają z udostępnionych funkcji. Wyjątek: szyna CPU<->pamięć nie jest w UEFI obsługiwana w ten sposób. Zamiast tego, wszystkie sterowniki mają bezpośredni dostęp do pamięci poprzez MmioRead, MmioWrite bez potrzeby używania protokołów.
  26. 26. UEFI driver model – jak to napisać? Konsumowanie protokołów: ● OpenProtocol ● LocateProtocol ● LocateHandle, LocateHandleBuffer ● LocateDevicePath ● CloseProtocol Produkowanie: ● InstallMultipleProtocolInterfaces ● UninstallMultipleProtocolInterfaces
  27. 27. Plan prezentacji ● UEFI - wprowadzenie ● EDK2 Build System - jak zbudować swój firmware? ● UEFI Driver model ● Aplikacje w UEFI ● Interakcje UEFI/OS ● Co z tego wyszło?
  28. 28. Aplikacje w UEFI – rodzaje obrazów
  29. 29. Aplikacje w UEFI – wstęp Aplikacje kompilowane są do formatu .efi. W tej formie mogą być: ● dostarczone wraz z obrazem firmware (modyfikacja pliku FDF) ● załadowane na jakiś zewnętrzny nośnik, np. HDD, pendrive ● pobrane przez TFTP Pod kątem pisania kodu jest niewiele różnic względem driverów, w tym: ● konstruktory/destruktory zamiast entry point lub Driver Binding Aplikacja ma dostęp do wszystkiego (może instalować, otwierać protokoły, wołać inne funkcje z gBS) – w UEFI nie ma pojęcia userspace.
  30. 30. Aplikacje w UEFI – przykład: EepromCmd Przykład – bardzo prosta aplikacja do obsługi platformowego protokołu EEPROM, skojarzona ze sterownikiem EepromDxe. Użytkownik wywołuje komendę “eeprom” z shella UEFI, podając komendę (read/write) oraz parametry do niej (skąd / dokąd, id urządzenia, bus I2C). Aplikacja: ● Rejestruje komendę do shella w konstruktorze ● Parsuje argumenty przy wywołaniu i na ich podstawie znajduje protokół odpowiedni dla urządzenia ● Korzystając z protokołu, wywołuje żądanie transferu danych EepromCmd Eeprom DXE I2C DXE UEFI Shell MarvellEepromProtocol EfiI2cIoProtocol EfiDriverBindingProtocol
  31. 31. Aplikacje w UEFI – OS loader OS loader jest odpowiedzialny za przekazanie kontroli z firmware do systemu operacyjnego. Po kolei: 1. Ustala swoją lokalizację, ładuje dodatkowe pliki. 2. Ustala gdzie jest OS i zyskuje dostęp do jego obrazu. Może wymagać dostępu do systemów plików niewspieranych przez UEFI. 3. Przekazuje mapę pamięci fizycznej i udostępnia ją do OS przez interfejsy UEFI. Opcjonalnie udostępnia też inne dane. 4. Woła ExitBootServices() – od tego punktu gBS jest niedostępne. 5. Wykonuje skok do kernela.
  32. 32. Bootowanie OS – EFISTUB w detalach Sekwencja bootowania przy pomocy EFISTUB: 1. Od UEFI otrzymuje wskaźniki na EFI_SYSTEM_TABLE 2. Znajduje skojarzony ze sobą Loaded Image Protocol, pobiera swój cmdline. Rozpoznaje adres fizyczny RAMu z System Table. 3. Relokacja 4. Pobiera FDT z FdtConfigurationTable; jeśli nie UEFI nie udostępniło FDT, generowany jest pusty plik. 5. Mapa pamięci (zarezerwowanych regionów) jest przekształcana (na podstawie danych z FDT) i na powrót zapisywana. 6. Wywoływane jest ExitBootServices, po czym następuje aktualizacja mapy wirtualnej pamięci w UEFI poprzez EfiSetVirtualAddressMap.
  33. 33. Plan prezentacji ● UEFI - wprowadzenie ● EDK2 Build System - jak zbudować swój firmware? ● UEFI Driver model ● Aplikacje w UEFI ● Interakcje UEFI/OS ● Co z tego wyszło?
  34. 34. Pomiędzy UEFI a OS – EFI_SYSTEM_TABLE FDT RSDP SMBIOS
  35. 35. EFI Configuration Tables Polimorficzna struktura – w zależności od GUID wskaźnik jest rzutowany na ustalony typ, na przykład: ● DTB ● Zmienne środowiskowe ● Tablice SMBIOS ● Root System Descriptor (ACPI)
  36. 36. EFI Runtime Services Struktura wskaźników na funkcje implementowane przez UEFI, dostępne w czasie działania systemu operacyjnego. ● Aktualizacja secure firmware przez OS ● Ustawianie zmiennych środowiskowych ● Zyskanie dostępu do informacji niezależnych od OS Sterowniki w UEFI, które implementują Runtime Services muszą korzystać z odpowiedniej pamięci, która nie zniknie po EfiBootServices.
  37. 37. Opis sprzętu - podejście embedded (Flattened) Device Tree to drzewiasta struktura, która ma za zadanie przekazać informacje o platformie do OS. Zawiera wyłącznie statyczny opis platformy, w tym informacje o: ● zasobach ● zależnościach między urządzeniami Pliki .dts (Device Tree Source) są kompilowane do postaci .dtb (Device Tree Blob). Mogą być dołączone do obrazu firmware. Opcjonalnie, zanim DTB trafi do systemu operacyjnego, jest modyfikowane przez FW.
  38. 38. Opis sprzętu - podejście serwerowe/PC ACPI (Advanced Configuration and Power Interface) to technologia znana głównie z komputerów klasy PC (pierwotnie wywodzi się z APM, stworzonego przez Intel/Microsoft). Coraz częściej jest implementowana na platformach ARM (zwłaszcza AARCH64), głównie ze względu na: ● Dojrzałą specyfikację (rozwijana od 1996) ● Szereg zalet nad FDT, w tym możliwość definiowania metod w kodzie ASL (który jest następnie interpretowany przez OS np. jako handlery przerwań, ) ● Chęć ujednolicenia rozwiązań stosowanych w centrach danych (gdzie stopniowo są także wprowadzane platformy ARM) Rolą firmware jest przygotowanie i opublikowanie tablic ACPI w pamięci, za ich interpretację odpowiedzialny jest OS.
  39. 39. Plan prezentacji ● UEFI - wprowadzenie ● EDK2 Build System - jak zbudować swój firmware? ● UEFI Driver model ● Aplikacje w UEFI ● Interakcje UEFI/OS ● Co z tego wyszło?
  40. 40. Marvell MacchiatoBin
  41. 41. Wsparcie platformowe dla rodziny Armada 7k/8k ● Od 0 do pełnej zgodności z SBBR ● Wyzwania platformowe (sieć, SD/MMC i wiele innych) ● Własne generyczne rozwiązania wokół stosów I2C i SPI ● Aplikacje shellowe ● Kod produkcyjny i prawie w całości już w edk2-platforms ● Duża łatwość dodawania nowych platform ● Działają najnowsze distro (Centos, RHEL, Fedora, SLES)
  42. 42. Koniec Pytania ?

×