Ghid pentru verificarea cererilor suplimentare uefi - windows 10 hardware dev

ROM-urile suplimentare sunt software-uri încorporate care sunt lansate de BIOS-ul computerului în timpul inițializării platformei. Acestea sunt de obicei stocate pe cardul introdus, deși acestea pot fi, de asemenea, pe placa de sistem.

O singură interfață EFI (UEFI) suportă modul depășit al ROM-urilor suplimentare.

Conform celei mai recente specificații UEFI (actualmente 2.3.1 modificată de C - secțiunea 2.5.1.2), ROM-urile suplimentare ISA (tip mostenit) nu fac parte din specificațiile UEFI. În această discuție vor fi luate în considerare numai ROM-uri suplimentare compatibile cu UEF bazate pe PCI.

Este posibilă utilizarea altor ROM-uri atunci când nu este posibilă încorporarea firmware-ului dispozitivului în firmware-ul calculatorului. Dacă un ROM suplimentar utilizează un driver, furnizorii independenți de hardware pot folosi de asemenea acest driver și pot stoca driverul și dispozitivul în aceeași locație.

Acest document explică de ce trebuie să verificați alte ROM-uri și descrie unele metode pentru efectuarea testului.

Sprijină atât BIOS UEFI, cât și BIOS din versiunile anterioare

Mulți producători creează dispozitive care includ ROMuri suplimentare și firmware pentru multe tipuri de computere. Principalele combinații includ următoarele.

Numai învechit ROM

ROM ROM UEFI suplimentar propriu

ROM obișnuit + EBC suplimentar ROM UEFI

Memorare învechită ROM + suplimentare pe 64 de biți UEFI

Vechiul ROM UEFI + UEFI IA32 pe 64 de biți

Vechiul ROM + UEFI + UEFI IA32 pe 64 de biți + EBC UEFI suplimentar ROM

BIOS-ul UEFI poate descărca și rula driverele tradiționale de firmware dacă este activat modulul de suport compatibil (CSM). Rețineți că dacă este activată descărcarea sigură, modulul de compatibilitate compatibilitate și ROM-urile vechi sunt dezactivate, deoarece driverele tradiționale pentru firmware nu acceptă autentificarea. Dacă formatul de opțiune ROM din configurația BIOS este configurat pentru ROM învechit, atunci dispozitivul va folosi întotdeauna ROM-ul tradițional.

Dacă opțiunea ROM este instalată ca compatibilă cu UEFI. va folosi un nou EFI ROM dacă este disponibil sau o ROM veche în absența unei noi.

Driverele UEFI sunt necesare pentru multe dintre componentele de securitate ale noului firmware și pentru a permite secvența de boot UEFI. De exemplu, instalarea Windows de pe o unitate optică atașată la un controler de stocare incompatibil cu UEFI nu este posibilă dacă sistemul este pornit în modul UEFI cu boot securizat activat.

1. UEFI și ROM-uri suplimentare

Ghid pentru verificarea cererilor suplimentare uefi - windows 10 hardware dev

Figura 2. Siguranța driverelor UEFI (sursa: UEFI 2.3.1 cu corecția C)

Din secțiunea 31.1.4 la 2.3.1 modificată de C UEFI:

Deoarece profilul utilizatorului UEFI conține o serie de beneficii legate de securitate, este important ca licențele de utilizare a regulatorului și furnizorii de acreditări de utilizator, precum și mediul în care acestea sunt realizate, sunt de încredere.

Aceasta include următoarele.

Protecția zonei de depozitare pentru șoferi.

Protecția instrumentelor de selecție a șoferului.

Protejați mediul de rulare al acestor drivere de la drivere neconfirmate.

Componentele, cum ar fi managerul de identitate, driverele de acreditare utilizator și driverele încorporate, pot fi amplasate într-o locație sigură, cum ar fi un dispozitiv de memorie flash protejat la scriere care are încredere în politica de platformă.

Unele alte drivere se pot afla în locații de stocare neprotejate, cum ar fi ROM-uri suplimentare sau partiții de disc, și pot fi ușor înlocuite. Asemenea drivere trebuie să fie verificate.

De exemplu, sau o platformă politică care este utilizată în mod implicit, ar trebui să fie în măsură să verifice cu succes driverele enumerate în parametrii driver Driver #### de descărcare, sau trebuie să verifice utilizatorului înainte de a va procesa aceste drivere. În caz contrar, executarea șoferului ar trebui să fie întârziată. Dacă profilul utilizatorului este modificat printr-un apel ulterior al comenzii de autentificare sau prin utilizarea autentificării dinamice, este posibil ca driverul #### să nu mai fie procesat din nou.

Baza de date a profilului de utilizator este închisă utilizând diverse evenimente ale semnalului UEFI bazate pe posibilitatea de a fi protejată.

UEFI și driverele UEFI ROM suplimentare rulează numai pentru dispozitivele din calea de boot.

Specificația PCI permite folosirea mai multor imagini ale ROM-urilor suplimentare pe un singur dispozitiv. Aceste ROM-uri suplimentare pot fi învechite pe 86 de biți și pe UEFI. Firmware-ul UEFI instalează o politică de platformă pentru selectarea ROM-urilor suplimentare. Din acest motiv, ROM-ul suplimentar al adaptorului poate fi executat ca un dispozitiv propriu de control.

Firmware-ul verifică semnăturile pe etapele BDS și DXE. Secvența evenimentelor este după cum urmează.

Inițierea PCI și diferențierea busului

Eșantion de dispozitiv PCI pentru ROM-urile opționale

Comparație între ROM-urile găsite în memorie

Etapa DXE: încărcarea driverelor UEFI în ROM

UEFI ROM-urile suplimentare pot fi localizate oriunde în memorie. Setarea implicită permite ROM-ului de pe placă să controleze dispozitivul. UEFI permite platformei să gestioneze politica cu privire la ce ROM suplimentar va gestiona un anumit dispozitiv utilizând EFI_PLATFORM_DRIVER_OVERRIDE. UEFI acceptă înregistrarea configurației interfeței cu ROM-uri suplimentare.

Pe un PC unde este activată boot-ul securizat, driverele ROM suplimentare prezintă un risc de securitate dacă nu au o semnătură sau nu au fost testate. Verificarea semnăturii pentru ROM-urile suplimentare este o cerință WHCK. Același lucru este valabil și atunci când deserviți alte ROM-uri, când trebuie să vă asigurați că actualizarea a fost verificată înainte de instalare.

Din specificația UEFI 2.3.1 Eratta C:

2. Descrierea problemei

Anumite ansamblul UEFI BIOS cu suport pentru pornire sigure, inclusiv Tiano Core, implicit nu autentifică opțiunea ROM UEFI, ca opțiune de ROM-uri UEFI semnate nu au fost disponibile în timpul dezvoltării sigure de boot. Aceasta reprezintă vectorii de atac posibili și vulnerabilitatea unei descărcări UEFI sigure.

2.1. vulnerabilitate

Codul sursă pentru vulnerabilitatea TianoCore este fișierul SecurityPkg \ SecurityPkg.dec:

Suprascrierea PCD trebuie plasată în secțiunea [PcdsFixedAtBuild] din fișierul DSC. Mecanismul exact de suprimare a setărilor poate varia în funcție de furnizorul BIOS.

Această vulnerabilitate poate exista în implementările anterioare ale descărcării în siguranță a UEFI în BIOS de la furnizori BIOS independenți. Contactați furnizorul BIOS pentru a afla dacă versiunea dvs. BIOS poate fi vulnerabilă.

3. În ce privește această preocupare?

Un computer UEFI pe care este implementată o descărcare sigură și care utilizează un UEFI ROM suplimentar fără semnătură. Mai mult, firmware-ul compatibil pentru a asigura funcționarea plăcilor existente poate fi vulnerabil fără efectuarea controalelor ROM suplimentare.

Netbook-uri, laptop-uri, și plăcile ultrabuki: majoritatea nu abordează backplane ROM-ul de anvelope mai frecvent utilizate ca PCI / e, ISA și derivați ai acestora (ExpressCard, miniPCI, CardBus, PCCard, LPC, trăsnete etc.). Dacă cele de mai sus nu sunt utilizate în laptop, numărul de posibile direcții de atac este redus semnificativ. În plus, driverele UEFI pentru componentele laptopului paralel sunt integrate în nucleul BIOS-ului încorporat al kernel-ului, care nu este localizat pe un ROM suplimentar separat. Prin urmare, majoritatea laptopurilor nu sunt expuse riscului. De asemenea, în cazul în care ROM-urile suplimentare învechite sunt dezactivate, UEFI pare să suporte numai ROM-uri suplimentare bazate pe PCI.

Cu toate acestea, dacă computerul dvs., placa de bază sau serverul utilizează UEFI BIOS și are o descărcare sigură, este posibil ca dispozitivul dvs. să fie vulnerabil. Pe un controler RAID dedicat, controler de stocare suplimentar pentru SATA, FC, etc. sau adaptoare de rețea Ethernet PCIe, pot fi utilizate alte dispozitive ROM. Controlerele de completare care acceptă o gamă largă de funcții pe servere sunt utilizate pe scară largă, deci acest lucru este valabil mai ales pentru spațiul de server.

De asemenea, poate afecta computerele pe 32 și 64 de biți și clasa 2 și clasa 3.

În cazul în care platforma de încărcare securizată acceptă dispozitive ROM suplimentare care nu sunt conectate la platforma în mod constant, și capacitatea de a verifica astfel de ROM suplimentare, aceasta ar trebui să sprijine, de asemenea, metodele de verificare ROM-uri opționale descrise în UDP protocoale de rețea și MTFTP și variabilele testate EFI, descrise în secțiunea caietul de sarcini 7.2 UEFI 2.3.1 modificat de C.

4. Cum efectuez verificarea?

Dacă dezvoltați software încorporat bazat pe Tiano Core, testați vulnerabilitatea menționată în secțiunea 2.1. Dacă utilizați firmware-ul unui alt furnizor independent de BIOS (IBV), contactați-l cu această întrebare. Sau puteți efectua singur testul, așa cum este descris mai jos.

Veți avea nevoie de următoarele.

PC pentru testare cu firmware-ul UEFI

Asigurați-vă că descărcarea sigură este activată

Pași pentru a efectua scanarea

Introduceți cardul PCI al suplimentului UEFI cu UEFI ROM-ul opțional în PC pentru verificare.

Activați funcția Secure Boot prin configurarea următoarelor opțiuni.

PK este testul dvs. PK sau testul PK auto-semnat

KEK - Microsoft KEK, test KEK Fabrikam, semnat cu PK, sau un alt KEK

DB - NULL. (Acest parametru este setat la "NULL").

SecureBoot - această variabilă UEFI trebuie să fie setată la "true"

Se așteaptă următorul rezultat.

Indiferent de opțiunea ROM-ul de conducător auto UEFI semnat sau nu ROM opțiune nu este încărcată dacă este setat parametrul DB la «NULL», și parametrul inclus SB (PK înregistrate și KEK).

A se vedea. De asemenea, o altă variantă a testului de mai sus în anexa A. Această abordare nu necesită valorile parametrilor DB «Null», dar pentru a efectua verificări necesare conducătorului auto UEFI ROM opțiune fără semn achiziționată de la un furnizor independent.

5. Cum pot remedia acest lucru?

Dacă verificarea de mai sus nu este finalizată, contactați IBV pentru a obține versiunile necesare și configurați-le pentru a testa alte ROM-uri. Verificați dacă firmware-ul este testat cu succes. Pentru computerele distribuite, va trebui să efectuați o actualizare de firmware sigură. Vedeți publicația NIST 800-147 și Ghidul pentru crearea și gestionarea cheilor de descărcare securizate în Windows 8.1.

Puteți testa PC-ul și utilizați Windows HCK ca instrument de validare (dar nu și un instrument de certificare) pentru a verifica dacă firmware-ul este actualizat în siguranță.

5.1. Semnarea conducătorului auto

Dacă există drivere nesemnate pentru UEFI ROM-uri suplimentare, citiți mai jos pentru informații despre cum să remediați acest lucru.

Semnați separat fiecare șofer ROM suplimentar. Acest lucru va perturba formatul PCI ROM-ului opțional. Șoferul UEFI trebuie să fie semnat numai înainte de a crea un ROM suplimentar combinat.

Înainte de a intra UEFI opțiunea driverului de imagine ROM UEFI semn sus și verificați-l la pornirea ghetei sigură în coajă UEFI (încărcare și descărcare de drivere fișier). Apoi adăugați driverul semnat la ROM-ul suplimentar combinat.

IHV dvs. poate contacta centrul Microsoft SysDev pentru a semna UEFI ROM-uri suplimentare prin serviciile disponibile în centrul SysDev.

5.2. Verificați pentru actualizări

Efectuați testul descris mai sus pentru a vă asigura că actualizarea nu este vulnerabilă. Utilizați verificarea HCK pentru a verifica dacă nu există regresii funcționale.

6. Resurse

Informații importante din specificația UEFI 2.3.1.

2.5.1. Probleme tradiționale ale unui ROM suplimentar

10. Protocoale - modelul conducătorului UEFI

13.4.2. PCI ROM-uri suplimentare

20. Codul mașinii virtuale EFI bytecode

28. Informații generale despre HII

29. Protocoale HII

30. Procesarea configurației HII și protocolul browserului

Anexa A. O abordare alternativă a testelor cu drivere ROM opționale fără semnătură

Această abordare se bazează pe primirea de fonduri de la IHV pentru a verifica dacă conducătorul UEFI ROM suplimentar este semnat.

Veți avea nevoie de următoarele.

PC pentru testare cu firmware-ul UEFI

Asigurați-vă că descărcarea sigură este activată

Mijloace de la IHV pentru a detecta semnătura driverului ROM suplimentar, dacă nu este evident - dacă driverul ROM suplimentar este semnat sau nu

Dacă firmware-ul nu este implementat corect, testul îl va afișa.

Anexa B. Scenarii pentru activarea Începerii Secure cu NULL db

Puteți utiliza fie setul curent de variabile de boot în condiții de siguranță (PK și KEK), fie puteți genera variabile de testare în scopul verificării.

Următorii pași descriu modul de creare a unui test PK, KEK și setarea parametrului DB la "NULL". Asigurați-vă că descărcarea sigură nu este activată; altfel, acești pași necesită semnarea fișierelor de bin UEFI.

Variabilele de boot sigure - DB, KEK și PK - sunt instalate în ordine inversă, deci nu este necesar să semnați fișiere UEFI bin.

Înainte de această etapă, computerul trebuie să fie în modul de instalare.

Crearea certificatelor KEK și PK

Pentru această etapă, aveți nevoie de instrumentul makecert.exe disponibil în SDK-ul Windows.