offerte prime day amazon

Ubuntu 17.10.1 rilasciato senza driver Intel SPI che corrompe l'UEFI

Ubuntu 17.10.1 rilasciato senza driver Intel SPI che corrompe l'UEFI

La peculiare situazione creata da alcuni produttori che usano una versione non-standard dell'UEFI ha portato Ubuntu a corrompere l'UEFI su alcuni modelli. Una nuova versione del sistema operativo corregge (aggirandolo) il problema

di pubblicata il , alle 08:21 nel canale Sistemi Operativi
UbuntuLinux
 

Canonical ha rilasciato ufficialmente una nuova ISO di Ubuntu 17.10 - passato ora alla versione 17.10.1 - con una soluzione al problema della corruzione dell'UEFI emerso qualche settimana fa.

Ubuntu 17.10.1 risolve il problema della corruzione dell'UEFI semplicemente disabilitando il driver per Intel SPI che causava la corruzione. Di fatto quindi non è stata trovata una soluzione reale al problema; questo è dovuto in parte al fatto che i firmware corrotti non sarebbero stati standard e richiederebbero lavoro specifico.

Una soluzione alla corruzione è stata trovata e richiede l'installazione del kernel 4.14.9 e due successivi riavvii. In questo modo sembrerebbe che i problemi di impossibilità di salvare le modifiche alle impostazioni e di avviare il sistema da supporti USB vengano risolti.

Così come Ubuntu, anche le varie versioni con altri ambienti desktop verranno aggiornate con la soluzione, come riportato da Phoronix. Da notare, però, che queste ISO non contengono già aggiornamenti importanti come quelli per proteggersi da Meltdown e Spectre e sarà dunque necessario installarli manualmente dopo il primo avvio.

Resta aggiornato sulle ultime offerte

Ricevi comodamente via email le segnalazioni della redazione di Hardware Upgrade sui prodotti tecnologici in offerta più interessanti per te

Quando invii il modulo, controlla la tua inbox per confermare l'iscrizione.
Leggi la Privacy Policy per maggiori informazioni sulla gestione dei dati personali

33 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info
The FoX16 Gennaio 2018, 08:49 #1

Uefi: lo standard "sbagliato".

Ottima idea.
Ottimo standard.
Almeno sulla carta.
Poi si è lasciata libertà ai produttori di fare quel che gli pareva... ed i risultati si sono visti.
Una cosa così importante e fondamentale non può e non deve essere lasciata alla discrezionalità ed all' "estro" dei singoli produttori.
L'UEFI DEVE essere posto sono un'autorità di controllo che ne certifichi gli aspetti implementativi. E di conseguenza l'aderenza e la compatibilità allo standard stesso.
Altrimenti casi come questo si ripeteranno ciclicamente anche in futuro.
E magari la prossima volta potrebbe essere windows la vittima... con danni molto maggiori.
zappy16 Gennaio 2018, 09:18 #2
è figlio della stupida idea che "nuovo è meglio".
in realtà è ormai da anni che un prodotto più vecchio è sotto vari aspetti "migliore" di quello nuovo, il quale non apporta reali benefici tangibili.
lemuel17 Gennaio 2018, 00:41 #3

Perché non ripartire da zero?

Se si voleva migliorare la situazione che il boot con il BIOS determinava, con i limiti noti, si potevano scegliere molte strade.
Quella adottata invece, dato il grande potere dei colossi dell'informatica sul settore, cioè UEFI, è un parto degenere figlia del ben noto "Diritto proprietario".
Con la ormai condivisa scusa e giustificazione a livello planetario per "ammodernare" e combattere rootkit e altro, si è inventato un sistema farraginoso e pieno di falle, di fatto per impedire l'utilizzo di software "non gradito", non tanto perché "malevolo", ma più perché non deve "disturbare gli interessi dei manovratori".
Personalmente per me il problema nasce dal fatto che sia il BIOS che l'UEFI sono software (di tipo "firmware", se vogliamo) installabili, aggiornabili (e "inoculabili" con estrema facilità.
Ricordo con disgusto le tante banali risposte ad altrettante futili discussioni sul malfunzionamento di componenti hardware su vari forum in giro sul web, che si concludevano spesso con la solita domandina (da "Pierino": "Hai aggiornato il BIOS"? Tale aggiornamento in effetti avrebbe risolto solo l'un per mille dei problemi.
Troppa facilità di modifica del BIOS.
In tempi più remoti, per aggiornare il BIOS (o "flasharlo", come scrivono i nuovi dotti creatori di neologismi), occorreva aprire il "case" del computer e commutare un microswitch nella opportuna posizione.
E bisognava utilizzare un FloppyDisk contenente software e applicazione di avvio.
Poi bisognava riportare il microswitch nella posizione "off" iniziale e si poteva sperare di avere il BIOS aggiornato al riavvio del sistema.
Troppo macchinoso per i "bulletti" del PC.
Meglio lanciare direttamente da Windows senza nessuna protezione hardware e magari beccarsi un malware (soluzione "molto" efficiente per i portatili).

E intanto, in entrambi i casi, cosa sarebbe successo se fosse mancata la alimentazione elettrica (e magari senza batteria)? Un grande casino, giacché poi il sistema non si sarebbe più potuto avviare, dato che non si sarebbe potuto ripetere l'aggiornamento, a causa del fatto evidente che nessuna periferica di "input" sarebbe stata riconosciuta.
Ecco allora tutti i vari video e forum su come sostituire "macchinosamente" il chip del BIOS con uno eguale e con la macchina alimentata.
Roba per equilibristi dell'elettronica.
Ma non sarebbe stato meglio fare in modo che almeno una periferica, quella del floppy, ad esempio, fosse stata stabilmente riconosciuta dal BIOS, tramite un chip dedicato, esclusivo, solo per far ripartire un floppy autopartente e ricaricare il BIOS senza problemi?
Troppo costoso? Troppo difficile?
No. Troppo autodafé senza problemi, cosa che non piace a chi governa lo scenario dell'informatica. Bisogna "sempre" prima o poi finire in un laboratorio, o nelle mani di un tecnico autorizzato, se si mette mano dentro al computer.

Analogamente per l'UEFI.
Ma intanto, perché non rendere pubblico il codice sorgente sia dei BIOS che dell'UEFI? Cos'è, c'è rischio che possa venire studiato e che vi si scoprano falle, utili per i famosi "malintenzionati" di cui spesso Microsoft fa cenno "preoccupata" (ma non dell'NSA), per inoculare codice malevolo?

Ma allora, ad esempio, siccome Linux ha un codice sorgente noto a chiunque lo voglia, come mai non si sono ancora attivati "milioni" di "malintenzionati" per bucare Linux e carpire i segreti degli utenti e delle aziende che lo usano? Senza parlare dei server?

Insomma, fintantoché certi software devono essere nelle mani dei soliti noti, dobbiamo tutti sottostare alle loro scelte ed alla politica dei "certificati" riconosciuti e validi.
Ma la politica dei " certificati" non è anch'essa figlia di un certo modo di scrivere i software per gli utenti? Come ad esempio i sistemi operativi?
Ovvero, siccome tutto l'"ambaradan" è partito 50 anni fa, con regole e criteri validi allora, è chiaro che oggi, dopo milioni di "patch" e "fix" tutto il sistema software è un enorme casino ingarbugliato a tal punto che bisogna ricorrere continuamente a criteri di autenticazione fra i più assurdi e macchinosi, oltre che segreti e nelle mani di pochi, sempre coloro che continuano a dettare le regole, a monte delle quali c'è però sempre e soprattutto, per chi non l'avesse capito (o facesse finta di non capire), la priorità assoluta del "Diritto proprietario".

Bene, a questo punto io comincerei a spazzare via tutto ciò che è stato fatto finora, chiamerei tutti i programmatori seri e competenti a spogliarsi della filosofia con la quale sono stati cresciuti e alimentati, e rimboccandoci le maniche ripartirei da zero a riscrivere daccapo tutto il sistema di software "portante" necessario a rifondare su basi diverse l'informatica nella parte applicativa e dei sistemi operativi.
Magari cercando una volta per tutte di limitare i concetti del "Diritto proprietario" sulle applicazioni, e non sui sistemi operativi, o perlomeno sui "kernel" di questi, in modo da avere codice aperto e trasparente.
E riversare questo standard di operare anche sui sistemi di avvio, di boot diretto dell'hardware delle macchine odierne.
Allo stesso modo definirei uno standard per governare la babele dei driver per l'hardware, e chiederei codice aperto anche per questi.
E chiederei codice aperto e controllabile anche per i firmware di ogni chip, compresa la CPU e la GPU.
Secondo me, questa sarebbe la strada migliore.
Coraggiosa, sì, faticosa, ma pronta a prepararsi ad un futuro in cui non si possa correre il rischio che con poche righe di codice un "malintenzionato" possa creare i prossimi "millennium" e "planetarium" crash di tutti i sistemi con la stessa facilità con la quale può farlo adesso.
cdimauro17 Gennaio 2018, 06:42 #4
Ne avete già sparlato nella notizia della corruzione del firmware a causa dell'implementazione errata, avete avuto le vostre risposte, ma puntualmente ritrovo gli stessi personaggi che, anziché approfondire quanto gli è stato detto e cercare di capire perché l'UEFI è stato creato e quali vantaggi ha portato, tornano nuovamente a ripetere esattamente le stesse cose, come un disco rotto.

Non c'è proprio speranza che i tuttologi internettiani possano apprendere finalmente qualcosa. Purtroppo l'ignoranza continua ad andare di moda...
jepessen17 Gennaio 2018, 09:31 #5
Originariamente inviato da: lemuel
...cut...


Qua si fa sempre il solito errore, non considerando il software un prodotto industriale rispetto ad altri, per il semplice fatto che si tratta di puro software invece che di hardware.

Perche' mai le aziende che forniscono software dovrebbero essere costrette a rilasciare il loro codice sorgente, oppure ad effettuare una rivoluzione di software ilbero? Sono loro prodotti, sviluppati da loro, e posso anche capire le scelte aziendali che non distribuiscono il codice corrispondente. Molte aziende rilasciano il software che producono con licenza open source, e' vero, ma sono aziende che 1) campano su licenze proprietarie a pagamento con feature aggiuntive e testate dalla comunita' open source, o 2) fatturano sui servizi e assistenza che danno a chi utilizza il software. C'e' sempre un riscontro economico, e se la filosofia dell'azienda si basa sul vendere il software, dimostrare come sia controproducente permettere agli altri di compilare il codice e' lasciato come esercizio al lettore.

Quando compri una macchina per caso ci sono anche i progetti? I file CAD della scocca e cosi' via? Quando compri un televisore c'e' il progetto della scheda elettronica?

No, e la cosa li' e' perfettamente normale, solamente che dato che si tratta di hardware nessuno si fa problemi, in caso di software invece, dato che si tratta di roba 'intangibile', per qualche motivo tutti i sentono in diritto di avere il codice, perche' tanto loro sono sempre piu' preparati di chi lavora da anni nel settore.

Io adoro l'open source, ho diversi progetti cui contribuisco su GitHub, ad esempio, ma l'azienda per cui lavoro ha anche diversi software chiusi, ed anche se ci sono bellissime idee dentro non mi sognerei mai di andarle a rendere disponibili per tutti, perche' sono dell'azienda. Punto. Vero, con l'opensource puoi aspettarti miglioramenti da parte della comunita' (Qt, ad esempio, e' un favoloso esempio), ma non sempre il gioco vale la candela.

Rendere un software open source o meno e' una scelta aziendale, e non c'e' una soluzione migliore dell'altra. I problemi, come questo, capitano? Si, ma non e' un motivo valido per esigere (manco chiedere per cortesia) tutto il codice sorgente (che poi voglio vedere quanta gente che usa software open source si va a leggere il codice di LibreOffice, per dirne una).

Questi sono problemi che nel mondo dell'industria capitano. Quando c'e' stato il DieselGate, perche' la gente non urlava a gran voce di rendere disponibili i progetti dei motori, per poter scovare i 'bachi' e modificare il motore per renderlo piu' pulito? Perche' l'utente comune sa che non ha dimestichezza per il pezzo di ferro, quindi non ci tenta neppure. Per qualche strano motivo, invece, la maggior parte e' convinta di programmare meglio di ingegneri e programmatori che passano anni a formarsi ed a lavorare su certi progetti, solo perche' riescono a fare un hello world oppure ad accendere un led su Arduino (sempre l'effetto Dunning-Kruger, insomma).

Se pensi di avere le capacita' di rifondare le basi dell'informatica e rivoluzionare il mondo, accomodati, nessuno te lo impedisce, e verremo tutti a baciarti i piedi se ci riuscirai, ma non pretendere che le aziende lo facciano perche', forse forse, hanno un po' piu' di conoscenze e magari sanno che quella strada al momento non porta da nessuna parte. Ma se per te la rivoluzione e' rendere disponbile i sorgenti di Windows e dei BIOS, mi sa che di strada ancora ce n'e'...
GTKM17 Gennaio 2018, 09:41 #6
Originariamente inviato da: jepessen
Qua si fa sempre il solito errore, non considerando il software un prodotto industriale rispetto ad altri, per il semplice fatto che si tratta di puro software invece che di hardware.

Perche' mai le aziende che forniscono software dovrebbero essere costrette a rilasciare il loro codice sorgente, oppure ad effettuare una rivoluzione di software ilbero? Sono loro prodotti, sviluppati da loro, e posso anche capire le scelte aziendali che non distribuiscono il codice corrispondente. Molte aziende rilasciano il software che producono con licenza open source, e' vero, ma sono aziende che 1) campano su licenze proprietarie a pagamento con feature aggiuntive e testate dalla comunita' open source, o 2) fatturano sui servizi e assistenza che danno a chi utilizza il software. C'e' sempre un riscontro economico, e se la filosofia dell'azienda si basa sul vendere il software, dimostrare come sia controproducente permettere agli altri di compilare il codice e' lasciato come esercizio al lettore.

Quando compri una macchina per caso ci sono anche i progetti? I file CAD della scocca e cosi' via? Quando compri un televisore c'e' il progetto della scheda elettronica?

No, e la cosa li' e' perfettamente normale, solamente che dato che si tratta di hardware nessuno si fa problemi, in caso di software invece, dato che si tratta di roba 'intangibile', per qualche motivo tutti i sentono in diritto di avere il codice, perche' tanto loro sono sempre piu' preparati di chi lavora da anni nel settore.

Io adoro l'open source, ho diversi progetti cui contribuisco su GitHub, ad esempio, ma l'azienda per cui lavoro ha anche diversi software chiusi, ed anche se ci sono bellissime idee dentro non mi sognerei mai di andarle a rendere disponibili per tutti, perche' sono dell'azienda. Punto. Vero, con l'opensource puoi aspettarti miglioramenti da parte della comunita' (Qt, ad esempio, e' un favoloso esempio), ma non sempre il gioco vale la candela.

Rendere un software open source o meno e' una scelta aziendale, e non c'e' una soluzione migliore dell'altra. I problemi, come questo, capitano? Si, ma non e' un motivo valido per esigere (manco chiedere per cortesia) tutto il codice sorgente (che poi voglio vedere quanta gente che usa software open source si va a leggere il codice di LibreOffice, per dirne una).

Questi sono problemi che nel mondo dell'industria capitano. Quando c'e' stato il DieselGate, perche' la gente non urlava a gran voce di rendere disponibili i progetti dei motori, per poter scovare i 'bachi' e modificare il motore per renderlo piu' pulito? Perche' l'utente comune sa che non ha dimestichezza per il pezzo di ferro, quindi non ci tenta neppure. Per qualche strano motivo, invece, la maggior parte e' convinta di programmare meglio di ingegneri e programmatori che passano anni a formarsi ed a lavorare su certi progetti, solo perche' riescono a fare un hello world oppure ad accendere un led su Arduino (sempre l'effetto Dunning-Kruger, insomma).

Se pensi di avere le capacita' di rifondare le basi dell'informatica e rivoluzionare il mondo, accomodati, nessuno te lo impedisce, e verremo tutti a baciarti i piedi se ci riuscirai, ma non pretendere che le aziende lo facciano perche', forse forse, hanno un po' piu' di conoscenze e magari sanno che quella strada al momento non porta da nessuna parte. Ma se per te la rivoluzione e' rendere disponbile i sorgenti di Windows e dei BIOS, mi sa che di strada ancora ce n'e'...


Una nota: dietro Qt ci sono sempre state aziende di un certo livello.
jepessen17 Gennaio 2018, 09:56 #7
Originariamente inviato da: GTKM
Una nota: dietro Qt ci sono sempre state aziende di un certo livello.


Infatti l'ho preso come esempio di aziende che campano (bene) distribuendo software open source.
GTKM17 Gennaio 2018, 10:03 #8
Originariamente inviato da: jepessen
Infatti l'ho preso come esempio di aziende che campano (bene) distribuendo software open source.


Intendevo che le Qt sono cosi' buone non tanto per i miglioramenti offerti dalla comunita', quanto perche' dietro ci sono sempre state aziende belle grosse.

Poi, ovvio che facciano i soldi, visto quanto costa una licenza per un prodotto closed.
jepessen17 Gennaio 2018, 10:12 #9
Originariamente inviato da: GTKM
Intendevo che le Qt sono cosi' buone non tanto per i miglioramenti offerti dalla comunita', quanto perche' dietro ci sono sempre state aziende belle grosse.

Poi, ovvio che facciano i soldi, visto quanto costa una licenza per un prodotto closed.


Come la maggior parte del software open source di un certo livello. Tutti gridano alla liberta', ma se vai, ad esempio, a vedere il log di git per vedere chi ci lavora, per la maggior parte sono tutte grosse aziende, come IBM, e pochi contributi dal programmatore della domenica.

Qt campa bene perche' sviluppano feature, le rilasciano LGPL per aumentare il numero di persone che lo conosce, e poi quando serve per scopi commerciali, si fanno pagare la licenza.

Chi fa progetti piccoli ed open source infatti non acquista una licenza Qt, se lo dovesse fare passerebbe semplicemente ad altro. Fanno pagare la licenza a chi serve ed a chi puo' permetterselo, un po' come le versioni Community di Visual Studio, che puoi utilizzarle per fare i programmi che vuoi pero' con limitazioni sul team e sull'azienda, per cui se sei una media-grossa azienda invece devi comprare la versione Professional, che e' esattamente uguale licenza a parte. Se non fosse cosi' gli hobbisti passerebbero che so, ad Eclipse o Netbeans, e non farebbe bene alla base di utenza di Visual Studio.

Quindi open-source e gratis per le aziende in realta' non lo sono, perche' hanno sempre un riscontro (ma sono aziende, e' ovvio, altrimenti come li pagano i dipendenti? In visibilita?)
GTKM17 Gennaio 2018, 11:20 #10
Originariamente inviato da: jepessen
Come la maggior parte del software open source di un certo livello. Tutti gridano alla liberta', ma se vai, ad esempio, a vedere il log di git per vedere chi ci lavora, per la maggior parte sono tutte grosse aziende, come IBM, e pochi contributi dal programmatore della domenica.

Qt campa bene perche' sviluppano feature, le rilasciano LGPL per aumentare il numero di persone che lo conosce, e poi quando serve per scopi commerciali, si fanno pagare la licenza.

Chi fa progetti piccoli ed open source infatti non acquista una licenza Qt, se lo dovesse fare passerebbe semplicemente ad altro. Fanno pagare la licenza a chi serve ed a chi puo' permetterselo, un po' come le versioni Community di Visual Studio, che puoi utilizzarle per fare i programmi che vuoi pero' con limitazioni sul team e sull'azienda, per cui se sei una media-grossa azienda invece devi comprare la versione Professional, che e' esattamente uguale licenza a parte. Se non fosse cosi' gli hobbisti passerebbero che so, ad Eclipse o Netbeans, e non farebbe bene alla base di utenza di Visual Studio.

Quindi open-source e gratis per le aziende in realta' non lo sono, perche' hanno sempre un riscontro (ma sono aziende, e' ovvio, altrimenti come li pagano i dipendenti? In visibilita?)


Penso, d'altronde, sia l'unico business model possibile con l'open-source.

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^