Il Secure Boot è «una nuova funzionalità» di UEFI, non un’invenzione di Microsoft, e perciò GRUB potrà essere in grado di supportarla. Sono le parole di Matthew Garret, sviluppatore di Red Hat, che ha sviluppato ampiamente l’argomento e spiegato perché non soltanto Linux non avrà problemi, ma potrà anche avvantaggiarsi della novità.
Il problema subentra col fatto che Microsoft è l’unica multinazionale in grado di condizionare i produttori per includere le proprie chiavi di cifratura nell’archivio di UEFI per il Secure Boot. In sostanza, la difficoltà nell’avvio di un altro sistema operativo non dipende né dal BIOS, né dal firmware: è una scelta dei produttori.
Soltanto i produttori possono decidere di bloccare la configurazione di UEFI per escludere la disabilitazione del Secure Boot e creare problemi a boot loader diversi da quello di Windows 8, l’unico attualmente compatibile con la nuova infrastruttura. Una scelta che in Europa sarebbe oggetto di “censura” dalla commissione antitrust.
Le opzioni, per l’utente finale, sarebbero almeno due: aggiornare il BIOS con una versione non ufficiale che permetta il controllo del Secure Boot di UEFI oppure non comprare una macchina che ne blocchi le funzionalità. Attualmente, non esistono sistemi che supportino UEFI 2.3.1 in commercio. E perciò il problema ancora non si pone.
Dal punto di vista tecnico, inserire il supporto al Secure Boot di UEFI in GRUB richiederebbe al massimo una settimana di lavoro: il problema è la GPLv3, in contrasto con un’operazione simile. Bisognerebbe realizzare un fork del boot loader utilizzando una licenza differente. Un’opzione ragionevole sulle macchine che lo richiedono.
Nel malaugurato caso in cui un produttore scegliesse d’inibire la rimozione del Secure Boot dalle opzioni del BIOS, insomma, una soluzione si troverebbe. Ammesso e non concesso che l’antitrust europeo ammetta la distribuzione di macchine col BIOS impostato a supportare solo Windows 8. Apple, a dirla tutta, si comporta così da anni.
Via | Matthew Garrett
Seguici
ossblog è un supplemento alla testata Blogo.it registrata presso il Tribunale di Milano n. 487/06, P. IVA 04699900967. Contatti, Chi siamo, Condizioni di utilizzo, Privacy.
© 2004-2012 Blogo.it, alcuni diritti riservati sotto licenza Creative Commons.
Per informazioni pubblicitarie e progetti speciali su Ossblog.it contattare la concessionaria esclusiva Populis Engage.
Kim Allamandola
24 set 2011 - 11:34 - #1Il “Secure Boot” non aggiunge nessuna sicurezza all’utente, non risolve nessun
problema tecnico, serve solo a condizionare la libertà individuale.
La GPLv3 è una GARANZIA per tutti e deve essere rispettata.
Ne consegue che questa caratteristica non deve esistere in commercio, chi provi
ad introdurla deve essere punito con l’immediata sospensione dei suoi prodtti
ed un’ammenda, cosa che andrebbe applicata per ogni prodotto che limiti senza
ragioni le libertà individuali. Questo a tutela dei clienti e delle aziende
stesse che con simili blocchi non possono competere tra loro e con i grandi
gruppi monopolistici.
È utopia? Non è detto, prima del volo umano volare era fantasia, pazzia, utopia
prima delle radiotelecomunicazioni poter comunicare da una parte all’altra
dell’oceano idem. C’è un vecchio detto: “chi troppo vuole nulla stringe” e qui
è già da molto che si pretende troppo.
ghostdog
24 set 2011 - 11:51 - #2qual’è punto della GPL3 entra in conflitto con l’UEFI?
romfladef
24 set 2011 - 12:20 - #3Non è in conflitto con l’UEFI, la GPLv3 (stesso discorso per la GPLv2, Garrett ha spiegato tutto nel dettaglio per chi volesse approfondire ulteriormente): il problema è predisporre delle chiavi di cifratura da inserire nel firmware proprietario da parte dei produttori. Questo è il conflitto che imporrebbe dei fork “proprietari” di GRUB preinstallati dagli OEM. Un po’ come avviene per le Radeon HD col KMS, per cui il firmware è fornito separatamente da X.Org e non è parte dei moduli del kernel perché in conflitto con la GPLv2.
http://mjg59.dreamwidth.org/5552.html
Che il Secure Boot non aggiunga nulla agli utenti è opinabile: personalmente, sono pure d’accordo e avrei preferito che s’evitasse una simile funzionalità. Intel per la sicurezza proporrà qualcosa di simile con l’acquisto di McAfee, anche se (ed è il motivo per cui non mi spaventa l’aggiornamento di UEFI) la commissione antitrust non è molto d’accordo.
Qualcuno ricorda il TCPA/Palladium? Avrebbe dovuto segnare la fine delle copie contraffatte di Windows e l’impossibilità d’installare Linux o altri sistemi operativi alternativi… ha fatto la fine di Carmen San Diego. Che fine ha fatto? Mai realizzato. Col Secure Boot la questione è leggermente diversa. Io credo che alla fine basterà disabilitarlo.
abral
24 set 2011 - 12:45 - #4Apple però non è in posizione dominante come Microsoft.
c1k0
24 set 2011 - 14:39 - #5“Bisognerebbe realizzare un fork del boot loader utilizzando una licenza differente.”
in che modo??? gli sviluppatori che hanno rilasciato il software in GPLv3 dovrebbero rilasciarlo con un’altra licenza, ed a quel punto si parla di dual-license, non di fork.
Mica basta prendere il codice e dire: “adesso lo rilascio in BSD”.
Fare un fork cambiando la licenza in modo arbitrario è… una violazione della licenza :D
foxtrott
24 set 2011 - 15:55 - #6@Kim Allamandola
complimenti sentitissimi per le boiate che hai scritto.
abbano
24 set 2011 - 16:30 - #7“Apple, a dirla tutta, si comporta così da anni.”
Mah…per essere più precisi Apple mi sembra faccia il contrario: non impedisce con EFI di installare altri OS, ma impedisce che l’OS stesso (mac osx) sia installato su macchine non Apple, dove non è presente l’EFI.
@foxtrott
Poco ci manca in effetti :|
sandro-kensan
24 set 2011 - 16:49 - #8UEFI è un tassello importante di Palladium
ilPestifero
24 set 2011 - 17:44 - #9@foxtrott
Complimenti a te per le valide contro argomentazioni.
Quali sarebbero i vantaggi di questo secure boot?
E quali invece gli svantaggi e soprattutto gli utilizzi che qualcuno (microsoft) verosimilmente ne farà?
Per fortuna che la GPLv3 aveva previsto queste derive in anticipo, e almeno ci fa riflettere su quanto tengano a noi le varie multinazionali del software.
waka_jawaka
25 set 2011 - 00:09 - #10Quoto in pieno sandro-kensan.
“La versione iniziale del TC prevedeva che il chip Fritz supervisionasse il processo di avvio, in modo che il Pc sarebbe stato avviato in uno stato conforme con hardware e software conosciuti. La versione corrente vede Fritz come un componente passivo che memorizza l’hash (numero univoco) della macchina allo start up. Questo hash viene calcolato utilizzando i dettagli dell’hardware (scheda audio, video etc..) e del software (Sistema Operativo, drivers, etc..). Se la macchina termina l’avvio in uno stato approvato, Fritz renderà disponibili al sistema operativoo le chiavi crittografiche necessarie per decrittare le applicazioni ed i dati TC. Se, invece, termina in uno stato non conforme allora Fritz non rilascerà la chiave giusta. La macchina sarà ancora in grado di eseguire applicazioni non-TC ed accedere a dati non-TC ma il materiale protetto resterà inaccessibile.”
Da: http://www.interlex.it/675/trustedcomp.htm
in originale:http://www.cl.cam.ac.uk/~rja14/tcpa-faq-1.0.html
Andrea R
25 set 2011 - 09:01 - #11C’è sempre da ricordare che per cambiarti il codice di avvio della macchina, un attaccante deve essere root, e una volta che ciò accade si è comunque nella M.
Questa funzione è da riservare ad ambienti ad alta sicurezza, perchè richiede
che la catena di fiducia sia continuativa: dal bios al bootloader, al kernel, ai driver, ai binari eseguibili e agli script di avvio, al logging via rete.
freeBeforeAll
25 set 2011 - 18:20 - #12Questa non è tecnologia ma, come hanno osservato alcuni, è un cavallo di troia per togliere ulteriori libertà alle persone.
La strategia maligna che c’è dietro non viene certo rivelata.
Si procede per piccoli passi. Una volta implementata nelle future schede madri, il danno sarà fatto e chi c’è dietro non si fermerà certo qui.
Sperare che la commissione antitrust fermerà tale porcheria è solo un atto di fede …
i peggiori incubi di Richard Stallman si stanno avverando …
Kim Allamandola
25 set 2011 - 21:41 - #13@Andrea R #11
che sicurezza ti da un paio di chiavi di firma da te non controllate, inserite
nella EEPROM sulla mobo? Su FreeBSD c’è il securelevel se hai realmente bisogno
di sicurezza. Col “SecureBoot” semmai hai un’ennesima occasione di DOS: tocco
qualcosa ed il SecureBoot mi pianta l’OS a costo zero!
C’è un vecchio detto che dice “le serrature, robuste o fragili, se sono insieme
alle chiavi non servono.”. La Sun su molte macchine metteva una smart card
chiamata SCC (System Configuration Card), senza questa l’OBP (diciamo il BIOS
delle Sun) non funzionava: l’ho vista spesso bloccata con una fascetta per
evitare un’accidentale rimozione…
mauuuuuu
26 set 2011 - 18:07 - #14@Kim Allamandola : che c’entra l’attacco DoS col far piantare l’OS? guarda che DoS non sta per destroy operative system, ma per denial-of-service………
Kim Allamandola
26 set 2011 - 18:49 - #15@mauuuuuu #14
Se ti modifico qualche parte dell’OS per cui il SecureBoot non lo riconosce più
valido ho ottenuto in DOS: la tua macchina non è solo compromessa, non fa del
tutto. Cosa che agli utenti Microsoft regolarmente pieni di virus non so se
piaccia…
Kim Allamandola
26 set 2011 - 18:50 - #16Scusa,
“ho ottenuto un DOS”, “non va del tutto”
snort….
foxtrott
27 set 2011 - 03:41 - #17@ilPestifero che scrive:
“Quali sarebbero i vantaggi di questo secure boot?”
Non ci arrivi da solo? Sei davvero cosi’ poco ferrato dal punto di vista tecnico e vuoi comunque argomentare in materia? ‘namo bene…
@freeBeforeAll che scrive:
“Questa non è tecnologia ma, come hanno osservato alcuni, è un cavallo di troia per togliere ulteriori libertà alle persone.”
Sei un paranoico che non capisce una cippa di quello che scrive, fattene una ragione.
@Kill Amandola che scrive:
“Col “SecureBoot” semmai hai un’ennesima occasione di DOS: tocco
qualcosa ed il SecureBoot mi pianta l’OS a costo zero!”
Se volevi togliere ogni dubbio sulla tua ignoranza in materia ci sei riuscito.
Kim Allamandola
27 set 2011 - 08:02 - #18@foxtrott #17
saresti così cortese da *argomentare*? No perché sparare a zero è facile,
spiegarsi, specie se non si hanno argomenti, non lo è…
Del resto c’è sempre da imparare: insegnaci!
Spiega perché una chiave privata salvata in una eprom dovrebbe darti sicurezza,
la chiave non è diversa macchina per macchina tra l’altro.
Spiega perché un controllo che permette di bloccare l’OS se trova qualcosa di
non firmato non sia un’ottima occasione per un DOS locale.
Spiega che sicurezza ti da una firma digitale la cui chiave privata è in giro
su n macchine.
Spiega che sicurezza ti da rispetto al securelevel, a AppArmour o SELinux su
un sistema in produzione.
In ultimo se vuoi essere così cortese spiega com’è che Microsoft, azienda da
sempre votata alla sicurezza, abbia il più alto numero di vulnerabilità e
problemi di ogni altro OS, seconda solo ad OSX…
Grazie!