Interfață Firmware Extensibilă Unificată - Unified Extensible Firmware Interface

Poziția EFI în stiva de software

Interfața Unified Extensible Firmware Interface ( UEFI ) este o specificație disponibilă publicului care definește o interfață software între un sistem de operare și firmware-ul platformei . UEFI înlocuiește interfața firmware de bază a sistemului de intrare / ieșire de bază ( BIOS ), prezentă inițial pe toate computerele personale compatibile cu computerul IBM , majoritatea implementărilor de firmware UEFI oferind suport pentru serviciile BIOS vechi. UEFI poate suporta diagnosticarea la distanță și repararea computerelor, chiar și fără niciun sistem de operare instalat.

Intel a dezvoltat specificațiile originale EFI ( Extensible Firmware Interface ). Unele dintre practicile și formatele de date ale EFI reflectă cele ale Microsoft Windows . În 2005, UEFI a depreciat EFI 1.10 (versiunea finală a EFI). EFI Forumul Unified este organismul industrie care gestionează specificațiile UEFI pe tot parcursul.

Istorie

Motivația inițială pentru EFI a venit în timpul dezvoltării timpurii a primelor sisteme Intel-HP Itanium la mijlocul anilor 1990. Limitările BIOS-ului (cum ar fi modul real pe 16 biți , 1 MB spațiu de memorie adresabil, programarea limbajului de asamblare și hardware-ul PC AT ) deveniseră prea restrictive pentru platformele de server mai mari pe care le viza Itanium. Efortul de abordare a acestor preocupări a început în 1998 și a fost numit inițial Intel Boot Initiative . Ulterior a fost redenumită Extensible Firmware Interface (EFI).

În iulie 2005, Intel a încetat dezvoltarea specificației EFI la versiunea 1.10 și a contribuit-o la Unified EFI Forum , care a dezvoltat specificația ca Unified Extensible Firmware Interface (UEFI). Specificația originală EFI rămâne deținută de Intel, care furnizează exclusiv licențe pentru produsele bazate pe EFI, dar specificația UEFI este deținută de Forumul UEFI.

Versiunea 2.0 a specificației UEFI a fost lansată la 31 ianuarie 2006. A adăugat criptografie și securitate. Versiunea 2.1 a specificației UEFI a fost lansată la 7 ianuarie 2007. A adăugat autentificarea rețelei și arhitectura interfeței utilizator („Infrastructura interfeței umane” în UEFI).

Cea mai recentă specificație UEFI, versiunea 2.9, a fost publicată în martie 2021.

Prima implementare open source UEFI, Tiano, a fost lansată de Intel în 2004. De atunci, Tiano a fost înlocuit de EDK și EDK2 și este acum întreținut de comunitatea TianoCore.

În decembrie 2018, Microsoft a anunțat Project Mu, o furcă de TianoCore EDK2 utilizată în produsele Microsoft Surface și Hyper-V . Proiectul promovează ideea firmware-ului ca serviciu .

În octombrie 2018, Arm a anunțat Arm ServerReady , un program de certificare a conformității pentru aterizarea sistemelor de operare generice și a hipervizoarelor pe servere bazate pe Arm. Programul necesită ca firmware-ul sistemului să fie compatibil cu cerințele de bază pentru pornire server (SBBR). SBBR necesită conformitatea UEFI, ACPI și SMBIOS . În octombrie 2020, Arm a anunțat extinderea programului pe piața edge și IoT . Noul nume al programului este Arm SystemReady . Arm SystemReady a definit specificația Base Boot Requirements ( BBR ) care oferă în prezent trei rețete, dintre care două sunt legate de UEFI: 1) SBBR: care necesită conformitatea UEFI, ACPI și SMBIOS adecvate mediului de operare la nivel de întreprindere, cum ar fi Windows, Red Hat Enterprise Linux, VMware ESXi; și 2) EBBR: care necesită conformitatea cu un set de interfețe UEFI definite în Embedded Base Boot Cerencies ( EBBR ) adecvate mediului încorporat, cum ar fi Yocto. Multe distribuții Linux și BSD pot suporta ambele rețete.

Avantaje

Interfața definită de specificația EFI include tabele de date care conțin informații despre platformă și servicii de boot și runtime care sunt disponibile pentru sistemul de încărcare și sistemul de operare. Firmware-ul UEFI oferă mai multe avantaje tehnice față de un sistem BIOS tradițional:

  • Capacitatea de a porni un disc care conține partiții mari (peste 2  TB ) cu un tabel de partiții GUID (GPT)
  • Mediu pre-OS flexibil, inclusiv capacitate de rețea, GUI, multi-limbaj
  • Mediu pre-OS pe 32 de biți (de exemplu IA-32 , ARM32 ) sau pe 64 de biți (de exemplu x64 , AArch64 )
  • Programarea limbajului C
  • Design modular
  • Compatibilitate înapoi și înainte

Compatibilitate

Compatibilitatea procesorului

Începând cu versiunea 2.5, există legături de procesor pentru Itanium, x86, x86-64, ARM (AArch32) și ARM64 (AArch64). Numai procesoarele little-endian pot fi acceptate. Suportul neoficial UEFI este în curs de dezvoltare pentru POWERPC64 prin implementarea TianoCore pe partea de sus a OPAL, stratul de abstractizare OpenPOWER, care rulează în modul puțin endian. Există proiecte similare pentru MIPS și RISC-V . Începând cu UEFI 2.7, legările procesorului RISC-V au fost stabilite oficial pentru modurile de 32, 64 și 128 de biți.

BIOS-ul PC standard este limitat la un mod de procesor pe 16 biți și 1 MB de spațiu de memorie adresabil, rezultat din designul bazat pe IBM 5150 care utilizează un procesor Intel 8088 pe 16 biți . În comparație, modul procesor într-un mediu UEFI poate fi pe 32 de biți ( x86-32 , AArch32) sau pe 64 de biți ( x86-64 , Itanium și AArch64). Implementările de firmware UEFI pe 64 de biți acceptă modul lung , care permite aplicațiilor din mediul de preîncărcare să utilizeze adresarea pe 64 de biți pentru a obține acces direct la toată memoria aparatului.

UEFI necesită ca firmware-ul și încărcătorul sistemului de operare (sau nucleul) să fie potrivite cu dimensiunea; adică, o implementare a firmware-ului UEFI pe 64 de biți poate încărca doar un sistem de încărcare sau un nucleu de boot pe sistemul de operare pe 64 de biți (cu excepția cazului în care este utilizat boot-ul Legacy bazat pe CSM) și același lucru se aplică și pe 32 de biți. După tranziția sistemului de la „Servicii de încărcare” la „Servicii de execuție”, nucleul sistemului de operare preia. În acest moment, nucleul poate schimba modurile procesorului, dacă dorește, dar aceasta blochează utilizarea serviciilor de rulare (cu excepția cazului în care nucleul revine din nou). Ca de versiunea 3.15, nucleul Linux sprijină pe 64 de biți kernel - boot - at pe implementările UEFI firmware pe 32 de biți care rulează pe x86-64 procesoare, cu predare UEFI sprijin de la un încărcător de boot UEFI ca cerință. Protocolul de transfer UEFI deduplică codul de inițializare UEFI între kernel și încărcătoarele de încărcare UEFI, lăsând inițializarea să fie efectuată numai de butonul de încărcare UEFI al kernel-ului Linux .

Compatibilitatea dispozitivului disc

A se vedea, de asemenea: GPT § Suport sisteme de operare și MBR de protecție

În plus față de schema standard de partiție pe disc PC care utilizează o înregistrare master boot (MBR), UEFI funcționează și cu schema de partiționare GUID Partition Table (GPT), care este lipsită de multe dintre limitările MBR. În special, limitele MBR privind numărul și dimensiunea partițiilor de disc (până la patru partiții primare pe disc și până la 2  TB (2 × 2 40 octeți ) pe disc) sunt relaxate. Mai precis, GPT permite o dimensiune maximă a discului și partiției de 8  ZB (8 × 2 70 octeți) .

Linux

Vezi și: partiția sistemului EFI § Linux

Suportul pentru GPT în Linux este activat prin activarea opțiunii CONFIG_EFI_PARTITION(EFI GUID Partition Support) în timpul configurării kernel-ului. Această opțiune permite Linux să recunoască și să utilizeze discurile GPT după ce firmware-ul sistemului trece controlul asupra sistemului către Linux.

Pentru compatibilitate inversă, Linux poate utiliza discuri GPT în sisteme bazate pe BIOS atât pentru stocarea datelor, cât și pentru boot, deoarece GRUB 2 și Linux sunt conștiente de GPT. O astfel de configurare este denumită de obicei BIOS-GPT . Întrucât GPT încorporează MBR de protecție, un computer bazat pe BIOS poate porni de pe un disc GPT folosind un încărcător de boot conștient de GPT stocat în zona de cod de bootstrap a MBR de protecție . În cazul GRUB, o astfel de configurație necesită o partiție de pornire BIOS pentru ca GRUB să încorporeze codul său din a doua etapă din cauza absenței lacunei post-MBR în discurile partiționate GPT (care este preluată de antetul primar și tabelul de partiții primare al GPT ). În mod obișnuit , dimensiunea de 1  MB , identificatorul unic global (GUID) al acestei partiții în schema GPT este 21686148-6449-6E6F-744E-656564454649 și este utilizat de GRUB numai în setările BIOS-GPT. Din perspectiva GRUB, nu există un astfel de tip de partiție în cazul partiționării MBR. Această partiție nu este necesară dacă sistemul este bazat pe UEFI, deoarece nu este necesară încorporarea codului din etapa a doua în acest caz.

Sistemele UEFI pot accesa discurile GPT și pot porni direct de pe ele, ceea ce permite Linux să utilizeze metodele de încărcare UEFI. Pornirea Linux de pe discurile GPT pe sistemele UEFI implică crearea unei partiții de sistem EFI (ESP), care conține aplicații UEFI precum bootloadere, nuclee de sistem de operare și software utilitar. O astfel de configurare este denumită de obicei UEFI-GPT , în timp ce ESP se recomandă să aibă dimensiunea de cel puțin 512 MB și formatat cu un sistem de fișiere FAT32 pentru o compatibilitate maximă.

Pentru compatibilitate inversă , majoritatea implementărilor UEFI acceptă, de asemenea, bootarea de pe discuri partiționate MBR, prin intermediul modulului de compatibilitate (CSM) care oferă compatibilitate BIOS moștenită. În acest caz, pornirea Linux pe sistemele UEFI este la fel ca pe sistemele bazate pe BIOS.

Microsoft Windows

Versiunile pe 64 de biți ale Windows Vista SP1 și versiunile ulterioare și pe 32 de biți ale Windows 8 , 8.1 și 10 pot porni de pe un disc GPT mai mare de 2  TB .

Caracteristici

Servicii

Exemplu de variabile UEFI

EFI definește două tipuri de servicii: servicii de boot și servicii de runtime . Serviciile de pornire sunt disponibile numai în timp ce firmware-ul deține platforma (adică înainte de ExitBootServices()apel) și includ console text și grafice pe diferite dispozitive și servicii de autobuz, bloc și fișier. Serviciile de rulare sunt încă accesibile în timp ce sistemul de operare rulează; acestea includ servicii precum data, ora și accesul NVRAM .

Servicii de protocol de ieșire grafică (GOP)
Grafica Protocolul de ieșire (GOP) oferă servicii de rulare; vezi, de asemenea , secțiunea Caracteristici grafice de mai jos. Sistemului de operare i se permite să scrie direct pe framebuffer-ul furnizat de GOP în timpul modului de rulare.
Servicii de hărți de memorie UEFI
Servicii SMM
Servicii ACPI
Servicii SMBIOS
Servicii variabile
Variabilele UEFI oferă o modalitate de stocare a datelor, în special date nevolatile. Unele variabile UEFI sunt partajate între firmware-ul platformei și sistemele de operare. Spațiile de nume variabile sunt identificate prin GUID-uri, iar variabilele sunt perechi cheie / valoare. De exemplu, variabilele UEFI pot fi folosite pentru a păstra mesajele de blocare în NVRAM după o blocare pentru ca sistemul de operare să le recupereze după o repornire.
Servicii de timp
UEFI oferă servicii de timp. Serviciile orare includ suport pentru fusul orar și câmpurile de vară, care permit setarea ceasului hardware în timp real la ora locală sau UTC. Pe mașinile care utilizează un ceas PC-AT în timp real, în mod implicit ceasul hardware trebuie setat la ora locală pentru compatibilitatea cu Windows bazat pe BIOS, cu excepția cazului în care se utilizează versiuni recente și o intrare în registrul Windows este setată pentru a indica utilizarea din UTC.

Aplicații

Interacțiunea dintre managerul de încărcare EFI și driverele EFI

Dincolo de încărcarea unui sistem de operare, UEFI poate rula aplicații UEFI , care se află ca fișiere pe partiția de sistem EFI . Acestea pot fi executate din UEFI Shell, de către managerul de boot al firmware-ului sau de alte aplicații UEFI. Aplicațiile UEFI pot fi dezvoltate și instalate independent de producătorii de echipamente originale (OEM).

Un tip de aplicație UEFI este un sistem de încărcare a sistemului de operare, cum ar fi GRUB , rEFInd , Gummiboot și Windows Boot Manager ; care încarcă unele fișiere OS în memorie și le execută. De asemenea, un încărcător de boot al sistemului de operare poate furniza o interfață cu utilizatorul pentru a permite selectarea unei alte aplicații UEFI. Utilitățile precum UEFI Shell sunt, de asemenea, aplicații UEFI.

Protocoale

EFI definește protocoalele ca un set de interfețe software utilizate pentru comunicarea între două module binare. Toți driverele EFI trebuie să ofere servicii altora prin protocoale. Protocoalele EFI sunt similare cu apelurile de întrerupere BIOS .

Drivere de dispozitiv

În plus față de driverele de dispozitiv specifice arhitecturii setului de instrucțiuni standard , EFI oferă un driver de dispozitiv independent de ISA stocat în memoria non-volatilă sub forma codului de octet EFI sau EBC . Firmware-ul sistemului are un interpret pentru imagini EBC. În acest sens, EBC este similar cu Open Firmware , firmware -ul independent de ISA utilizat între computerele Apple Macintosh și Sun Microsystems SPARC bazate pe PowerPC .

Unele drivere EFI specifice arhitecturii (non-EFI Byte Code) pentru unele tipuri de dispozitive pot avea interfețe pentru utilizare de către sistemul de operare. Acest lucru permite sistemului de operare să se bazeze pe EFI pentru ca driverele să efectueze funcții grafice și de rețea de bază înainte și dacă sunt încărcate driverele specifice sistemului de operare.

În alte cazuri, driverul EFI poate fi driver de sistem de fișiere care permite bootarea din alte tipuri de volume de disc. Exemplele includ efifs pentru 37 de sisteme de fișiere (bazate pe codul GRUB2 ), utilizate de Rufus pentru încărcarea în lanț a ESP-urilor NTFS.

Caracteristici grafice

Specificația EFI 1.0 a definit un protocol UGA (Universal Graphic Adapter) ca o modalitate de a sprijini caracteristicile grafice. UEFI nu a inclus UGA și l-a înlocuit cu GOP (Graphics Output Protocol).

UEFI 2.1 a definit o „Infrastructură de interfață umană” (HII) pentru a gestiona intrarea utilizatorului, șirurile localizate, fonturile și formularele (în sensul HTML ). Acestea permit producătorilor de echipamente originale (OEM) sau furnizorilor independenți de BIOS (IBV) să proiecteze interfețe grafice pentru configurarea pre-boot.

Majoritatea implementărilor de firmware UEFI timpurii au fost bazate pe consolă. Astăzi multe implementări de firmware UEFI se bazează pe GUI.

Partiție de sistem EFI

Articol principal: partiția sistemului EFI

O partiție de sistem EFI, adesea prescurtată la ESP, este o partiție de dispozitiv de stocare a datelor care este utilizată în computerele care aderă la specificația UEFI. Accesat de firmware-ul UEFI la pornirea computerului, acesta stochează aplicațiile UEFI și fișierele pe care aceste aplicații trebuie să le ruleze, inclusiv încărcătoarele de pornire ale sistemului de operare . Schemele de tabele de partiții acceptate includ MBR și GPT , precum și volumele El Torito pe discuri optice. Pentru utilizare pe ESP-uri, UEFI definește o versiune specifică a sistemului de fișiere FAT , care este menținută ca parte a specificației UEFI și independent de specificația FAT originală, cuprinzând sistemele de fișiere FAT32 , FAT16 și FAT12 . ESP oferă, de asemenea, spațiu pentru un sector de boot, ca parte a compatibilității BIOS înapoi.

Pornirea

Pornire UEFI

Spre deosebire de BIOS-ul PC vechi, UEFI nu se bazează pe sectoarele de boot , definind în schimb un manager de boot ca parte a specificației UEFI. Atunci când un computer este pornit, managerul de pornire verifică configurația de pornire și se bazează pe setările sale, apoi execută încărcătorul de pornire specificat al sistemului de operare sau kernelul sistemului de operare (de obicei, încărcătorul de pornire). Configurația de boot este definită de variabilele stocate în NVRAM , inclusiv variabile care indică căile sistemului de fișiere către încărcătoarele OS sau nucleele OS.

Sistemele de încărcare ale sistemului de operare pot fi detectate automat de UEFI, ceea ce permite pornirea ușoară de pe dispozitive detașabile, cum ar fi unitățile flash USB . Această detectare automată se bazează pe căi de fișiere standardizate către încărcătorul de boot al sistemului de operare, calea variază în funcție de arhitectura computerului . Formatul căii fișierului este definit ca <EFI_SYSTEM_PARTITION> \ EFI \ BOOT \ BOOT <MACHINE_TYPE_SHORT_NAME> .EFI ; de exemplu, calea fișierului către sistemul de încărcare OS pe un sistem x86-64 este \ efi \ boot \ bootx64.efi și \ efi \ boot \ bootaa64.efi pe arhitectura ARM64.

Procesul de pornire

Pornirea sistemelor UEFI de pe discurile partiționate GPT se numește de obicei boot UEFI-GPT . În ciuda faptului că specificația UEFI necesită ca tabelele de partiții GPT să fie pe deplin acceptate, unele implementări de firmware UEFI trec imediat la bootarea CSM bazată pe BIOS în funcție de tipul tabelei de partiții a discului de boot, împiedicând efectiv bootarea UEFI din EFI System Partition. pe discurile partiționate MBR. O astfel de schemă de boot este denumită în mod obișnuit UEFI-MBR .

De asemenea, este obișnuit ca un manager de boot să aibă o interfață de utilizator textuală, astfel încât utilizatorul să poată selecta sistemul de operare dorit (sau utilitarul de configurare) dintr-o listă de opțiuni de boot disponibile.

Pornire CSM

Pentru a asigura compatibilitatea înapoi, majoritatea implementărilor de firmware UEFI pe mașini de clasă PC acceptă, de asemenea, bootarea în modul BIOS moștenit de pe discuri partiționate MBR, prin intermediul modulului de compatibilitate (CSM) care oferă compatibilitate moștenită a BIOS-ului. În acest scenariu, bootarea se efectuează în același mod ca pe sistemele bazate pe BIOS, ignorând tabela de partiții și bazându-se pe conținutul unui sector de boot .

Boot-ul în stil BIOS de pe discuri partiționate MBR este denumit în mod obișnuit BIOS-MBR , indiferent dacă este efectuat pe UEFI sau sisteme bazate pe BIOS. În plus, este posibilă pornirea sistemelor bazate pe BIOS de pe discuri GPT și o astfel de schemă de boot este denumită în mod obișnuit BIOS-GPT .

Modulul de compatibilitate permite sistemelor de operare vechi și unele opțiuni vechi ROM-uri care nu acceptă UEFI să fie utilizate în continuare. De asemenea, oferă funcționalitatea necesară pentru modul de gestionare a sistemului (SMM), numită CompatibilitySmm , ca o completare a caracteristicilor furnizate de UEFI SMM. Un exemplu al unei astfel de funcționalități vechi SMM este furnizarea de suport USB vechi pentru tastatură și mouse, prin emularea omologilor lor PS / 2 clasici .

În noiembrie 2017, Intel a anunțat că intenționează să elimine treptat suportul pentru CSM până în 2020.

Pornirea în rețea

Specificația UEFI include suport pentru bootarea prin rețea prin mediul Preboot eXecution Environment (PXE). Protocoalele de rețea de pornire PXE includ Protocol Internet ( IPv4 și IPv6 ), User Datagram Protocol (UDP), Dynamic Host Configuration Protocol (DHCP), Trivial File Transfer Protocol (TFTP) și iSCSI .

Imaginile sistemului de operare pot fi stocate de la distanță în rețelele de spațiu de stocare (SAN-uri), cu Internet Small Computer System Interface (iSCSI) și Fibre Channel over Ethernet (FCoE) ca protocoale acceptate pentru accesarea SAN-urilor.

Versiunea 2.5 a specificației UEFI adaugă suport pentru accesarea imaginilor de boot prin protocolul HTTP .

Încărcare sigură

A se vedea, de asemenea ,: Secure Boot critic
Exemplu de boot securizat activ așa cum a fost detectat de rEFInd boot manager

Specificația UEFI 2.3.1 Errata C (sau o versiune ulterioară) definește un protocol cunoscut sub numele de Secure Boot , care poate asigura procesul de boot, împiedicând încărcarea driverelor UEFI sau a încărcătoarelor de boot ale sistemului de operare care nu sunt semnate cu o semnătură digitală acceptabilă . Detaliile mecanice ale precizării semnării acestor drivere nu sunt specificate. Când Secure Boot este activat, acesta este plasat inițial în modul „setare”, ceea ce permite ca o cheie publică cunoscută sub numele de „cheie de platformă” (PK) să fie scrisă pe firmware. Odată ce cheia este scrisă, Secure Boot intră în modul „Utilizator”, unde numai driverele UEFI și încărcătoarele de încărcare ale sistemului de operare semnate cu cheia platformei pot fi încărcate de firmware. „Chei de schimb de chei” suplimentare (KEK) pot fi adăugate la o bază de date stocată în memorie pentru a permite utilizarea altor certificate, dar acestea trebuie să aibă totuși o conexiune cu porțiunea privată a cheii platformei. Secure Boot poate fi plasat și în modul „Personalizat”, unde se pot adăuga la sistem chei publice suplimentare care nu se potrivesc cu cheia privată.

Secure Boot este acceptat de Windows 8 și 8.1 , Windows Server 2012 și 2012 R2, Windows 10 , Windows Server 2016 , 2019 și 2022 și Windows 11 , VMware vSphere 6.5 și o serie de distribuții Linux, inclusiv Fedora (de la versiunea 18), openSUSE (de la versiunea 12.3), RHEL (de la versiunea 7), CentOS (de la versiunea 7), Debian (de la versiunea 10) și Ubuntu (de la versiunea 12.04.2). Începând din ianuarie 2017, asistența FreeBSD se află într-o etapă de planificare.

Shell UEFI

Exemplu de sesiune UEFI shell 2.2

UEFI oferă un mediu shell , care poate fi utilizat pentru a executa alte aplicații UEFI, inclusiv încărcătoare de încărcare UEFI . În afară de aceasta, comenzile disponibile în shell-ul UEFI pot fi utilizate pentru obținerea diverselor alte informații despre sistem sau firmware, inclusiv obținerea hărții de memorie ( memmap), modificarea variabilelor managerului de boot ( bcfg), rularea programelor de partiționare ( diskpart), încărcarea driverelor UEFI, și editarea fișierelor text ( edit).

Codul sursă pentru un shell UEFI poate fi descărcat de pe Intel „s TianoCore proiect UDK / EDK2. Este disponibil și un ShellBinPkg pre-construit. Shell v2 funcționează cel mai bine în sistemele UEFI 2.3+ și este recomandat peste Shell v1 în aceste sisteme. Shell v1 ar trebui să funcționeze în toate sistemele UEFI.

Metodele utilizate pentru lansarea shell UEFI depind de producătorul și modelul plăcii de bază a sistemului . Unele dintre ele oferă deja o opțiune directă în configurarea firmware pentru lansarea, de exemplu , versiunea x86-64 compilată a nevoilor shell care urmează să fie puse la dispoziție ca <EFI_SYSTEM_PARTITION>/SHELLX64.EFI. Unele alte sisteme au un shell UEFI deja încorporat care poate fi lansat prin combinații adecvate de apăsare a tastelor. Pentru alte sisteme, soluția este fie crearea unei unități flash USB adecvate, fie adăugarea manuală ( bcfg) a unei opțiuni de boot asociate cu versiunea compilată de shell.

Comenzi

Următoarea este o listă de comenzi acceptate de shell-ul EFI.

Extensii

Extensiile la UEFI pot fi încărcate de la practic orice dispozitiv de stocare nevolatil atașat la computer. De exemplu, un producător original de echipamente (OEM) poate distribui sisteme cu o partiție de sistem EFI pe hard disk, ceea ce ar adăuga funcții suplimentare firmware-ului UEFI standard stocat pe ROM-ul plăcii de bază .

Capsulă UEFI

UEFI Capsule definește o interfață de actualizare firmware modernă și sigură de la Firmware-to-OS. Windows 8 , Windows 8.1 , Windows 10 și Fwupd pentru Linux acceptă UEFI Capsule.

Hardware

La fel ca BIOS-ul , UEFI inițializează și testează componentele hardware ale sistemului (de exemplu, formarea memoriei, formarea legăturilor PCIe, formarea legăturilor USB) și apoi încarcă încărcătorul de încărcare de pe dispozitivul de stocare în masă sau de la pornirea în rețea . În sistemele x86 , firmware-ul UEFI este de obicei stocat în cipul flash NOR al plăcii de bază.

Clasele UEFI

Mașinile UEFI pot avea una dintre următoarele „clase”, care au fost utilizate pentru a facilita tranziția la UEFI. Intel a încheiat BIOS-ul vechi în 2020.

  • Clasa 0: BIOS vechi
  • Clasa 1: UEFI în modul numai CSM (adică fără boot UEFI)
  • Clasa 2: UEFI cu CSM
  • Clasa 3: UEFI fără CSM
  • Clasa 3+: UEFI cu Secure Boot Activat

Etape de pornire

SEC - Faza de securitate

Aceasta este prima etapă a boot-ului UEFI, dar poate avea un cod binar specific platformei care îl precede. (de exemplu, Intel ME , AMD PSP , microcod CPU ). Acesta constă dintr-un cod minim scris în limbaj de asamblare pentru arhitectura specifică. Inițializează o memorie temporară (adesea memoria cache a procesorului ca RAM) și servește drept rădăcină software de încredere a sistemului, cu opțiunea de a verifica PEI înainte de transfer.

PEI - Inițializare pre-EFI

A doua etapă a boot-ului UEFI constă într-un dispecer care conține dependență, care încarcă și rulează module PEI (PEIM) pentru a gestiona sarcini de inițializare hardware timpurie, cum ar fi inițializarea memoriei principale și operațiuni de recuperare a firmware-ului. În plus, este responsabil pentru descoperirea modului de încărcare curent și gestionarea multor operațiuni ACPI S0ix / ACPI S3. În cazul reluării ACPI S0ix / ACPI S3, este responsabilă pentru restabilirea multor registre hardware într-o stare de pre-repaus. PEI folosește și memoria cache a procesorului ca RAM.

DXE - Mediul de executare a driverului

Această etapă constă din module C și un dispecer care conștientizează dependența. Cu memoria principală disponibilă acum, procesorul, chipset-ul, placa principală și perifericele sunt inițializate în DXE și BDS.

BDS - Boot Device Select

BDS face parte din DXE. În această etapă, dispozitivele I / O și dispozitivele de pornire sunt inițializate, driverele UEFI sau opționalele ROM ale dispozitivelor PCI sunt executate în funcție de configurația sistemului și opțiunile de pornire sunt procesate.

TSL - Încărcare tranzitorie a sistemului

Aceasta este etapa dintre selectarea dispozitivului de boot și transferul către sistemul de operare. În acest moment se poate introduce UEFI shell sau executa o aplicație UEFI, cum ar fi încărcătorul de boot al sistemului de operare.

RT - Runtime

UEFI predă sistemului de operare (OS) după ce ExitBootServices () este executat. Un sistem de operare compatibil UEFI este acum responsabil pentru ieșirea din serviciile de boot care declanșează firmware-ul pentru a descărca toate codurile și datele care nu mai sunt necesare, lăsând doar codul / datele serviciilor de rulare, de exemplu SMM și ACPI . Un sistem de operare modern tipic va prefera să-și folosească propriile programe (cum ar fi driverele de nucleu ) pentru a controla dispozitivele hardware.

Când se folosește un sistem de operare vechi, CSM se va ocupa de acest apel, asigurându-se că sistemul este compatibil cu așteptările BIOS vechi.

Implementare și adoptare

Intel EFI

Articol principal: TianoCore EDK II
InsydeH2O, o implementare UEFI

Implementarea EFI de către Intel este Intel Platform Innovation Framework , denumit în cod Tiano . Tiano rulează pe procesoarele Intel XScale , Itanium , x86-32 și x86-64 și este software proprietar, deși o parte din cod a fost lansată sub licența BSD sau Eclipse Public License (EPL) sub denumirea de TianoCore . TianoCore poate fi folosit ca o sarcină utilă pentru coreboot .

Implementarea de către Phoenix Technologies a UEFI este marcată ca SecureCore Technology (SCT). American Megatrends oferă propria sa implementare firmware UEFI cunoscută sub numele de Aptio, în timp ce Insyde Software oferă InsydeH2O.

În decembrie 2018, Microsoft a lansat o versiune open source a implementării UEFI bazate pe TianoCore EDK2 de pe linia Surface , Project Mu .

Das U-Boot

O implementare a API-ului UEFI a fost introdusă în Universal Boot Loader ( Das U-Boot ) în 2017. Pe arhitectura ARMv8 distribuțiile Linux folosesc implementarea U-Boot UEFI împreună cu GNU GRUB pentru boot (de exemplu SUSE Linux ), la fel este valabil pentru OpenBSD. Pentru bootarea de la iSCSI iPXE poate fi folosit ca aplicație UEFI încărcată de U-Boot.

Platforme care utilizează EFI / UEFI

Intel primul e Itanium stații de lucru și servere, lansat în 2000, implementat EFI 1.02.

Primele sisteme Itanium 2 ale Hewlett-Packard , lansate în 2002, au implementat EFI 1.10; au reușit să pornească Windows , Linux , FreeBSD și HP-UX ; OpenVMS a adăugat capacitatea UEFI în iunie 2003.

În ianuarie 2006, Apple Inc. și-a livrat primele computere Macintosh bazate pe Intel . Aceste sisteme foloseau EFI în locul Open Firmware , care fusese folosit pe sistemele sale anterioare bazate pe PowerPC. La 5 aprilie 2006, Apple a lansat pentru prima dată Boot Camp , care produce un disc de drivere Windows și un instrument de partiționare nedistructivă pentru a permite instalarea Windows XP sau Vista fără a necesita o reinstalare a Mac OS X. De asemenea, a fost lansată o actualizare de firmware care a fost adăugată. Compatibilitatea BIOS cu implementarea sa EFI. Modelele ulterioare de Macintosh au fost livrate împreună cu noul firmware.

În 2005, peste un milion de sisteme Intel au fost livrate odată cu implementarea UEFI de către Intel. Noile produse mobile, desktop și server, utilizând implementarea UEFI de la Intel, au început să fie livrate în 2006. De exemplu, plăcile care utilizează seria de chipset-uri Intel 945 utilizează implementarea firmware-ului UEFI Intel.

Din 2005, EFI a fost implementat și pe arhitecturi non-PC, cum ar fi sistemele încorporate bazate pe nuclee XScale .

EDK (EFI Developer Kit) include o țintă NT32, care permite firmware-ului EFI și aplicațiilor EFI să ruleze într-o aplicație Windows . Dar EDK NT32 nu permite accesul direct la hardware. Aceasta înseamnă doar un subset de aplicație EFI și driverele pot fi executate la ținta EDK NT32.

În 2008, mai multe sisteme x86-64 au adoptat UEFI. În timp ce multe dintre aceste sisteme permit încă bootarea numai a sistemelor de operare bazate pe BIOS prin intermediul modulului de compatibilitate (CSM) (astfel nu li se pare utilizatorului că este bazat pe UEFI), alte sisteme au început să permită bootarea sistemelor de operare bazate pe UEFI. De exemplu, server IBM x3450, plăci de bază MSI cu ClickBIOS, notebook-uri HP EliteBook.

În 2009, IBM a livrat mașini System x (x3550 M2, x3650 M2, iDataPlex dx360 M2) și BladeCenter HS22 cu capacitate UEFI. Dell a livrat servere PowerEdge T610, R610, R710, M610 și M710 cu capacitate UEFI. Mai multe sisteme disponibile comercial sunt menționate într-o carte albă UEFI.

În 2011, principalii furnizori (cum ar fi ASRock , Asus , Gigabyte și MSI ) au lansat mai multe plăci de bază orientate către consumator, folosind chipset - ul Intel LGA 1155 din seria 6 și chipset-urile AMD 9 din seria AM3 + cu UEFI.

Odată cu lansarea Windows 8 în octombrie 2012, cerințele de certificare Microsoft necesită acum ca computerele să includă firmware care implementează specificația UEFI. Mai mult, dacă computerul acceptă caracteristica „ Connected Standby ” din Windows 8 (care permite dispozitivelor să aibă o gestionare a energiei comparabilă cu smartphone-urile , cu o revenire aproape instantanee din modul standby), atunci firmware-ului nu i se permite să conțină un modul de compatibilitate ( CSM). Ca atare, sistemele care acceptă Connected Standby sunt incapabile să pornească sistemele de operare Legacy BIOS.

În octombrie 2017, Intel a anunțat că va elimina suportul BIOS pentru PC vechi din toate produsele sale până în 2020, în favoarea UEFI Clasa 3.

Sisteme de operare

Un sistem de operare care poate fi pornit de la un (U) EFI se numește un sistem de operare (U) conștient de EFI, definit prin specificația (U) EFI. Aici termenul pornit de la un (U) EFI înseamnă pornirea directă a sistemului folosind un încărcător de sistem de operare (U) EFI stocat pe orice dispozitiv de stocare. Locația implicită pentru încărcător sistemului de operare este <EFI_SYSTEM_PARTITION>/BOOT/BOOT<MACHINE_TYPE_SHORT_NAME>.EFI, în cazul în care numele scurt de tipul de aparat poate fi IA32, X64, IA64, ARMsau AA64. Unii furnizori de sisteme de operare pot avea propriile încărcătoare de încărcare. De asemenea, pot schimba locația de încărcare implicită.

  • Kernel - ul Linux a fost capabil de a utiliza EFI la boot , deoarece începutul anilor 2000, folosind elilo EFI bootloader sau, mai recent, versiunile EFI ale GRUB . Grub + Linux acceptă, de asemenea, pornirea dintr-o tabelă de partiții GUID fără UEFI. Distribuția Ubuntu a adăugat suport pentru UEFI Secure Boot începând cu versiunea 12.10. Mai mult, kernel-ul Linux poate fi compilat cu opțiunea de a rula ca bootloader EFI singur prin intermediul caracteristicii EFI bootstub.
  • HP-UX utilizează (U) EFI ca mecanism de pornire pe sistemele IA-64 din 2002.
  • OpenVMS a folosit EFI pe IA-64 de la lansarea sa inițială de evaluare în decembrie 2003 și pentru lansări de producție din ianuarie 2005. Portul x86-64 al OpenVMS folosește și UEFI pentru a porni sistemul de operare.
  • Apple folosește EFI pentru linia sa de Mac-uri bazate pe Intel . Mac OS X v10.4 Tiger și Mac OS X v10.5 Leopard implementează EFI v1.10 în modul pe 32 de biți chiar și pe procesoare mai noi pe 64 de biți, dar suport complet a ajuns cu OS X v10.8 Mountain Lion .
  • Cele Itanium versiuni de Windows 2000 (Advanced Server Limited Edition și Datacenter Server Limited Edition) implementat EFI 1.10 în 2002. MS Windows Server 2003 pentru IA-64 , MS Windows XP 64-bit Edition și Windows 2000 Advanced Server Limited Edition, toate acestea sunt pentru familia de procesoare Intel Itanium , implementează EFI, o cerință a platformei prin specificația DIG64 .
  • Microsoft a introdus UEFI pentru sistemele de operare Windows x64 cu Windows Vista SP1 și Windows Server 2008, însă este acceptat doar UGA (Universal Graphic Adapter) 1.1 sau Legacy BIOS INT 10h ; Protocolul de ieșire grafică (GOP) nu este acceptat. Prin urmare, computerele care rulează versiuni pe 64 de biți ale Windows Vista SP1 , Windows Vista SP2 , Windows 7 , Windows Server 2008 și Windows Server 2008 R2 sunt compatibile cu UEFI Clasa 2. UEFI pe 32 de biți nu a fost inițial acceptat, deoarece furnizorii nu aveau niciun interes în producerea firmware-ului UEFI nativ pe 32 de biți din cauza stării principale a computerului pe 64 de biți . Windows 8 a introdus în cele din urmă optimizări suplimentare pentru sistemele UEFI, inclusiv suportul Graphics Output Protocol (GOP), o pornire mai rapidă, suport UEFI pe 32 de biți și suport Secure Boot. Microsoft a început să solicite UEFI să ruleze Windows cu Windows 11 .
  • La 5 martie 2013, FreeBSD Foundation a acordat o subvenție unui dezvoltator care dorește să adauge suport UEFI la kernel-ul și bootloader-ul FreeBSD . Modificările au fost inițial stocate într-o ramură discretă a codului sursă FreeBSD, dar au fost combinate cu sursa principală la 4 aprilie 2014 (revizuirea 264095); modificările includ suport și în programul de instalare. Suportul de încărcare UEFI pentru amd64 a apărut pentru prima dată în FreeBSD 10.1 și pentru arm64 în FreeBSD 11.0.
  • Oracle Solaris 11.1 și versiunile ulterioare acceptă boot-ul UEFI pentru sistemele x86 cu firmware UEFI versiunea 2.1 sau o versiune ulterioară. GRUB 2 este folosit ca boot loader pe x86.
  • OpenBSD 5.9 a introdus suportul de încărcare UEFI pentru sistemele x86 pe 64 de biți folosind propriul încărcător personalizat, OpenBSD 6.0 a extins acest suport pentru a include ARMv7.

Utilizarea UEFI cu virtualizare

  • Mașinile virtuale HP Integrity oferă boot UEFI pe serverele HP Integrity. De asemenea, oferă un mediu UEFI virtualizat pentru sistemele de operare UEFI-guest.
  • Intel găzduiește un proiect Open Open Machine Firmware pe SourceForge.
  • Software-ul VMware Fusion 3 pentru Mac OS X poate porni mașini virtuale Server Mac OS X folosind UEFI.
  • Stația de lucru VMware înainte de versiunea 11 acceptă neoficial UEFI, dar este activată manual prin editarea fișierului .vmx. VMware Workstation versiunea 11 și mai sus acceptă UEFI, indiferent dacă sistemul gazdă fizic este bazat pe UEFI. VMware Workstation 14 (și, în consecință, Fusion 10) adaugă suport pentru caracteristica Secure Boot a UEFI.
  • VSphere ESXi 5.0 hipervizorului acceptă în mod oficial UEFI. Versiunea 6.5 adaugă suport pentru Secure Boot.
  • VirtualBox a implementat UEFI de la 3.1, dar limitat la sistemele de operare Unix / Linux și unele versiuni de Windows (nu funcționează cu Windows Vista x64 și Windows 7 x64).
  • QEMU / KVM poate fi utilizat cu Firmware-ul Open Virtual Machine (OVMF) furnizat de TianoCore .
  • Hipervizorul VMware ESXi versiunea 5, parte a VMware vSphere, acceptă UEFI virtualizat ca alternativă la BIOS-ul PC moștenit din interiorul unei mașini virtuale.
  • A doua generație a mașinii virtuale Microsoft Hyper-V acceptă UEFI virtualizate.
  • VM-urile Shielded Google Cloud Platform acceptă UEFI virtualizate pentru a activa Secure Boot.

Dezvoltarea aplicațiilor

EDK2 Application Development Kit (EADK) face posibilă utilizarea funcțiilor standard de bibliotecă C în aplicațiile UEFI. EADK poate fi descărcat gratuit din proiectul SourceForge Intel TianoCore UDK / EDK2 . De exemplu, un port al interpretului Python este pus la dispoziție ca aplicație UEFI utilizând EADK. Dezvoltarea sa mutat în GitHub de la UDK2015.

Un program minimalist „ Bună ziua, lume ” scris cu EADK arată similar cu omologul său obișnuit C : 

#include <Uefi.h>
#include <Library/UefiLib.h>
#include <Library/ShellCEntryLib.h>

EFI_STATUS EFIAPI ShellAppMain(IN UINTN Argc, IN CHAR16 **Argv)
{
    Print(L"hello, world\n");
    return EFI_SUCCESS;
}

Critică

Numeroși activiști pentru drepturile digitale au protestat împotriva UEFI. Ronald G. Minnich , un coautor al coreboot-ului , și Cory Doctorow , un activist pentru drepturile digitale, au criticat UEFI ca o încercare de a elimina capacitatea utilizatorului de a controla cu adevărat computerul. Nu rezolvă problemele de lungă durată ale BIOS-ului de a necesita doi drivere diferite - unul pentru firmware și unul pentru sistemul de operare - pentru majoritatea hardware-ului.

Proiectul open-source TianoCore oferă, de asemenea, interfețe UEFI. TianoCore nu are driverele specializate care inițializează funcțiile chipset-ului, care sunt furnizate în schimb de coreboot , dintre care TianoCore este una dintre multele opțiuni de încărcare utilă. Dezvoltarea coreboot necesită cooperarea producătorilor de chipset-uri pentru a furniza specificațiile necesare dezvoltării driverelor de inițializare.

Încărcare sigură

Vezi și: Windows 8 § Recepție
Exemple de chei publice personalizate Secure Boot
MokManager, o parte din bootloader-ul Shim

În 2011, Microsoft a anunțat că computerele certificate pentru a rula sistemul de operare Windows 8 trebuiau să fie livrate cu cheia publică Microsoft înscrisă și cu Secure Boot activat. În urma anunțului, compania a fost acuzată de critici și de susținătorii software-ului liber / open source (inclusiv Free Software Foundation ) că a încercat să utilizeze funcționalitatea Secure Boot a UEFI pentru a împiedica sau a împiedica direct instalarea sistemelor de operare alternative, cum ar fi Linux . Microsoft a negat faptul că cerința Secure Boot a fost destinată să servească ca o formă de blocare și și-a clarificat cerințele afirmând că sistemele bazate pe x86 certificate pentru Windows 8 trebuie să permită Secure Boot să intre în modul personalizat sau să fie dezactivat, dar nu pe sisteme folosind arhitectura ARM . Windows 10 permite OEM-urilor să decidă dacă Secure Boot poate fi administrat sau nu de către utilizatorii sistemelor lor x86.

Alți dezvoltatori și-au exprimat îngrijorarea cu privire la problemele legale și practice ale implementării suportului pentru Secure Boot pe sistemele Linux în general. Fostul dezvoltator Red Hat, Matthew Garrett, a menționat că condițiile din GNU General Public License versiunea 3 pot împiedica utilizarea GNU GRand Unified Bootloader fără ca dezvoltatorul unei distribuții să dezvăluie cheia privată (cu toate acestea, Free Software Foundation și- a clarificat poziția, asigurând că responsabilitatea de a pune la dispoziție cheile a fost deținută de producătorul hardware-ului) și că ar fi, de asemenea, dificil pentru utilizatorii avansați să construiască nuclee personalizate care ar putea funcționa cu Secure Boot activat fără să le autosemneze. Alți dezvoltatori au sugerat că ar putea fi furnizate versiuni semnate de Linux cu o altă cheie, dar au observat că ar fi dificil să convingem OEM-urile să-și livreze computerele cu cheia necesară alături de cheia Microsoft.

Mai multe distribuții majore Linux au dezvoltat diferite implementări pentru Secure Boot. Garrett însuși a dezvoltat un bootloader minim cunoscut sub numele de shim, care este un bootloader precompilat, semnat, care permite utilizatorului să aibă încredere individuală în cheile furnizate de distribuțiile Linux. Ubuntu 12.10 folosește o versiune mai veche de shim preconfigurată pentru a fi utilizată cu propria cheie Canonical , care verifică doar bootloader-ul și permite încărcarea nucleelor ​​nesemnate; dezvoltatorii au crezut că practica de a semna doar bootloader-ul este mai fezabilă, deoarece un nucleu de încredere este eficient în securizarea doar a spațiului utilizatorului și nu a stării de pre-boot pentru care Secure Boot este conceput pentru a adăuga protecție. Acest lucru permite, de asemenea, utilizatorilor să-și construiască propriile nuclee și să folosească și module personalizate , fără a fi nevoie să reconfigureze sistemul. Canonical își menține, de asemenea, propria cheie privată pentru a semna instalări de Ubuntu preîncărcate pe computere OEM certificate care rulează sistemul de operare și intenționează, de asemenea, să impună o cerință Secure Boot - necesitând atât o cheie Canonical, cât și o cheie Microsoft (din motive de compatibilitate) ) pentru a fi inclus în firmware-ul lor. Fedora folosește și shim, dar necesită semnarea atât a nucleului, cât și a modulelor sale.

S-a contestat dacă kernelul sistemului de operare și modulele sale trebuie să fie semnate, de asemenea; în timp ce specificațiile UEFI nu o impun, Microsoft a afirmat că cerințele lor contractuale o fac și că își rezervă dreptul de a revoca orice certificate utilizate pentru semnarea codului care pot fi utilizate pentru a compromite securitatea sistemului. În Windows, numai driverul kernel WHQL este permis dacă este activat Secure Boot. În februarie 2013, un alt dezvoltator Red Hat a încercat să trimită un patch la kernel-ul Linux care să-i permită să analizeze semnarea autentică a Microsoft folosind o cheie master X.509 încorporată în fișierele PE semnate de Microsoft. Cu toate acestea, propunerea a fost criticată de creatorul Linux Linus Torvalds , care a atacat Red Hat pentru că a sprijinit controlul Microsoft asupra infrastructurii Secure Boot.

La 26 martie 2013, grupul spaniol de dezvoltare de software liber Hispalinux a depus o plângere oficială la Comisia Europeană , susținând că cerințele Microsoft Secure Boot pentru sistemele OEM sunt „obstructive” și anticoncurențiale .

La conferința Black Hat din august 2013, un grup de cercetători în domeniul securității a prezentat o serie de exploatări în implementări specifice ale UEFI ale furnizorilor care ar putea fi utilizate pentru a exploata Secure Boot.

În august 2016, s-a raportat că doi cercetători în domeniul securității au găsit cheia de securitate „cheie de aur” pe care Microsoft o folosește la semnarea sistemelor de operare. Din punct de vedere tehnic, nu a fost expusă nicio cheie, cu toate acestea, a fost un binar exploatabil semnat de cheie. Acest lucru permite oricărui software să ruleze ca și cum ar fi fost semnat cu adevărat de Microsoft și expune posibilitatea atacurilor rootkit și bootkit . Acest lucru face, de asemenea, imposibilă repararea erorii, deoarece orice patch poate fi înlocuit (retrogradat) de binarul (semnat) exploatabil. Microsoft a răspuns într-o declarație că vulnerabilitatea există doar în arhitectura ARM și dispozitivele Windows RT și a lansat două patch-uri; cu toate acestea, patch-urile nu elimină (și nu pot) înlătura vulnerabilitatea, ceea ce ar necesita înlocuirea cheilor din firmware-ul utilizatorului final pentru a remedia problema.

Multe distribuții Linux acceptă UEFI Secure Boot acum, cum ar fi RHEL (RHEL 7 și versiuni ulterioare), CentOS (CentOS 7 și versiuni ulterioare), Ubuntu , Fedora , Debian (Debian 10 și versiuni ulterioare), OpenSUSE , SUSE Linux .

Probleme cu firmware-ul

Proeminența sporită a firmware-ului UEFI în dispozitive a dus, de asemenea, la o serie de probleme tehnice atribuite implementărilor lor respective.

După lansarea Windows 8 la sfârșitul anului 2012, s-a descoperit că anumite modele de computere Lenovo cu Secure Boot aveau un firmware codificat pentru a permite încărcarea numai a executabilelor denumite „ Windows Boot Manager ” sau „ Red Hat Enterprise Linux ”, indiferent de setare. Alte probleme au fost întâmpinate de mai multe modele de laptopuri Toshiba cu Secure Boot, cărora le lipseau anumite certificate necesare pentru buna funcționare a acestuia.

În ianuarie 2013, a fost publicat un bug în jurul implementării UEFI pe unele laptop-uri Samsung , ceea ce a determinat blocarea acestora după instalarea unei distribuții Linux în modul UEFI. În timp ce potențialele conflicte cu un modul kernel conceput pentru a accesa caracteristicile sistemului de pe laptopurile Samsung au fost inițial blamate (ceea ce i-a determinat pe mentenanții kernelului să dezactiveze modulul pe sistemele UEFI ca măsură de siguranță), Matthew Garrett a descoperit că eroarea a fost declanșată de fapt prin stocarea prea multor UEFI variabile în memorie și că bug-ul ar putea fi declanșat și în Windows în anumite condiții. În concluzie, el a stabilit că modulul kernel care a ofensat a provocat scrierea în firmware a depozitelor de mesaje ale kernelului, declanșând astfel eroarea.

Vezi si

Note

Referințe

Lecturi suplimentare

linkuri externe