Spectre e Meltdown, due bug di sicurezza che sconvolgono il mondo dell'informatica

[s-y]

la mancanza di patch non avrà nessun effetto per la maggioranza degli user di smartphone, purtroppo...

è da tanto che lo scrivo ormai, ma la policy su android deve cambiare, non possono più lasciar fare gli oem come meglio credono. verrà utilizzato meno? pazienza

btw io in (semibramosa) attesa di patch per il bq acquaris che uso. e la bq è tra gli oem 'svegli'...

[Cloud76]

Originariamente inviato da s-y

CUT

Qualcosa con Oreo almeno è cambiato, si chiama Project Treble, con quello dovrebbe essere più semplice aggiornare i terminali.

[pabloski]

AMD ha optato per una soluzione un pelino drastica https://lists.opensuse.org/opensuse-.../msg00004.html

"This new firmware disables branch prediction on AMD family 17h processor"

Ma nel frattempo http://seclists.org/fulldisclosure/2018/Jan/12

Olè i mitici superchipponi tutta cripto che dovevano garantirci pane, lavoro e felicità. Ma levare quelle schifezze di ME e PSP no!?! Giusto per cominciare, neh!

[tallines]

Originariamente inviato da carlottoIIx6

proprio, guarda la tabella http://www.bitsandchips.it/9-hardwar...le-proprie-cpu
in pratica amd ha uno solo dei tre (spectra1, assenti spectra2 e meltdown) che mentre per intel affligge tutti i sistemi operativi e non esiste soluzione software per amd afflige solo linux (in alcuni casi) e ha soluzione software.

Interessante il link che hai postato .

Quindi chi usa un processore AMD in ambito Windows, non è coinvolto ?...........

[TheQ.]

comuque questa mattina si è aggiornato con la stessa patch anche WIN10 con CPU AMD (stesso antivirus dell'altro mio PC). Leggevo sulle news che hanno corretto un altro bug su AMD.

Su AMD l'auslogic benchmark dà risultati migliori.

Sul notebook con Intel:
-Intel extreme tuning vede una variazione dello 0.87% fra prima e dopo patch
-CPU-M indica una variazione del 1.6% nelle prestazioni della CPU
-intelburn test all'incirca uguale
-HWBot indica una perdita di 0.20%
-burnintest dellla passmark indica gli stessi risultati.
-il vecchio benchmark auslogic benchmark indica una variazione dell'8-10%. Questo test però non esegue cicli di calcoli, ma simula grafica 2D, uso CPU, uso HDD/SSD, ecc...

[Erotavlas_turbo]

Originariamente inviato da MaxFabio93

Interessante, grazie per le risorse e le fonti Comunque non griderei al complotto ma piuttosto mi chiederei dove è finita tutta la sicurezza di cui parlava Intel.

Complotto? Già dimenticato lo scandalo Prism nel NSA del 2013 e lo scandalo Vault 7 del 2017 CIA? Queste sono forme volute di controllo da parte degli USA verso gli altri stati dato che le CPU Intel sono prodotte in USA sotto il controllo del governo tramite NSA e CIA.
In realtà, Intel sapeva dei bug delle loro CPU dal 2007 dai tempi dell'architettura core 2 fonte e sembra che abbia modificato la gestione della memoria introducendo e mantenendo i bug.

Originariamente inviato da Marco71

...non dominabile evidentemente nemmeno da "team" di molte persone, progettisti, scienziati ecc. ecc. e non nel settore dei processori per calcolatori-computer di fatto delle enormi macchine a stati finiti.
Questo è un problema nel microcodice dei K8 e K10 AMD ad esempio...e chissà quanti altri ancora ne esistono latenti...

Marco71.

Certo, cambiando il microcodice di una CPU con uno buggato è normale avere la possibilità di mettere trojan. Il ME di Intel è un trojan di questo tipo.

Originariamente inviato da cdimauro

E dov'è la sicurezza di AMD e ARM, visto che pure loro sono afflitte da vulnerabilità?

Leggi il mio primo messaggio. Solo Intel è vulnerabile al bug Meltdown. Riguardo al bug Spectre ARM è coinvolta pienamente mentre AMD solo parzialmente.
Leggi qui

Originariamente inviato da cdimauro

Perché se implementi una cosa e funziona, e si tratta di roba che non cambia nel tempo (parliamo del meccanismo di funzionamento della memoria virtuale, che è codificato ormai da parecchi anni), allora non ci rimetti mano a meno che non trovi, per l'appunto, un errore.

Quindi niente complottismo: si tratta "semplicemente" di una cosa che è diffusa tanto quanto i calcoli elettronici. I famigerati "bug"...

In realtà, Intel sapeva dei bug delle loro CPU dal 2007 dai tempi dell'architettura core 2 fonte e sembra che abbia modificato la gestione della memoria introducendo e mantenendo i bug. Non è complottismo, è la realtà dei fatti. Come negare PRISM, VAULT 7, ME e adesso questo? Solo una persona priva di ragionamento può ignorargli, senza offesa.

Originariamente inviato da cdimauro

Che non risolvono assolutamente le problematiche di cui parla la notizia.

Non è che basta appiccicare la parola "open" su qualcosa per conferirgli un'aura di sicurezza...

Ne abbiamo parlato anche in altre sedi. Un software o hardware closed source non ti garantisce alcuna trasparenza e la storia recente parla chiaro. Le corrispondenti versioni open forniscono trasparenza e permettono di risolvere prima il problema.
Anche Snowden auspica l'adozione di hardware o software open source fonte e lui conosce bene la situazione.

Originariamente inviato da pabloski

AMD ha optato per una soluzione un pelino drastica https://lists.opensuse.org/opensuse-.../msg00004.html

"This new firmware disables branch prediction on AMD family 17h processor"

Si per AMD il bug è solo su linux, al momento hanno optato per la soluzione più drastica, già modificata.

Originariamente inviato da pabloski

Ma nel frattempo http://seclists.org/fulldisclosure/2018/Jan/12

Olè i mitici superchipponi tutta cripto che dovevano garantirci pane, lavoro e felicità. Ma levare quelle schifezze di ME e PSP no!?! Giusto per cominciare, neh!

Mi quoto:
Occorrono CPU e hardware in generale open source a partire dal firmware. Avanti tutta con i progetti coreboot e libreboot che permettono di escludere anche l'altro problema delle CPU Intel https://libreboot.org/faq.html#intel e in parte di quelle AMD https://libreboot.org/faq.html#amd.

[Sandro kensan]

Originariamente inviato da cdimauro

No, non mi riferivo a quello. Il problema di Meltdown è strettamente legato a un bug relativo alla gestione della cache, che viene fuori grazie a precise sequenze di istruzioni che sfruttano l'attuale implementazione dell'architettura basata su esecuzione speculativa e out-of-order.

Il paper (che invito a leggere per chi fosse interessato) ne parla già dall'abstract.

Io per Meltdown ho capito solo questo esempio che si trova in fondo alla pagina dopo molte spiegazioni preliminari:

https://www.raspberrypi.org/blog/why...e-or-meltdown/

mettono insieme il branch prediction con la speculative execution in un bel esempio molto facile da comprendere. Invece il paper che mi hai suggerito di leggere è troppo complicato e non ci sono esempi nel testo che mi permettono di seguire i lunghi discorsi che loro fanno nel paper. Troppo complicato per me questo metodi di apprendimento e comprensione. È come comprendere un teorema senza formule ma con una descrizione a parole come facevano gli antichi: troppo complicato.

Edit: aggiungo che nell'esempio la cache è sfruttato per individuare il dato presente nella memoria privilegiata (kernel memory).In pratica la cache è la cartina di tornasole per distinguere tra un bit a 0 e un bit a 1 di un certo indirizzo nella memoria privilegiata, la distinzione è fatta con i tempi di latenza tra il dato in cache o in RAM.

[Ataru224]

Ma su Windows XP la falla verrà corretta anche se il supporto è terminato?

[Averell]

Originariamente inviato da Ataru224

Ma su Windows XP la falla verrà corretta anche se il supporto è terminato?

(a regola) no.

Ma anche fosse SI, XP (per quanto ancora sia dura da accettare per qualcuno) è esposto ad infiniti modi per scalarne privilegi rispetto ai suoi successori.

Accettatelo perchè è cosi' per cui non occorre scomodare neppure Spectre ecc


Cioè, si parla ancora di un defunto?

[Averell]

Originariamente inviato da Averell

(a regola) no.

Ma anche fosse SI, XP (per quanto ancora sia dura da accettare per qualcuno) è esposto ad infiniti modi per scalarne privilegi rispetto ai suoi successori.

Accettatelo perchè è cosi' per cui non occorre scomodare neppure Spectre ecc


Cioè, si parla ancora di un defunto?

mi spiego meglio:
XP su un Ryzen/Intel 8°gen + flash BIOS etc? (su quelli prima invece mi viene direttamente da ridere)

Piuttosto una martellata sui °° perchè (forse) sarò anche coperto contro Spectre e C. ma sono talmente tanti altri i pericoli REALI in cui posso imbattermi per cui è sprecato anche solo perdere tempo a parlarne.

[Ataru224]

Originariamente inviato da Averell

(a regola) no.

Ma anche fosse SI, XP (per quanto ancora sia dura da accettare per qualcuno) è esposto ad infiniti modi per scalarne privilegi rispetto ai suoi successori.

Accettatelo perchè è cosi' per cui non occorre scomodare neppure Spectre ecc


Cioè, si parla ancora di un defunto?

Speriamo che MS fa un'eccezione anche se XP è fuori supporto perchè mi sembra una falla abbastanza grave

[Averell]

qual'è il senso di sprecare risorse (denaro, sudore,..) su una cosa che E' GIA' A PECORINA a prescindere da questo rischio?

Cioè, se io avessi XP (indipendentemente dalla piattaforma hardware), mi preoccuperei di altro...e questo non lo volete (/potete?) accettare.

XP → CESTINO

Per carità, è stato bello...ma allora viviamo di ricordi e non parliamone più

[Lampetto]

Originariamente inviato da Ataru224

Ma su Windows XP la falla verrà corretta anche se il supporto è terminato?

Per fare un paragone appropriato è come chiedere a Fiat di aggiornare il carburatore della Topolino..
17 anni in informatica corrispondono a 50 annni nelle auto..

Possibile, ma non è garantito

[TheZioFede]

ma xp lo lasciate morire in pace?

[TheZioFede]

Originariamente inviato da s-y

è da tanto che lo scrivo ormai, ma la policy su android deve cambiare, non possono più lasciar fare gli oem come meglio credono. verrà utilizzato meno? pazienza

dubito google dica "pazienza" se si usa di meno

[pabloski]

Originariamente inviato da s-y

è da tanto che lo scrivo ormai, ma la policy su android deve cambiare, non possono più lasciar fare gli oem come meglio credono. verrà utilizzato meno? pazienza

Project Treble, lanciato con Android Oreo serve proprio a questo. Gli OEM non avranno più scuse. E se continuano....beh, sarà ora che i consumatori traggano le dovute conclusioni e agiscano di conseguenza.

[s-y]

Originariamente inviato da TheZioFede

dubito google dica "pazienza" se si usa di meno

Originariamente inviato da pabloski

Project Treble, lanciato con Android Oreo serve proprio a questo. Gli OEM non avranno più scuse. E se continuano....beh, sarà ora che i consumatori traggano le dovute conclusioni e agiscano di conseguenza.

temo non sia abbastanza, e prima o poi 'pazienza' dovrà dirlo secondo me, con aggiornamenti obbligatori e imposti, e se non accetti usi altro os

si, lo so...

[pabloski]

Originariamente inviato da s-y

temo non sia abbastanza, e prima o poi 'pazienza' dovrà dirlo secondo me, con aggiornamenti obbligatori e imposti, e se non accetti usi altro os

si, lo so...

Bella questione. Non so se Google abbia o meno il potere per fare una cosa del genere. Da un lato esistono alternative ad Android, dall'altro queste alternative hanno una frazione delle app di Android.

Se da un lato gli OEM non possono migrare all'istante, dall'altro potrebbero in 4-5 anni farla pagare a Google. Chiaramente non è detto che dall'altra parte troverebbero il bengodi. Un'ipotetica Microsoft o Canonical non gradirebbero trovarsi con terminali su cui girano i loro OS che non vengono aggiornati mai.

Credo che a questo giro gli OEM dovranno correggere il tiro o cominceranno a volare sberle. Considerando pure ormai il tema sicurezza è diventato di dominio pubblico, la pressione da parte degli utenti dovrebbero aumentare nel prossimo futuro.

Penso che quanto successo con Meltdown e Spectre abbia lasciato poca gente che ancora dorme tra due guanciali.

[s-y]

doppio

[s-y]

Originariamente inviato da pabloski

Credo che a questo giro gli OEM dovranno correggere il tiro o cominceranno a volare sberle. Considerando pure ormai il tema sicurezza è diventato di dominio pubblico, la pressione da parte degli utenti dovrebbero aumentare nel prossimo futuro.

su questo non sono così ottimista, ma vedremo
per il resto la ricetta non ce l'ho ci mancherebbe, ma questa situazione del tutto particolare, potrebbe essere la prova che così com'è ora non va bene. se poi chi dovrebbe farlo trarrà le conclusioni, in un mondo dove contano solo i bilanci a tre mesi, mah...
anche perchè alla fine una possibile conseguenza di questo 'richiamo sulla sicurezza agli utenti' potrebbe essere una corsa al cambio terminale, e non sarebbe irreale ipotizzare che ci contino pure gli oem...