Extensible Firmware Interface

Da Wikipedia, l'enciclopedia libera.
Logo di UEFI

EFI è l'acronimo di Extensible Firmware Interface, una tecnologia annunciata inizialmente solo da Intel al momento della presentazione della propria architettura IA-64 del processore Itanium e poi ripresentata in maniera decisamente più consistente insieme a Microsoft a fine 2003. Lo scopo di EFI dovrebbe essere quello di sostituire gradualmente gli attuali BIOS delle schede madri e dopo un timido debutto sul mercato agli inizi del 2006 grazie ai primi iMac Intel Core Duo di Apple, è stata introdotta in volumi solo con i processori Intel Core con architettura Sandy Bridge, dopo esser stata affiancata a un'altra tecnologia Intel arrivata a fine 2005, iAMT per la gestione remota dei sistemi.

Caratteristiche principali[modifica | modifica sorgente]

Secondo Intel, quando verrà adottata in maniera consistente, EFI consentirà ai produttori di integrare nel firmware del computer applicazioni e nuove funzionalità, fra cui strumenti per la diagnostica e il ripristino dei dati, servizi di crittografia e funzionalità per la gestione dei consumi.

EFI dovrebbe anche rendere più semplice la gestione di PC e server da remoto, aiutando così le aziende a ridurre i costi di manutenzione e supporto, e potrà gestire direttamente le connessioni di rete per connettersi ad una LAN o a Internet. A tal proposito i BIOS basati sullo standard EFI saranno dotati di alcune funzionalità specifiche per la gestione delle reti ed, eventualmente, anche di un browser Web. L'altra miglioria promessa da EFI è la capacità di ridurre, anche drasticamente, i tempi di caricamento del sistema operativo e quello di supportare, similmente a quanto succede con i computer palmari, forme di avvio istantaneo. L'EFI ha anche il compito di dotare il firmware del PC di un'interfaccia grafica più amichevole, facile da usare e in grado di supportare le risoluzioni video permesse dalle moderne schede grafiche. In aggiunta a questo, l'EFI fornirà un ambiente per il boot multipiattaforma capace di fornire i servizi base richiesti dai sistemi operativi.

In un certo senso, EFI si può considerare un piccolo sistema operativo dedicato a presiedere tutte quelle operazioni che intercorrono fra l'accensione fisica della macchina e l'avvio del sistema operativo vero e proprio, superando però tutte le problematiche emerse negli anni con gli attuali BIOS. Come tale infatti, sarà in grado di far girare applicazioni di alto livello scritte attraverso strumenti di programmazione standard. Tutto questo verrà reso possibile dal fatto che le interfacce di EFI saranno appoggiate da codice in linguaggio C++, mettendo così definitivamente al bando l'ostico codice assembly degli attuali BIOS.

Sebbene EFI sia già arrivato sul mercato nei nuovi iMac, questi si appoggiano a un chipset proprietario sviluppato da Apple. Il primo chipset di Intel a supportare i BIOS EFI è arrivato all'inizio del 2007 grazie alla piattaforma mobile Santa Rosa basata sul chipset Crestine e il processore Merom, ma non ha incontrato il favore dei produttori di sistemi.

Sistemi Operativi[modifica | modifica sorgente]

Adozione dell'EFI[modifica | modifica sorgente]

A parte la già citata Apple, MSI ha finora proposto schede madri dotate di firmware EFI. A partire da gennaio 2011 tutte le nuove schede madri di Asus implementeranno BIOS EFI, rendendo definitiva l'affermazione di questa tecnologia.

Restrizioni imposte da Microsoft[modifica | modifica sorgente]

Exquisite-kfind.png Per approfondire, vedi Windows RT#Avvio protetto.

Il requisito che i dispositivi certificati per Windows RT devono essere venduti con l'avvio protetto non disattivabile incontrò le critiche soprattutto degli sviluppatori di software libero, che sentivano che Microsoft stava tentando di esercitare il vendor lock-in impedendo agli utenti di installare sistemi operativi alternativi come Linux.

Il 20 settembre 2011 Matthew Garrett, uno sviluppatore di Red Hat, segnalò il possibile rischio che Microsoft avrebbe potuto escludere i sistemi operativi alternativi dai dispositivi certificati per Windows 8,[6] dando origine ad un'ampia copertura mediatica sull'argomento.[7][8] Secondo Garrett, se gli OEM si fossero limitati a includere nei loro dispositivi la sola chiave privata di Microsoft, all'utente non sarebbe stato permesso di avviare né Linux né alcun altro sistema operativo all'infuori di Windows 8. L'adozione di versioni firmate di Linux in sistemi regolarmente dotati delle relative chiavi UEFI avrebbe per giunta fatto sorgere delle ulteriori problematiche: per esempio, non si sarebbe potuto utilizzare il boot loader GRUB perché la versione 3 della licenza GPL con cui è concesso richiede che il distributore fornisca all'utente tutte le chiavi di autorizzazione necessarie per installare il software.[9]

Il team di sviluppo di Windows 8 assicurò in seguito nel blog ufficiale Building Windows 8 che gli OEM sarebbero stati liberi di personalizzare il loro firmware, per esempio offrendo un'opzione per disattivare l'avvio protetto.[10]

Il 28 ottobre 2011 Canonical e Red Hat, due delle maggiori società coinvolte in Linux, pubblicarono un libro bianco sulla questione, esortando i produttori ad includere nei PC un'interfaccia utente per attivare o disattivare facilmente l'avvio protetto.[11]

Nel gennaio 2012 suscitò nuove preoccupazioni,[12][13] in particolare nella comunità Linux,[14] un documento in cui Microsoft stabiliva che, a differenza dei PC basati sulle architetture IA-32 e x86-64, i dispositivi basati su architettura ARM sarebbero stati esclusi dal programma di certificazione per Windows RT se avessero consentito la disattivazione dell'avvio protetto.[15] Adrian Kingsley-Hughes di ZDNet suggerì tra le altre ipotesi che Microsoft stesse escludendo gli altri sistemi per motivi di vendor lock-in.[16] Matthew Garrett intanto evidenziò le difficoltà nell'implementazione dell'avvio protetto in Linux, tra cui la complicazione del processo di installazione di un sistema operativo alternativo e la difficoltà nel persuadere gli OEM a vendere computer con la chiave alternativa insieme alla chiave Microsoft.[17]

I requisiti contrattuali Microsoft, al contrario di quanto previsto dalle specifiche UEFI, impongono che il kernel e i suoi moduli devono essere firmati; Microsoft si riserva il diritto di revocare qualsiasi certificato usato per firmare del codice che può essere usato per compromettere la sicurezza del sistema.[18] Nel febbraio 2013, uno sviluppatore di Red Hat ha tentato di applicare una patch al kernel di Linux che consentirebbe ad esso di analizzare la firma Authenticode di Microsoft usando una chiave X.509 master incorporata in file PE firmati da Microsoft, ma la scelta è stata criticata da Linus Torvalds, il creatore di Linux.[19]

Il 26 marzo 2013 il gruppo spagnolo di sviluppo di software libero Hispalinux ha depositato una lamentela formale presso la Commissione europea, contestando il fatto che i requisiti per l'avvio protetto imposti da Microsoft sui sistemi OEM sono ostruttivi e anti-competitivi.[20]

Soluzioni adottate dai sistemi operativi alternativi[modifica | modifica sorgente]

Alcune importanti distribuzioni Linux hanno sviluppato dei workaround per aggirare le restrizioni imposte da Microsoft. Lo stesso Matthew Garrett ha sviluppato un boot loader minimo noto come shim; un boot loader precompilato e firmato che consente all'utente di considerare attendibili le chiavi fornite dai distributori.[21]

Fedora Linux[modifica | modifica sorgente]

Siccome Microsoft non ha stabilito alcuna imposizione riguardo alla possibilità di installare certificati di terze parti che permetterebbero l'esecuzione di software alternativo,[17] gli sviluppatori di Fedora Linux hanno scelto di acquistare per la versione 18 di Fedora una chiave di sicurezza, da VeriSign al prezzo scontato di 99 $ tramite il Centro per sviluppatori Windows,[22][23] sollevando alcune critiche nella comunità Linux.[24][25]

La chiave acquistata è stata impiegata per firmare il boot loader shim, che serve per svolgere un unico compito: si limita infatti a verificare l'integrità di GRUB e a caricarlo, poiché anche GRUB e il kernel (a sua volta caricato da GRUB) sono firmati, anche se con chiavi generate dal progetto Fedora.[9]

Ubuntu[modifica | modifica sorgente]

Per assicurarsi di non violare la licenza di GRUB, Ubuntu ha adottato al suo posto il boot loader efilinux, firmato con una chiave generata da Canonical. Secondo la Free Software Foundation, tuttavia, la preoccupazione degli sviluppatori di Ubuntu di violare la licenza di GRUB è infondata.[26]

efilinux ha poi il compito di avviare un'immagine del kernel non firmata, al contrario del kernel di Fedora che invece è firmato. Gli sviluppatori di Ubuntu credono che la firma del solo boot loader sia una soluzione più fattibile, poiché un kernel fidato renderebbe sicuro solo lo spazio dell'utente e non lo stato pre-avvio del sistema (che l'avvio protetto è progettato per proteggere), e inoltre vogliono permettere agli utenti di creare e utilizzare i propri moduli di kernel personalizzati.[27]

L'avvio dei CD di Ubuntu al contrario si basa su una soluzione analoga a quella scelta da Fedora: i CD di Ubuntu fanno uso del boot loader shim, lo stesso di Fedora, firmato con una delle chiavi esistenti certificate da Microsoft.[28]

Canonical ha dichiarato che non offrirà la propria chiave privata per firmare i boot loader di altri distributori e venditori, ma imporrà agli OEM certificati di offrire anche la chiave privata Microsoft oltre a quella di Canonical per evitare di escludere dalle macchine con Ubuntu preinstallato i sistemi operativi che si appoggiano ad una chiave Microsoft, come Fedora e Windows 8.[9]

Ubuntu ha aggiunto il supporto all'avvio protetto UEFI a partire dalla versione 12.10.[29]


Nell'ottobre 2012, prima della pubblicazione di Windows 8, la Linux Foundation ha annunciato di stare sviluppando un boot loader UEFI minimo firmato con una chiave Microsoft che servirà per avviare il boot loader principale. Tuttavia, per mantenere la sicurezza e per impedire che il boot loader venga utilizzato per caricare silenziosamente del malware, l'avvio richiederà l'input dell'utente.[30]

Voci correlate[modifica | modifica sorgente]

Collegamenti esterni[modifica | modifica sorgente]

Note[modifica | modifica sorgente]

  1. ^ Versione EFI di Grub (Debian GNU/Linux). URL consultato il 27/03/2011.
  2. ^ Storia dei rilasci di HP OpenVMS. URL consultato il 27/03/2011.
  3. ^ http://refit.sourceforge.net/info/vista.html. URL consultato il 27/03/2011.
  4. ^ Microsoft Windows Server TechCenter. "Extensible Firmware Interface". URL consultato il 27/03/2011.
  5. ^ "Microsoft determined that vendors would not have any interest in producing native UEFI 32-bit firmware because of the current status of mainstream 64-bit computing and platform costs. Therefore, Microsoft has chosen not to ship support for 32-bit UEFI implementations.". URL consultato il 27/03/2011.
  6. ^ (EN) Matthew Garrett, UEFI secure booting, mjg59's journal, 20 settembre 2011. URL consultato il 18 febbraio 2012 (archiviato il 18 febbraio 2012).
  7. ^ (EN) Jon Brodkin, Windows 8 secure boot could complicate Linux installs, Ars Technica, 21 settembre 2011. URL consultato il 18 febbraio 2012 (archiviato il 18 febbraio 2012).
  8. ^ (EN) John Leyden, Windows 8 secure boot would 'exclude' Linux, The Register, 21 settembre 2011. URL consultato il 18 febbraio 2012 (archiviato il 18 febbraio 2012).
  9. ^ a b c (EN) Nathan Willis, Ubuntu details its UEFI secure boot plans, LWN.net, 27 giugno 2012. URL consultato il 12 settembre 2012 (archiviato il 12 settembre 2012).
  10. ^ (EN) Tony Mangefeste, Protecting the pre-OS environment with UEFI, Building Windows 8, 22 settembre 2011. URL consultato il 18 febbraio 2012 (archiviato il 18 febbraio 2012).
  11. ^ (EN) Victor Tuson Palau, White Paper: Secure Boot impact on Linux, Canonical Blog, 28 ottobre 2011. URL consultato il 18 febbraio 2012 (archiviato il 18 febbraio 2012).
  12. ^ (EN) Aaron Williamson, Microsoft confirms UEFI fears, locks down ARM devices, Software Freedom Law Center, 12 gennaio 2012. URL consultato il 4 marzo 2012 (archiviato il 4 marzo 2012).
  13. ^ (EN) Tom Warren, Windows 8 ARM devices won't have the option to switch off Secure Boot, The Verge, 16 gennaio 2012. URL consultato il 4 marzo 2012 (archiviato il 4 marzo 2012).
  14. ^ (EN) Joey Sneddon, Microsoft to Prevent Linux Booting on ARM Hardware?, OMG! Ubuntu!, 13 gennaio 2012. (archiviato il 25 febbraio 2012).
  15. ^ (EN) Windows 8 Hardware Certification Requirements - Windows 8 System Requirements (PDF), MSDN, 16 dicembre 2011, p. 116. URL consultato il 4 marzo 2012 (archiviato il 4 marzo 2012).
    «Disabling Secure MUST NOT be possible on ARM systems.».
  16. ^ (EN) Adrian Kingsley-Hughes, Why is Microsoft locking out all other OSes from Windows 8 ARM PCs & devices?, ZDNet, 13 gennaio 2012. URL consultato il 18 febbraio 2012 (archiviato il 18 febbraio 2012).
  17. ^ a b (EN) Matthew Garrett, Why UEFI secure boot is difficult for Linux, mjg59's journal, 17 gennaio 2012. URL consultato l'11 settembre 2012 (archiviato l'11 settembre 2012).
  18. ^ (EN) No Microsoft certificate support in Linux kernel says Torvalds, The H Open, 26 febbraio 2013. URL consultato il 26 febbraio 2013 (archiviato il 26 febbraio 2013).
  19. ^ (EN) Jon Brodkin, Linus Torvalds: I will not change Linux to “deep-throat Microsoft”, Ars Technica, 26 febbraio 2013. URL consultato il 26 febbraio 2013 (archiviato il 26 febbraio 2013).
  20. ^ (EN) Sarah Morris, Exclusive: Open software group files complaint against Microsoft to EU, Reuters, 26 marzo 2013. URL consultato il 26 marzo 2013 (archiviato il 26 marzo 2013).
  21. ^ (EN) Steven J. Vaughan-Nichols, Shimming your way to Linux on Windows 8 PCs, ZDNet, 4 dicembre 2012. URL consultato il 26 febbraio 2013 (archiviato il 26 febbraio 2013).
  22. ^ (EN) Tim Burke, UEFI Secure Boot, Red Hat, 5 giugno 2012. URL consultato il 15 giugno 2012 (archiviato il 15 giugno 2012).
  23. ^ (EN) Matthew Garrett, Implementing UEFI Secure Boot in Fedora, mjg59's journal, 30 maggio 2012. URL consultato il 15 giugno 2012 (archiviato il 15 giugno 2012).
  24. ^ (EN) Steven J. Vaughan-Nichols, Linus Torvalds on Windows 8, UEFI, and Fedora, ZDNet, 10 giugno 2012. URL consultato il 15 giugno 2012 (archiviato il 15 giugno 2012).
  25. ^ (EN) Jonathan Corbet, Fedora, secure boot, and an insecure future, LWN.net, 5 giugno 2012. URL consultato il 15 giugno 2012 (archiviato il 15 giugno 2012).
  26. ^ (EN) John Sullivan, Free Software Foundation recommendations for free operating system distributions considering Secure Boot, Free Software Foundation, 30 giugno 2012. URL consultato il 9 luglio 2012 (archiviato il 9 luglio 2012).
  27. ^ (EN) Jamie Strandboge, UEFI Secure Boot and Ubuntu - implementation, Mailing list ubuntu-devel, 25 giugno 2012. URL consultato il 12 settembre 2012 (archiviato il 12 settembre 2012).
  28. ^ (EN) Steve Langasek, Colin Watson; Jeremy Kerr, UEFI Secure Boot and Ubuntu - implementation, Mailing list ubuntu-devel, 22 giugno 2012. URL consultato il 12 settembre 2012 (archiviato il 12 settembre 2012).
  29. ^ (EN) Ubuntu will use GRUB 2 for its Secure Boot implementation, The H Online, 21 settembre 2012. URL consultato il 28 ottobre 2012 (archiviato il 29 ottobre 2012).
  30. ^ (EN) Peter Bright, Linux Foundation to offer signed solution for UEFI Secure Boot conundrum, Ars Technica, 12 ottobre 2012. URL consultato il 12 ottobre 2012 (archiviato il 12 ottobre 2012).
Informatica Portale Informatica: accedi alle voci di Wikipedia che trattano di Informatica