Wymagania interfejsu UEFI dotyczące wersji systemu Windows na platformach SoC

W tym artykule opisano wymagania UEFI dotyczące systemu Windows 10 dla wersji klasycznych (Home, Pro, Enterprise i Education).

Podsumowanie wymagań

W poniższej tabeli wymieniono wszystkie bieżące wymagania dotyczące zgodności interfejsu UEFI zgodnie ze specyfikacją UEFI (sekcja 2.6 specyfikacji UEFI 2.3.1). W tej tabeli termin Jawne wymaganie systemu Windows identyfikuje dowolny protokół lub usługę, która jest wywoływana bezpośrednio przez składnik systemu Windows. Chociaż tylko te usługi są jawnie używane przez system Windows, inne wymienione usługi i protokoły mogą być niejawnie lub jawnie wymagane przez podstawową implementację oprogramowania układowego, sterowniki urządzeń EFI lub łańcuchy narzędzi programistycznych i wdrożeniowych.

Firma Microsoft z zadowoleniem przyjmuje opinie i komentarze od implementujących ten zestaw wymagań. W przypadku wszelkich wymagań zgodności interfejsu UEFI, które nie są wymagane przez system operacyjny lub oprogramowanie układowe, naszym zamiarem jest wykonanie pracy przez UEFI.org, aby te wymagania zgodności zostały złagodzone dla tej klasy urządzeń.

Aby uzyskać więcej informacji na temat konkretnych wymagań, zobacz sekcje po tabeli.

Wymaganie	Sekcja specyfikacji UEFI	Notatki
tabela systemu EFI	4.3	Jawne wymaganie systemu Windows
usług rozruchowych EFI	6.0
Usługi zdarzeń, czasomierza i zadań	6.1
Usługi pamięci	6.2	Jawne wymaganie systemu Windows
Usługi obsługi protokołów	6.3	Jawne wymaganie systemu Windows
Usługi obrazów	6.4	Jawne wymaganie systemu Windows
Różne usługi	6.5	Jawne wymaganie systemu Windows
usług środowiska uruchomieniowego EFI	7.0
Usługi dotyczące zarządzania czasem	7.3	Jawne wymaganie systemu Windows
Zmienne usługi	7.2	Jawne wymaganie systemu Windows
Różne usługi	7.5	Jawne wymaganie systemu Windows
wymagane protokoły UEFI
Protokół EFI dotyczący załadowanych obrazów	8.1
Protokół ścieżki urządzenia z załadowanym obrazem EFI	8.2
Protokół ścieżki urządzenia EFI	9.2	Jawne wymaganie systemu Windows
Protokół narzędzi dla ścieżek urządzeń EFI	9.5
Protokół dekompresu EFI	18,5
Protokół interpretera EBC	20.11
warunkowo wymagane protokoły UEFI
Prosty protokół wprowadzania tekstu EFI	11.3	Jawne wymaganie systemu Windows
Protokół EFI prostego wprowadzania tekstu EX	11.2
Prosty protokół wyjściowy tekstowy EFI	11.4
Protokół wyjściowy grafiki EFI	11.9	Jawne wymaganie systemu Windows
Odnaleziony protokół EFI EDID	11.9.1
Aktywny protokół EFI EDID	11.9.1
Protokół we/wy bloku EFI	12.8	Jawne wymaganie systemu Windows
Protokół we/wy dysku EFI	12.7
Prosty protokół systemu plików EFI	12.4
Protokół sortowania EFI Unicode	12.10
Prosty protokół sieciowy EFI	21.1
Podstawowy protokół kodu EFI PXE	21.3
Protokół usług integralności rozruchu EFI	21.5
Protokół we/wy szeregowego interfejsu EFI	11.8
Powiązanie UEFI Arm	2.3.5	Jawne wymaganie systemu Windows
wymagania dotyczące zabezpieczeń
Bezpieczny rozruch	27.0	Jawne wymaganie systemu Windows
Wymagania dotyczące menedżera rozruchu	3.1, 3.3	Jawne wymaganie systemu Windows

Wymagania dotyczące tabeli systemowej EFI

Tabela systemowa EFI musi być zgodna ze standardową definicją na poziomie wersji zaimplementowanej. Tabela konfiguracji wskazywana przez tabelę systemu EFI musi zawierać dwa identyfikatory GUID i skojarzone ze nimi wskaźniki opisane w poniższej tabeli.

GUID	Opis
Tabela GUID EFI_ACPI	Ten identyfikator GUID powinien wskazywać na wskaźnik opisu głównego systemu ACPI (RSDP) dla platformy.
SMBIOS_Table GUID	Ten GUID musi wskazywać na strukturę punktu wejścia SMBIOS. System Windows wymaga specyfikacji SMBIOS na poziomie wersji 2.4 lub nowszej. Sekcje 3.2, "Wymagane struktury i dane" oraz 4, "Wytyczne dotyczące zgodności", są wymagane. Dostępny jest test zgodności systemu Windows SMBIOS.

Wymagania dotyczące usług rozruchowych EFI

W poniższej tabeli wymieniono wymagania dotyczące usług rozruchowych EFI dla systemu Windows.

Usługa rozruchu EFI	Wymaganie
Usługi pamięci	System Windows wymaga wszystkich usług pamięci.
Usługi obsługi protokołów	System Windows wymaga następujących usług obsługi protokołów: OpenProtocol() CloseProtocol() LocateDevicePath() LocateHandle()
Usługi obrazów	System Windows wymaga następujących usług obrazu: ExitBootServices()
Rozmaite usługi rozruchowe	System Windows wymaga następujących różnych usług rozruchowych: Stall() Uwaga: implementacja Stall() musi mieć deterministyczny (powtarzalny) błąd, aby można było niezawodnie poprawić lub anulować błąd.

Wymagania dotyczące usług środowiska uruchomieniowego EFI

W poniższej tabeli wymieniono wymagania dotyczące usług środowiska uruchomieniowego EFI dla systemu Windows.

Usługa środowiska uruchomieniowego EFI	Wymaganie
Usługi związane z czasem	System Windows wymaga następujących usług czasowych: GetTime() SetTime() Uwaga: Usługi czasu będą wywoływane tylko podczas rozruchu (przed ExitBootServices()) na potrzeby uzyskiwania dostępu do sprzętu platformy odczytującego czas dnia.
Usługi zmienne	Wszystkie usługi zmiennych UEFI są wymagane do zarządzania wieloma urządzeniami rozruchowymi i zmiennymi zabezpieczeń w docelowej klasie systemów.
Różne usługi środowiska uruchomieniowego	System Windows wymaga następujących różnych usług środowiska uruchomieniowego: ResetSystem() Uwaga: implementacja ResetSystem() musi obsługiwać zarówno opcje resetowania, jak i zamykania.

Wymagania dotyczące protokołu

W poniższej tabeli opisano protokoły UEFI wymagane przez system Windows do wykonywania określonych funkcji podczas rozruchu.

Protokół	Wymaganie
Protokół wyjściowy grafiki	System Windows wymaga protokołu GRAPHICS Output Protocol (GOP). Wymagania dotyczące buforu ramki są następujące: W przypadku zintegrowanych wyświetlaczy HorizontalResolution i VerticalResolution musi być natywną rozdzielczością panelu. W przypadku wyświetlaczy zewnętrznych HorizontalResolution i VerticalResolution muszą być natywną rozdzielczością wyświetlacza lub, jeśli nie jest to obsługiwane, najwyższymi wartościami obsługiwanymi zarówno przez kartę graficzną, jak i połączony ekran. PixelsPerScanLine musi być równe HorizontalResolution. PixelFormat musi być PixelBlueGreenRedReserved8BitPerColor. Wymagany jest fizyczny bufor ramki; PixelBltOnly nie jest obsługiwana. Gdy przekazywane jest wykonanie do aplikacji startowej UEFI, menedżer rozruchu oprogramowania układowego i oprogramowanie układowe nie mogą używać buforu ramki w żadnym celu. Bufor ramki musi być nadal skanowany po zakończeniu usług rozruchowych.
Alternatywne źródło wyświetlania	Oprogramowanie układowe UEFI musi obsługiwać rozruch przy użyciu dowolnego łącznika wyświetlania obsługiwanego przez sprzęt. Jeśli panel wewnętrzny jest połączony i widoczny, należy użyć panelu wewnętrznego. Wszystkie wyjścia, które mają fizycznie połączone ekrany, muszą wyświetlać ekran rozruchowy. W przypadku podłączonych wyświetlaczy oprogramowanie układowe UEFI musi: Zainicjuj dane wyjściowe za pomocą trybu natywnego wyświetlania, jeśli można określić rozdzielczość natywną. Jeśli tryb natywny nie jest możliwy, należy zainicjować tryb najwyższej zgodności. Jeśli nie można określić możliwości wyświetlania, podłączony wyświetlacz musi zostać zainicjowany w trybie, który jest znany jako zgodny z dowolną liczbą monitorów (zazwyczaj 640x480 lub 1024x768, przy 60 Hz).
Dane wejściowe w czasie rozruchu	Protokół EFI Simple Text Input Protocol jest wymagany do wyboru rozruchu lub innych opcji menu w systemach z wbudowanymi klawiaturami lub dołączonymi klawiaturami. W przypadku systemów bez klawiatury w środowisku rozruchowym zalecane są trzy przyciski: Przycisk Start Przycisk zwiększania głośności Przycisk zmniejszania głośności Naciśnięcia przycisków należy zgłaszać za pośrednictwem protokołu EFI Simple Text Input Protocol, mapując je odpowiednio na następujące klawiatury: Klucz systemu Windows Strzałka w górę Strzałka w dół
Uruchamianie pamięci lokalnej	System Windows wymaga obsługi protokołu we/wy blokowego oraz protokołu ścieżki urządzeń dla rozwiązania magazynowania zawierającego partycję systemową EFI i partycję systemu operacyjnego Windows. W przypadku rozruchu z magazynu flash, który wymaga bilansowania zużycia lub innego zarządzania flash, należy to zaimplementować w oprogramowaniu układowym (nie w aplikacji UEFI).

Wymagania dotyczące zabezpieczeń

System Windows ma wymagania dotyczące zabezpieczeń w obszarach bezpiecznego rozruchu, mierzonego rozruchu, kryptografii i ochrony danych. Te wymagania zostały szczegółowo opisane w poniższej tabeli. Ponadto w przypadku tych obszarów, w których sprzęt SoC zapobiega zgodności z istniejącym standardem (TPM, RTC itp.), opracowywane są dodatkowe wymagania. Są one opisane na końcu tabeli.

Obszar	Wymaganie
Ogólne	Wymaganie 1: OBOWIĄZKOWE. Platforma jest zgodna ze wszystkimi wymaganiami określonymi w tej sekcji. Wymaganie 2: OBOWIĄZKOWE. Platformy powinny być klasy UEFI Trzy bez zainstalowanego ani możliwego do zainstalowania Modułu Wsparcia Zgodności. Emulacja systemu BIOS i rozruch w trybie Legacy PC/AT muszą być wyłączone.
Bezpieczny rozruch UEFI	Wymaganie 3: OBOWIĄZKOWE. Bezpieczny rozruch zgodnie z definicją w UEFI v2.3.1 sekcji 27 musi być dostarczany w stanie włączonym i z bazą danych sygnatur (EFI_IMAGE_SECURITY_DATABASE) niezbędną do bezpiecznego rozruchu maszyny wstępnie przygotowaną. Początkowa zawartość bazy danych sygnatur jest określana przez producenta OEM na podstawie wymaganych sterowników UEFI innych firm, potrzeb odzyskiwania oraz programu rozruchowego systemu operacyjnego zainstalowanego na maszynie, ale musi być dołączony podpis EFI_CERT_X509 dostarczony przez Microsoft. Nie ma żadnych dodatkowych podpisów. Wymaganie 4: OBOWIĄZKOWE. Wymagana jest obecność bazy danych sygnatur UEFI "zabronione" (EFI_IMAGE_SECURITY_DATABASE1). Wymaganie 5: OBOWIĄZKOWE. Dostarczony przez firmę Microsoft klucz UEFI KEK musi być uwzględniony w bazie danych KEK UEFI. Nie powinno być żadnych dodatkowych KEK. Firma Microsoft udostępnia klucz KEK w postaci podpisu EFI_CERT_X509. Wymaganie 6: OBOWIĄZKOWE. Klucz PKpub powinien być obecny i przechowywany w pamięci flash oprogramowania układowego. Uwaga: Ponieważ PKpriv (odpowiednik klucza prywatnego dla PKpub) kontroluje zasady bezpiecznego rozruchu na wszystkich urządzeniach zaopatrzonych w PKpub, jego ochrona i użycie muszą być ściśle nadzorowane. Wymaganie 7: OBOWIĄZKOWE. Początkowe bazy danych podpisów są przechowywane w pamięci flash oprogramowania układowego i mogą być aktualizowane tylko za pomocą aktualizacji oprogramowania układowego podpisanego przez producenta OEM lub za pomocą uwierzytelnionego zapisu zmiennej UEFI. Wymaganie 8: OBOWIĄZKOWE. Obrazy w ścieżce rozruchowej, które nie przechodzą weryfikacji podpisu, nie mogą być wykonywane, a przyczyna tego niepowodzenia zostanie dodana do EFI_IMAGE_EXECUTION_TABLE. Ponadto zalecane podejście w tych sytuacjach polega na tym, że menedżer rozruchu UEFI inicjuje odzyskiwanie zgodnie ze strategią specyficzną dla producenta OEM. Wymaganie 9: OBOWIĄZKOWE. Fizyczne przejęcie kontroli przez użytkownika nie może być dozwolone dla obrazów UEFI, które nie przeszły weryfikacji podpisu. Wymaganie 10: opcjonalne. OEM może zaimplementować zdolność do wyłączenia Bezpiecznego Rozruchu przez fizycznie obecnego użytkownika, zarówno poprzez dostęp do PKpriv, jak i poprzez fizyczną obecność w konfiguracji oprogramowania układowego. Dostęp do konfiguracji oprogramowania układowego może być chroniony za pomocą określonych platform (hasło administratora, karta inteligentna, konfiguracja statyczna itp.) Wymaganie 11: OBOWIĄZKOWE, jeśli jest zaimplementowany wymóg 10. Jeśli bezpieczny rozruch jest wyłączony, wszystkie istniejące zmienne UEFI nie będą dostępne. Wymaganie 12: OPCJONALNE. OEM może zaimplementować możliwość wyboru przez fizycznie obecnego użytkownika między dwoma trybami bezpiecznego rozruchu w ustawieniach oprogramowania układowego: "Niestandardowy" i "Standardowy". Tryb niestandardowy umożliwia większą elastyczność zgodnie z poniższymi instrukcjami. Wymaganie 13: OBOWIĄZKOWE, jeśli zaimplementowano wymaganie 12. Ponowne włączenie wyłączonego bezpiecznego rozruchu w trybie niestandardowym jest możliwe po ustawieniu określonego przez właściciela PK. Administracja jest kontynuowana zgodnie z definicją w sekcji 27.5 specyfikacji UEFI v2.3.1: Wymiana kluczy oprogramowania układowego/systemu operacyjnego. W trybie niestandardowym właściciel urządzenia może ustawić wybór podpisów w bazach danych podpisów. Wymaganie 14: OBOWIĄZKOWE, jeśli zaimplementowano wymaganie 12. Konfiguracja oprogramowania układowego wskazuje, czy bezpieczny rozruch jest włączony i czy jest obsługiwany w trybie standardowym lub niestandardowym. Konfiguracja oprogramowania układowego zapewnia możliwość powrotu z trybu niestandardowego do standardowego. Wymaganie 15: OBOWIĄZKOWE. Jeśli ustawienia oprogramowania układowego zostaną zresetowane do domyślnych ustawień fabrycznych, wszystkie zmienne chronione ustawione przez użytkownika zostaną wymazane, a oryginalne PK zostaną przywrócone wraz z oryginalnymi bazami danych sygnatur dostarczonymi przez producenta. Wymaganie 16: OBOWIĄZKOWE. Podpisywanie sterowników korzysta z opcji Authenticode (WIN_CERT_TYPE_PKCS_SIGNED_DATA). Wymaganie 17: OBOWIĄZKOWE. Obsługa EFI_IMAGE_EXECUTION_INFO_TABLE (czyli tworzenia i przechowywania informacji o obrazach uruchomionych lub nie uruchamianych podczas rozruchu). Wymaganie 18: OBOWIĄZKOWE. Obsługa metody GetVariable() dla EFI_IMAGE_SECURITY_DATABASE (zarówno autoryzowanej, jak i zabronionej bazy danych sygnatur). Wymaganie 19: OBOWIĄZKOWE. Obsługa setVariable() dla EFI_IMAGE_SECURITY_DATABASE (zarówno autoryzowanej, jak i zabronionej bazy danych podpisów) przy użyciu klucza KEK firmy Microsoft do uwierzytelniania. Wymaganie 20: OBOWIĄZKOWE. EFI_HASH_SERVICE_BINDING_PROTOCOL: Obsługa usługi: CreateChild(), DestroyChild(). Wymaganie 21: OBOWIĄZKOWE. EFI_HASH_PROTOCOL. Obsługa usługi: Hash(). Obsługa algorytmów wyznaczania skrótów SHA_1 i SHA-256. Musi obsługiwać przekazywanie komunikatu o długości co najmniej 10 Mb/s.
Mierzony rozruch UEFI	Poniższe wymagania nie oznaczają potrzeby implementacji modułu TPM TCG; oznaczają one jednak potrzebę równoważności funkcji dla obszarów, których dotyczy problem. Obsługa platformy może być zapewniana przez implementację sprzętową oprogramowania układowego modułu TPM działającego w bezpiecznym środowisku wykonywania, opartą na silniku przyspieszania kryptograficznego i korzystającą z izolowanej pamięci. Firma Microsoft może być w stanie udostępnić oprogramowanie referencyjne dla takiej implementacji modułu TPM do użytku przez dostawcę. Jest to przedmiotem dalszych dyskusji. Wymaganie 22: OBOWIĄZKOWE. Platforma będzie zgodna z protokołem EFI określonym w UEFI Trusted Execution Environment EFI Protocol. Wymaganie 23: OBOWIĄZKOWE. Platforma jest zgodna ze specyfikacją platformy EFI TCG z następującymi dodatkami: Na platformach obsługujących interfejs zdefiniowany w protokole TrEE EFI skrót PKpub powinien zostać rozszerzony na TPM PCR[03] jako zdarzenie EV_EFI_VARIABLE_CONFIG. Skrót zawartości autoryzowanej bazy danych sygnatur (patrz sekcja 27.8 specyfikacji UEFI w wersji 2.3.1) musi zostać rozszerzony podczas mierzonego rozruchu jako zdarzenie EV_EFI_VARIABLE_CONFIG. Operacja rozszerzania będzie dotyczyć PCR[03] modułu TPM. Klient UEFI może odczytywać i analizować listę certyfikatów przy użyciu zmiennej EFI_IMAGE_SECURITY_DATABASE i weryfikować skrót względem rozszerzonej wartości. Wartości skrótu TCG_PCR_EVENT powinny być SHA-256, a nie SHA-1. Wymaganie 24: OBOWIĄZKOWE. Platforma musi zaimplementować kontrolkę MemoryOverwriteRequestControl zdefiniowaną w specyfikacji TCG Platform Reset Attack Mitigation .
Kryptografia	Wymaganie 25: OBOWIĄZKOWE. Platforma udostępnia EFI_HASH_PROTOCOL (UEFI v2.3.1 Sekcja 27.4) na potrzeby odciążania operacji skrótu kryptograficznego. Algorytm SHA-256 musi być obsługiwany. Wymaganie 26: OBOWIĄZKOWE. Platforma powinna obsługiwać zdefiniowany przez firmę Microsoft EFI_RNG_PROTOCOL dla odczytu entropii przed systemem operacyjnym.
Ochrona danych	Wymaganie 27: OBOWIĄZKOWE. Platforma musi obsługiwać zmienne EFI z dowolną kombinacją następujących atrybutów zmiennych UEFI ustawionych: EFI_VARIABLE_BOOTSERVICE_ACCESS EFI_VARIABLE_NON_VOLATILE EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS
Inne wymagania dotyczące zabezpieczeń	Następujące dodatkowe wymagania są wymagane przez system Windows na platformach SoC. Firma Microsoft zdefiniowała protokół zbierania entropii z platformy UEFI. Chociaż nie jest to wymaganie UEFI, ten protokół jest wymagany przez system Windows na platformach SoC. Aby uzyskać więcej informacji na temat tego protokołu, zobacz protokół zbierania entropii UEFI . Aktualizacje bazy danych sygnatur UEFI. Nowy mechanizm aktualizowania uwierzytelnionych zmiennych został przyjęty w sekcji 27 interfejsu UEFI 2.3.1. Ten mechanizm jest wymagany przez system Windows. Zaufane środowisko wykonywania. Firma Microsoft opracowała protokół EFI do interakcji z zaufanym środowiskiem wykonawczym (TrEE), którego funkcjonalność jest podobna do części sprzętu Trusted Platform Module (TPM) grupy TCG (Trusted Computing Group). Protokół EFI w dużym stopniu wykorzystuje "TCG EFI Protocol", wersja 1.2 Poprawka 1.00, z 9 czerwca 2006 r. od Trusted Computing Group. Aby uzyskać szczegółowe informacje, zapoznaj się z protokołem EFI Środowiska Zaufanej Egzekucji UEFI.

Wymagania dotyczące menedżera rozruchu oprogramowania układowego

Menedżer rozruchu oprogramowania układowego musi obsługiwać domyślne zachowanie rozruchu zdefiniowane w sekcji 3.3 specyfikacji. Ponadto, do obsługi wielo-rozruchu wymagane są globalnie zdefiniowane zmienne oraz zgodność z wymaganiami menedżera rozruchu określonymi w sekcji 3.1 specyfikacji.

Wymagania dotyczące powiązania UEFI ARM

UEFI Arm Binding zawiera wymagania specyficzne dla platformy Arm, które są potrzebne, aby zapewnić zgodność ze specyfikacją UEFI. System Windows wymaga wszystkiego w powiązaniu arm, które ma zastosowanie do architektury ARMv7. Ponieważ system Windows nie obsługuje żadnych elementów wcześniejszych niż ARMv7, wymagania w powiązaniu, które są specyficzne dla arMv6k i poniżej, są opcjonalne.

Powiązanie określa na przykład sposób konfigurowania jednostki MMU oraz sposób mapowanie pamięci fizycznej. Powiązanie określa również, że wywołania wykonywane do protokołów i usług UEFI powinny być wykonywane tylko w ARM ISA, co oznacza, że oprogramowanie działające w Thumb2 lub Thumb będzie musiało przełączyć się z powrotem do trybu ARM przed wywołaniem funkcji UEFI.

Wymagania dotyczące uruchamiania wieloprocesorowego interfejsu UEFI Arm

Firma Microsoft opracowała protokół uruchamiania wielu rdzeni arm na platformie UEFI z wieloma procesorami. Ten protokół jest wymagany przez system Windows na platformach Arm, które nie obsługują Power State Coordination Interface (PSCI). Platformy, które obsługują interfejs PSCI, nie mogą używać tego protokołu. Aby uzyskać więcej informacji na temat tego protokołu, zobacz dokument Uruchamianie wieloprocesorowe na platformach opartych na UEFI Arm na stronie internetowej Architektury składników ACPI (ACPICA).

Wymagania dotyczące konfiguracji platformy

Oprogramowanie układowe jest odpowiedzialne za umieszczenie sprzętu systemu w dobrze zdefiniowanym stanie przed przekazaniem go do modułu ładującego systemu operacyjnego. W poniższej tabeli zdefiniowano powiązane wymagania dotyczące konfiguracji platformy.

Wymaganie	Opis
Ścieżka rozruchu	Oprogramowanie układowe musi zainicjować platformę do punktu, w którym system Windows może uzyskać dostęp do urządzenia rozruchowego za pośrednictwem interfejsu UEFI i załadować jądro. Każde urządzenie zaangażowane w hierarchię do odczytu z urządzenia rozruchowego musi być taktowane i zasilane w rozsądnym tempie, biorąc pod uwagę wydajność i moc. Podstawowy rdzeń procesora powinien być również taktowany i zasilany w rozsądnym tempie, aby system mógł uruchomić się w odpowiednim czasie bez opróżniania baterii.
Podstawowe zasoby systemowe	Podstawowe zasoby systemowe uwidocznione w systemie operacyjnym za pośrednictwem tabel ACPI muszą być włączone i taktowane. Podstawowe zasoby systemowe obejmują kontrolery przerwań, czasomierze i kontrolery DMA, które muszą być zarządzane przez system operacyjny. Ponadto przerwania muszą być maskowane przez wywołanie metody ExitBootServices(), dopóki skojarzony sterownik urządzenia w systemie operacyjnym nie zdemaskuje i ponownie włączy przerwania na urządzeniu. Jeśli przerwy są włączone podczas usług rozruchowych, zakłada się, że oprogramowanie układowe zarządza nimi.
Debugowanie	System Windows obsługuje debugowanie za pośrednictwem interfejsów USB 3 Host (XHCI), USB 2 Host (EHCI)1, IEEE 1394, interfejsów szeregowych i funkcji USB (a także kart PCI Ethernet). Co najmniej jeden z nich musi być zasilany, taktowany i inicjowany przez oprogramowanie układowe przed przekazaniem systemu operacyjnego. Niezależnie od tego, która opcja jest dostarczona, musi mieć uwidoczniony port do celów debugowania, a kontroler musi być mapowany na pamięć lub być podłączony za pośrednictwem dedykowanej (niewspółdzielonej) magistrali peryferyjnej.
Inne wymagania dotyczące konfiguracji platformy	Przed przekazaniem kontroli modułowi ładującemu systemu operacyjnego należy ukończyć konfigurację multipleksowania pinów i padów w oprogramowaniu układowym.

Wymagania dotyczące instalacji

System Windows wymaga, aby partycja systemu operacyjnego znajdowała się w rozwiązaniu magazynu partycjonowanego GPT. Magazyn podzielony na partycje MBR może być używany jako magazyn danych. Zgodnie ze specyfikacją UEFI platforma UEFI wymaga dedykowanej partycji systemowej. System Windows wymaga tej dedykowanej partycji systemowej nazywanej partycją systemową EFI (ESP).

Wymaganie sprzętowego interfejsu testowego zabezpieczeń (HSTI)

Platforma musi zaimplementować sprzętowy interfejs testowania zabezpieczeń, a platforma ma obowiązek udostępniania dokumentacji i narzędzi zgodnie z specyfikacją testowania zabezpieczeń sprzętu.

Powiązane artykuły

minimalne wymagania UEFI dla systemu Windows na platformach SoC

wymagania UEFI dotyczące wsparcia dla flashowania USB