Luca Annunziata

Linux fa pace con UEFI

Nel kernel finiscono le patch per arginare il problema sorto con alcuni laptop. Lo conferma Torvalds. E ci sono novità anche sulla faccenda Secure Boot

Roma - Il problema scoperto la scorsa settimana, che causa il blocco irreversibile di alcuni portatili Samsung (e pare anche di altri marchi) che montano firmware UEFI e tentano di installare la distribuzione Ubuntu, si avvia a una risoluzione. Nel kernel Linux sono state inserite le patch necessarie a eliminare incidenti di questo tipo, esiste una soluzione tampone per chi non avesse modo di scaricare l'ultima release disponibile del kernel, e nelle prossime settimane tutte le distro coinvolte apporteranno le modifiche necessarie per eliminare l'incidente alla radice.

La questione è nata a causa di una incomprensione tra chi ha scritto il driver kernel per i laptop Samsung che montano UEFI e Samsung stessa. L'implementazione di entrambe le componenti pare fosse fuori standard, e la congiunzione astrale di queste due "imperfezioni" ha causato il guaio: ora tutto si avvia a risolversi per il meglio, e gli utenti dovranno solo badare ad evitare di usare software non aggiornato sulle proprie macchine.

Nel frattempo Linux Foundation fa sapere che ci sono novità anche per la questione SecureBoot: il "pre-bootloader" annunciato è arrivato alla fase di sperimentazione sul campo, anche se non è ancora adatto a essere distribuito al pubblico. In ogni caso il lavoro della Foundation prosegue, e non dovrebbe ormai mancare troppo alla soluzione definitiva della faccenda. (L.A.)
26 Commenti alla Notizia Linux fa pace con UEFI
Ordina
  • Meglio il vecchio Bios ...e basta con queste stupidaggini del secure boot ! ...ma dove s'è mai vista che che per l'incompetenza di un'azienda che macina milioni di dollari devono essere gli altri ad adeguarsi ai suoi casini ?
    non+autenticato
  • - Scritto da: Etype
    > Meglio il vecchio Bios ...e basta con queste
    > stupidaggini del secure boot ! ...ma dove s'è mai
    > vista che che per l'incompetenza di un'azienda
    > che macina milioni di dollari devono essere gli
    > altri ad adeguarsi ai suoi casini ?

    Bah meglio il vecchio bios fino ad un certo punto, c'è di bello che efi permette lo sviluppo del firmware con sistemi più moderni e senza passare per il vetusto assembly ma alla fine non ne risolve completamente i limiti quindi una mezza evoluzione portata avanti da chi cerca fondamentalmente di blindare il sistema fin dal suo avvio e poco di più.
    mura
    1615
  • - Scritto da: mura

    > Bah meglio il vecchio bios fino ad un certo
    > punto, c'è di bello che efi permette lo sviluppo
    > del firmware con sistemi più moderni e senza
    > passare per il vetusto assembly ma alla fine non
    > ne risolve completamente i limiti quindi una
    > mezza evoluzione portata avanti da chi cerca
    > fondamentalmente di blindare il sistema fin dal
    > suo avvio e poco di
    > più.

    va bene per la prima parte,però dai mettere il secure boot non è altro che un controllo per tener lontani i concorrenti e per far dessitere gli utenti che sono alle prime armi ad altri Os ....
    non+autenticato
  • - Scritto da: Etype

    > va bene per la prima parte,però dai mettere il
    > secure boot non è altro che un controllo per
    > tener lontani i concorrenti e per far dessitere
    > gli utenti che sono alle prime armi ad altri Os

    Assolutamente d'accordo, mettere sistemi come questo in un PC che per definizione è una scatola vuota sulla quale far girare il software che si vuole è un cercare di limitare la libertà dell'utente con la scusa del più sicuro.
    mura
    1615
  • - Scritto da: Etype
    > Meglio il vecchio Bios ...e basta con queste
    > stupidaggini del secure boot

    Avere una catena di chiavi di cifratura sicure in hardware non è una cosa stupida, se usate bene la sicurezza ne può guadagnare.
    non+autenticato
  • - Scritto da: Ignazio
    > - Scritto da: Etype
    > > Meglio il vecchio Bios ...e basta con
    > > queste stupidaggini del secure boot

    > Avere una catena di chiavi di cifratura
    > sicure in hardware non è una cosa stupida, se
    > usate bene la sicurezza ne può guadagnare.

    Appunto, ma in questo caso non sono assolutamente usate bene per la sicurezza, altrimenti l'utente potrebbe mettere le proprie chiavi.

    Sta venendo implementato come sistema di controllo non di sicurezza, diffidiamo.
    krane
    22544
  • Da qualsiasi punto di vista si tratta di una fregatura.
  • - Scritto da: Sandro kensan
    > Da qualsiasi punto di vista si tratta di una
    > fregatura.

    Concordo. E più che mai do ragione a Stallman. I computer devono essere liberi a partire da bootloader, passando per il kernel, fino al software applicativo. Bisogna evitare di comprare computer che producono questi signori, che si stanno dando da fare per sodomizzarci. Anche a costo di comprare hardware più scadente. Se non aiutiamo economicamente (comprando i loro prodotti) quelle aziende che sono corrette con noi ma aiutiamo a ingrassare questi signori non dobbiamo poi brontolare quando ci inchia****ano. Ma ce l'ho ancora di più con quelli che hanno portato al fork dal movimento Free Software e lo hanno ribatezzato "Open Source" per opportunismo, e accettano anche nel kernel tutte quelle porcherie dei blob proprietari. Io lavoro esclusivamente sui desktop, che me li assemblo da solo, e per andare in giro ho un vecchio netbook che funziona da dio, ma quando quello schiatta, ci penserò magari a un netbook Lemote o qualcosa del genere. UNo completamente libero.
    non+autenticato
  • perche`? Fin tanto che l'utente sara` libero di usare le chiavi scelte a suo insindacabile giudizio, non mi pare che potere usufruire di un sistema operativo firmato sia un male.
    Certo se invece che il Secure Boot implementeranno il Restricted Boot allora sono d'accordo con te, ma e' presto per dirlo.

    Quanto al caso specifico Samsung io dico: ma che cavolo, un test non lo potevano fare? Bacchettata sia a Samsung sia a Greg Kroah-Hartman (anche se direi almeno 80% samsung, non piu` del 20% lui)!
  • - Scritto da: pentolino
    > perche`? Fin tanto che l'utente sara` libero di
    > usare le chiavi scelte a suo insindacabile
    > giudizio, non mi pare che potere usufruire di un
    > sistema operativo firmato sia un male.

    Peccato che non sia affatto cosi, le chiavi non sono ne' detenute ne' generabili dall'utente.

    > Certo se invece che il Secure Boot
    > implementeranno il Restricted Boot allora
    > sono d'accordo con te, ma e' presto per dirlo.

    La situazione attualmente e' proprio questa, in futuro non si sa ma al momento le chiavi non sono in mano all'utente e non c'e' nessuna previsione di mettercele peraltro.

    > Quanto al caso specifico Samsung io dico: ma che
    > cavolo, un test non lo potevano fare? Bacchettata
    > sia a Samsung sia a Greg Kroah-Hartman (anche se
    > direi almeno 80% samsung, non piu` del 20% lui)!

    Il caso specifico temo sia solo la punta dell'iceberg.
    krane
    22544
  • - Scritto da: krane
    > Peccato che non sia affatto cosi, le chiavi non
    > sono ne' detenute ne' generabili
    > dall'utente.

    fin tanto che si puo` installare il bootloader shim puo` andare

    > La situazione attualmente e' proprio questa, in
    > futuro non si sa ma al momento le chiavi non sono
    > in mano all'utente e non c'e' nessuna previsione
    > di mettercele
    > peraltro.

    e' per questo che stanno mettendo a punto la soluzione "shim"; e` un compromesso, ma meglio che niente.

    > Il caso specifico temo sia solo la punta
    > dell'iceberg.

    speriamo di no, chi vivra` vedra`, sarebbe ben triste vedere tramontare il software libero...
  • - Scritto da: pentolino
    > - Scritto da: krane
    > > Peccato che non sia affatto cosi, le
    > > chiavi non sono ne' detenute ne'
    > > generabili dall'utente.

    > fin tanto che si puo` installare il
    > bootloader shim puo` andare

    Lo dicevano anche i linari ogni volta che windows gli brasava il boot sector, e dopo anni qualcuno ancora non tutti si sono accorti di essere finiti in un baratro monopolistico da cui non se ne usciva. Vogliamo ricaderci ? Veramente ?

    > > La situazione attualmente e' proprio
    > > questa, in futuro non si sa ma al
    > > momento le chiavi non sono in mano
    > > all'utente e non c'e' nessuna previsione
    > > di mettercele peraltro.

    > e' per questo che stanno mettendo a punto la
    > soluzione "shim"; e` un compromesso, ma
    > meglio che niente.

    NO, e' proprio meglio niente, questo e' il punto.

    > > Il caso specifico temo sia solo la punta
    > > dell'iceberg.

    > speriamo di no, chi vivra` vedra`, sarebbe ben
    > triste vedere tramontare il software libero...

    Sarebbe solo il secondo tentativo, di quanti tentativi hai bisogno per convincertene ?
    krane
    22544
  • soluzioni?
  • - Scritto da: pentolino
    > soluzioni?

    Assicurarsi di non comprare questo blotware ed informare a 360 gradi tutti quelli che si conoscono.
    krane
    22544
  • hai qualche link a cui riferirmi dove ci siano informazioni su quale hardware moderno si possa acquistare senza Restricted Boot?
    Non sto trollando, e` che non puoi dire alle persone: non comprare un computer nuovo fin tanto che Restricted Boot non sara` sconfitto
  • - Scritto da: pentolino
    > hai qualche link a cui riferirmi dove ci siano
    > informazioni su quale hardware moderno si possa
    > acquistare senza Restricted Boot?
    > Non sto trollando, e` che non puoi dire alle
    > persone: non comprare un computer nuovo fin tanto
    > che Restricted Boot non sara` sconfitto

    Giusto: facciamo una lista, chiedo la collaborazione di un po' chi voglia, intanto cerco in rete se c'e' qualcosa di simile a cui riferirsi.
    krane
    22544
  • guarda, qui spiega molto bene come funziona Secure Boot:

    http://superuser.com/questions/525889/if-i-buy-a-c...

    per farla breve la certificazione MS richiede che il Secure Boot sia disattivabile dall'utente; che ne pensi?
  • "non dovrebbe ormai mancare troppo alla soluzione definitiva della faccenda." dice Annunziata... e' MOLTO ottimista il ragazzo.

    Pur sapendo gia' che UEFI + secureboot era fondamentalmente un inchiapettata per l'utente (e in particolare quello non-M$), nel weekend mi son voluto divertire guardando un po di documenti su EFI (intel,apple) le 3 rev di UEFI, secureboot e GPT. E commenti sulle reali implementazioni. Sono dolori da parecchi punti di vistaA bocca storta

    Per 0.99cent magari vi scrivo un articoloSorride
    non+autenticato
  • - Scritto da: bubba
    > "non dovrebbe ormai mancare troppo alla soluzione
    > definitiva della faccenda." dice Annunziata... e'
    > MOLTO ottimista il ragazzo.

    > Pur sapendo gia' che UEFI + secureboot era
    > fondamentalmente un inchiapettata per l'utente (e
    > in particolare quello non-M$), nel weekend mi son
    > voluto divertire guardando un po di documenti su
    > EFI (intel,apple) le 3 rev di UEFI, secureboot e
    > GPT. E commenti sulle reali implementazioni. Sono
    > dolori da parecchi punti di vista
    >A bocca storta

    Link link !!! Sono in inglese vero ? Perplesso

    > Per 0.99cent magari vi scrivo un articoloSorride

    Cacchio te li do' Occhiolino
    krane
    22544
  • > > Per 0.99cent magari vi scrivo un articoloSorride
    > Cacchio te li do' Occhiolino

    IL

    Linari...
    non+autenticato
  • - Scritto da: krane
    > - Scritto da: bubba
    > > "non dovrebbe ormai mancare troppo alla
    > soluzione
    > > definitiva della faccenda." dice
    > Annunziata...
    > e'
    > > MOLTO ottimista il ragazzo.
    >
    > > Pur sapendo gia' che UEFI + secureboot era
    > > fondamentalmente un inchiapettata per
    > l'utente
    > (e
    > > in particolare quello non-M$), nel weekend
    > mi
    > son
    > > voluto divertire guardando un po di
    > documenti
    > su
    > > EFI (intel,apple) le 3 rev di UEFI,
    > secureboot
    > e
    > > GPT. E commenti sulle reali implementazioni.
    > Sono
    > > dolori da parecchi punti di vista
    > >A bocca storta
    >
    > Link link !!! Sono in inglese vero ? Perplesso
    ahah, si. ma non e' niente di particolarmente segreto ehSorride dunque vediamo

    ho letto un po di specifiche da http://www.uefi.org/specs/ (ottime anche le slides http://www.uefi.org/learning_center )

    C'e' il framwork opensource tianocore ( con EDK = EFI Developer Kit e il suo EDK II). Utile per capire delle cose "fuori" dalle major che cucinano realmente il firmware. Originariamente era (e') roba di Intel per EFI. [ http://sourceforge.net/apps/mediawiki/tianocore/in... e altro ]
    Anche le voci sulla bistrattata wikipedia sono utili.

    Poi http://mjg59.dreamwidth.org/ , l'omino ex-Redhat esperto di UEFI & secureboot e http://www.rodsbooks.com/ esperto di GPT,uefi e creatore del bootmanager rEFInd.
    Poi ci sono varie keyword interessanti tipo "uefi gop fastboot", "uefi blackhat" ecc.

    Da tutto cio si ricavano molte cose interessanti... impox scriverle bene (ci vorrebbe un articolo o due). Ne cito 3 brevissimamente e imprecisamente...
    1) una delle principali motivazioni usate per "vendere" l'uefi come un beneficio per l'END-user rispetto il BIOS, e' che il bios, col suo disk scheme MBR, non riesce a indirizzare hdisk maggiori di 2.1Tera. In se e' vero, MA il nuovo disk-scheme ( GPT > protective MBR ) e' perfettamente utilizzabile anche su piattaforme Bios-based ( basta solo che sia un minimo collaborativo ). Il problema in realta' e' "un certo OS", che e'/e' stato handicappato (win7 ia32 col bios+gpt non va. win7 x64 richiede uefi. L'hack dell MBR hybrid non lo conto)

    2) il BIOS esegue il firmware (option rom) contenuto nelle schede pci (express). Anche UEFI fa lo stesso. Solo che NON puo essere lo stesso codice ,SPECIALMENTE se dev'essere firmato digitalmente per via del secureboot.
    E qua i casini si fanno molteplici... (in parte anche a seconda della versione di uefi e del framework). Se uefi prevede il CSM (legacy), non ci sono problemi... ma a quel punto tantovale non averlo il UEFICon la lingua fuori
    I primi casini forse li incontri col Graphics Output Protocol (GOP), proto abilitato dal UEFI driver per supportate la "console" grafica in fase di pre-boot (scopo finale rimpiazzare il vga legacy bios code). Problema: la scheda di 1 anno fa, non ha il firmware uefi adatto (possono e fanno schede con codice bios e uefi. Ma se lo spazio sul chip non basta? E se non fanno gli aggiornamenti? Se il monitor CRT/LCD non supporta il refresh/risoluzione forzato da uefi?). Semplice = cambi scheda o disabiliti uefi. Sono brutale,ma in svariati casi e' cosi.
    Poi c'e molto altro.

    3) al blackhat han fatto vedere che UEFI (senza secureboot) e' piu gustoso e violentabile del bios (ovvio. e' quasi un mini-os)

    (3.1 - non ho parlato del secureboot... che per ora e' una vera violenza per tutti gli utenti non windoze. E anche in futuro rimarra' una palla al piede, a meno di scenari clamorosi)

    Supersintesi, in a long distant future forse UEFI sara' un ottima cosa ... ma per ora va MOLTO bene come giocattolo per hackers & co. Per il resto MEGLIO bios + gpt + ipxeCon la lingua fuori

    > > Per 0.99cent magari vi scrivo un articoloSorride
    >
    > Cacchio te li do' Occhiolino
    ahah. No era una proposta per P.I.Sorride mai estorcerei dalla gente 0.99cent... mica sono Ruppolo.
    non+autenticato
  • Se avessero veramente le palle, invece di metterci il bios o efi potrebbero provare a mettere il microkernel L4. Quello sarebbe VERAMENTE innovativo. (Sì, si può installare un sistema operativo nella memoria flash riservata al bios o a EFI: avevo visto dei tutorial per installarci il dos, in modo da avviare anche senza disco di sistema)

    Su L4 è infatti possibile far girare qualunque sistema operativo, o anche più sistemi operativi in contemporanea:

    http://os.inf.tu-dresden.de/L4/LinuxOnL4/inaction....

    Oppure, si possono eseguire più istanze dello stesso sistema operativo (sarebbe una soluzione molto più efficiente rispetto alla classica virtualizzazione). Il riavvio del computer si potrebbe effettuare senza tempi morti: infatti si potrebbe aprire una nuova istanza del sistema operativo e poi, quando questa si è avviata, si potrebbe chiudere quella vecchia (così un server non avrebbe nemmeno un secondo di downtime)

    Il microkernel, di per sè, è estremamente stabile e non dovrebbe richiedere aggiornamenti:

    http://punto-informatico.it/2716370/PI/News/microk...

    Inoltre, sarebbe possibile realizzare i driver per le varie periferiche in funzione di L4, ed in questo modo non ci sarebbe più nessun problema di compatibilità con i diversi sistemi operativi: windows, linux, freebsd... agirebbero tutti chiamando il microkernel, che girerebbe le richieste ai driver specifici. In questo modo, si darebbe nuova linfa allo sviluppo di nuovi sistemi operativi.
    non+autenticato
  • - Scritto da: bubba
    > - Scritto da: krane
    > > - Scritto da: bubba
    > > > "non dovrebbe ormai mancare troppo alla
    > > soluzione
    > > > definitiva della faccenda." dice
    > > Annunziata...
    > > e'
    > > > MOLTO ottimista il ragazzo.
    > >
    > > > Pur sapendo gia' che UEFI + secureboot era
    > > > fondamentalmente un inchiapettata per
    > > l'utente
    > > (e
    > > > in particolare quello non-M$), nel weekend
    > > mi
    > > son
    > > > voluto divertire guardando un po di
    > > documenti
    > > su
    > > > EFI (intel,apple) le 3 rev di UEFI,
    > > secureboot
    > > e
    > > > GPT. E commenti sulle reali
    > implementazioni.
    > > Sono
    > > > dolori da parecchi punti di vista
    > > >A bocca storta
    > >
    > > Link link !!! Sono in inglese vero ? Perplesso
    > ahah, si. ma non e' niente di particolarmente
    > segreto ehSorride dunque
    > vediamo
    >
    > ho letto un po di specifiche da
    > http://www.uefi.org/specs/ (ottime anche le
    > slides http://www.uefi.org/learning_center
    > )
    >
    > C'e' il framwork opensource tianocore ( con EDK =
    > EFI Developer Kit e il suo EDK II). Utile per
    > capire delle cose "fuori" dalle major che
    > cucinano realmente il firmware. Originariamente
    > era (e') roba di Intel per EFI. [
    > http://sourceforge.net/apps/mediawiki/tianocore/in
    > Anche le voci sulla bistrattata wikipedia sono
    > utili.
    >
    > Poi http://mjg59.dreamwidth.org/ , l'omino
    > ex-Redhat esperto di UEFI & secureboot e
    > http://www.rodsbooks.com/ esperto di GPT,uefi e
    > creatore del bootmanager
    > rEFInd.
    > Poi ci sono varie keyword interessanti tipo "uefi
    > gop fastboot", "uefi blackhat"
    > ecc.
    >
    > Da tutto cio si ricavano molte cose
    > interessanti... impox scriverle bene (ci vorrebbe
    > un articolo o due). Ne cito 3 brevissimamente e
    > imprecisamente...
    > 1) una delle principali motivazioni usate per
    > "vendere" l'uefi come un beneficio per l'END-user
    > rispetto il BIOS, e' che il bios, col suo disk
    > scheme MBR, non riesce a indirizzare hdisk
    > maggiori di 2.1Tera. In se e' vero, MA il nuovo
    > disk-scheme ( GPT > protective MBR ) e'
    > perfettamente utilizzabile anche su piattaforme
    > Bios-based ( basta solo che sia un minimo
    > collaborativo ). Il problema in realta' e' "un
    > certo OS", che e'/e' stato handicappato (win7
    > ia32 col bios+gpt non va. win7 x64 richiede uefi.
    > L'hack dell MBR hybrid non lo
    > conto)
    >
    > 2) il BIOS esegue il firmware (option rom)
    > contenuto nelle schede pci (express). Anche UEFI
    > fa lo stesso. Solo che NON puo essere lo stesso
    > codice ,SPECIALMENTE se dev'essere firmato
    > digitalmente per via del
    > secureboot.
    > E qua i casini si fanno molteplici... (in parte
    > anche a seconda della versione di uefi e del
    > framework). Se uefi prevede il CSM (legacy), non
    > ci sono problemi... ma a quel punto tantovale non
    > averlo il UEFI
    >Con la lingua fuori
    > I primi casini forse li incontri col Graphics
    > Output Protocol (GOP), proto abilitato dal UEFI
    > driver per supportate la "console" grafica in
    > fase di pre-boot (scopo finale rimpiazzare il vga
    > legacy bios code). Problema: la scheda di 1 anno
    > fa, non ha il firmware uefi adatto (possono e
    > fanno schede con codice bios e uefi. Ma se lo
    > spazio sul chip non basta? E se non fanno gli
    > aggiornamenti? Se il monitor CRT/LCD non supporta
    > il refresh/risoluzione forzato da uefi?).
    > Semplice = cambi scheda o disabiliti uefi. Sono
    > brutale,ma in svariati casi e'
    > cosi.
    > Poi c'e molto altro.
    >
    > 3) al blackhat han fatto vedere che UEFI (senza
    > secureboot) e' piu gustoso e violentabile del
    > bios (ovvio. e' quasi un
    > mini-os)
    >
    > (3.1 - non ho parlato del secureboot... che per
    > ora e' una vera violenza per tutti gli utenti non
    > windoze. E anche in futuro rimarra' una palla al
    > piede, a meno di scenari
    > clamorosi)
    >
    > Supersintesi, in a long distant future forse UEFI
    > sara' un ottima cosa ... ma per ora va MOLTO
    > bene come giocattolo per hackers & co. Per il
    > resto MEGLIO bios + gpt + ipxe
    >Con la lingua fuori
    >
    > > > Per 0.99cent magari vi scrivo un articolo
    >Sorride
    > >
    > > Cacchio te li do' Occhiolino
    > ahah. No era una proposta per P.I.Sorride mai
    > estorcerei dalla gente 0.99cent... mica sono
    > Ruppolo.

    Grazie, interessantissimo e pieno di spunti, se mai ci incontreremo ti devo un caffe'.
    krane
    22544
  • - Scritto da: krane

    > > Da tutto cio si ricavano molte cose
    > > interessanti... impox scriverle bene (ci
    > vorrebbe
    > > un articolo o due). Ne cito 3
    > brevissimamente
    > e
    > > imprecisamente...
    (..)

    > > 2) il BIOS esegue il firmware (option rom)
    > > contenuto nelle schede pci (express). Anche
    > UEFI
    >(..)
    > > il refresh/risoluzione forzato da uefi?).
    > > Semplice = cambi scheda o disabiliti uefi.
    > Sono
    > > brutale,ma in svariati casi e'
    > > cosi.
    > > Poi c'e molto altro.
    Mi autoquoto per chi mai dovesse leggere... in questo appunto notturno sono forse stato troppo enfatico.. nel senso che certe cose che sembrano affermazioni secche, sono piu' inconsistenze,interpretazioni creative nell'implementazione, e dubbi (miei)... paranoie? mhh...pero' non e' che me le sono inventate.
    Che ci siano incompatibilita'/rogne con un sistema uefi e pci non-uefi lo si puo vedere da thread con Mac-Pro e nvidia non-efi, controller ITE, bug tipo http://www-947.ibm.com/support/entry/portal/docdis... ecc.. ecc..

    ...mhh.. stavo per fare un pippone di dubbi & co, ma no, vien troppo lungoCon la lingua fuori
    Partiamo da questo : uefi, senza secureboot, e' PIU hackable del bios (anzi e' gia prevista una ver ulteriore 'Measured Boot' con chip TPM/TCG, perche il secureboot e' ancora "poco") [1]...
    Il secure pero' obbliga [1] a questo
    UEFI Driver Signing utilizes Microsoft Authenticode Technology to sign UEFI executable
    • Secure Boot should check these signatures …
    – UEFI Drivers loaded from PCI-Express cards
    – Drivers loaded from mass storage and USB
    ((buono per i venditori di hardware e, a spanne, per M$. MOLTO meno per il portafoglio e i non M$-user))
    (( aggiungiamo i Dubbi su [1] "UEFI Signing is not required for …
    – Drivers in the factory BIOS
    – Legacy components used only during legacy boots
    (( il legacy e' di fondamentale importanza capire com'e' gestito. Perche da un lato rende vana la security, dall'altro impedisce all'hw di funzionare in fase di pre-boot (e dopo?) ))

    Altre docs [2] iniziano con
    Model for add-on drivers & OpROM
    –Generic model for multiple architectures
    –Designed to solve OEM, IBV & IHV problems (( cioe i produttori. e gli utenti con 'vecchie' pci ? ))
    Il [2] e' molto enfatico sulla separazione tra specs UEFI, framework sottostanti e collaborazione/coding degli OEM. (( Ma nella realta' sappiamo che collaborano abbastanza poco. specie se l'hw/pci sono 'vecchie' ))
    Mi riferisco anche a interessanti affermazioni come
    " Many UEFI drivers are packaged as an OpROM
    • PCI spec allows multiple OpROM images on a device
    –Includes Legacy x86 & UEFI
    • UEFI firmware sets platform policy for running OpROM
    e anche
    UEFI firmware “policy” can change
    –Example: Run legacy OpROM or UEFI first?
    –IBV/OEM/ODM policy may be different
    "

    Interessanti, in quest'ottica, anche http://mjg59.dreamwidth.org/16280.html e paragrafo "Q: Only machines that want to boot Windows need to carry Microsoft's keys" di http://mjg59.dreamwidth.org/10971.html

    [1] http://www.uefi.org/learning_center/UEFI_Plugfest_...
    [2] http://www.uefi.org/learning_center/UPFS11_P6_Opti...

    Azzo... e' venuto lungo comunqueA bocca aperta

    >
    > Grazie, interessantissimo e pieno di spunti, se
    > mai ci incontreremo ti devo un
    > caffe'.
    lol grazieSorride
    non+autenticato