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

[Sandro kensan]

Originariamente inviato da cdimauro

Esattamente.

In realtà si potrebbe fare altro. Il tuo sarebbe un caso particolare, mentre problematiche di questo tipo ce ne sono diverse, che non verrebbero risolte con la tua idea.

Serve una soluzione più generale al problema.

No, in questo caso, non essendo mappata alcuna memoria del kernel, è proprio impossibile accedervi. Dunque non esisterebbe nessuna kern_mem[address]: tutta la memoria che il processo vede è solo ed esclusivamente sua.

Ecco perché con la separazione degli spazi d'indirizzamento di kernel e user land, il problema è risolto proprio a monte.

Mi piacerebbe un link di altri problemi che tu citi così da farmi una idea più chiara della complessità di Meltdown.

Ma quando dici "Ecco perché con la separazione degli spazi d'indirizzamento di kernel e user land, il problema è risolto proprio a monte" mi fa venire in mente che non è necessario separare i due spazi di memoria ma solo accedere alla memoria privilegiata senza i trucchi permessi dall'esecuzione speculativa.

[Yrbaf]

L'articolo di HWUpgrade è impreciso.

L'esecuzione fuori ordine non centra proprio nulla (da sola almeno).

La causa del problema è la gestione della cache assieme all'esecuzione speculativa.

Vero che l'esecuzione speculativa è spesso presente solo in processori out of order, ma non sono la stessa cosa e ci posso essere anche processori out of order che non implementano l'esecuzione speculativa.

L'esecuzione speculativa non è niente di speciale e non è legata ai processi o al kernel, è semplicemente il non fermare / stallare la pipeline quando si incontra un salto (jump).
Ogni istruzione di salto genera una biforcazione del codice, se il salto avviene si deve proseguire dall'indirizzo indicato nel salto e se il salto non avviene si prosegue con l'istruzione successiva al salto.

Il problema è che se il salto avviene o non avviene lo si sa troppo tardi quindi il processore ha due scelte.
Fermarsi per sapere il risultato del salto e poi procedere, ma questo causa stalli della pipeline e perdita di prestazioni o proseguire scegliendo lui (predizione di salto in base a varie tecniche da quelle semplici tipo "salto sempre fatto se all'indietro e salto mai fatto se in avanti" a quelle più raffinate che richiedono storia dei salti passati e ...) una delle due strade e proseguire senza fermarsi.
Se la predizione di salto sarà stata azzeccata si avrà una prestazione massimale (come se il salto non fosse mai esistito) e se la predizione è sbagliata bisognerà annullare l'effetto delle istruzioni eseguite erroneamente come se queste non fossero mai state eseguite, con ovviamente perdita prestazionale.

L'esecuzione fuori ordine è invece la possibilità di eseguire istruzioni non nell'ordine del programma se tali istruzioni non hanno dipendenze tra di loro.
Es.
...
C=A*B
D=C+2
E=A+3
...
In un processore con esecuzione in ordine E sarebbe calcolato dopo (o al più in parallelo) che è stato calcolato D che a sua volta per forza deve aspettare che sia stato calcolato C, mentre in un processore con out of order, verrebbe iniziato il calcolo di C, D sarebbe messo in pausa causa dipendenze ma nel frattempo verrebbe calcolato E.
Di fatto il calcolo di E avverrebbe prima di D e quindi l'esecuzione è fuori ordine (solo l'esecuzione materiale è fuori ordine i risultati devono essere comunque sempre presentati in ordine per conservare la semantica del codice).
E questo non centra con l'esecuzione speculativa anche se di solito l'esecuzione speculativa è presente solo in processori che sono anche out of order.

PS
Anche sulle CPU senza speculazione hw ci sono delle tecniche per minimizzare il costo dei salti (es. i delay slot usati su Mips, l'uso di istruzioni condizionali per evitare l'uso di salti su Arm ed altre cpu)

[cdimauro]

Originariamente inviato da Sandro kensan

Mi piacerebbe un link di altri problemi che tu citi così da farmi una idea più chiara della complessità di Meltdown.

Gli altri non riguardano Meltdown. Ma al momento preferisco non parlarne perché sto elaborando delle soluzioni a queste problematiche, e non so ancora cosa farci.

Ma quando dici "Ecco perché con la separazione degli spazi d'indirizzamento di kernel e user land, il problema è risolto proprio a monte" mi fa venire in mente che non è necessario separare i due spazi di memoria ma solo accedere alla memoria privilegiata senza i trucchi permessi dall'esecuzione speculativa.

Se vuoi continuare ad avere i due spazi di memoria condivisi ovviamente devi risolvere il problema dell'accesso ai dati "non tuoi" (del kernel, nello specifico) pur lavorando in maniera speculativa.

@Yrbaf: in questo caso si parla propriamente di esecuzione speculativa E out-of-order, perché non c'è alcun salto coinvolto, ma una violazione di privilegio che comporta il sollevamento di un'eccezione (che si potrebbe considerare un salto, in fin dei conti), che però ha dato ugualmente dato seguito al caricamento di dati del kernel in cache (da cui la "speculazione").

[Yrbaf]

Ok se c'è speculazione c'è un cambio di PC quindi di fatto l'equivalente di un salto, poi che sia una istruzione di salto esplicita o una eccezione importa di meno.

Non ho letto gli articoli originali ma ancora non capisco cosa centri l'esecuzione out of order (che tra l'altro non vedo, ma magari vedrei se vedessi i testi originali).
Il colpevole pare solo l'esecuzione speculativa e la relativa gestione della cache che non fa un Undo completo (o non lo fa abbastanza velocemente dando tempo di leggerla) degli effetti delle istruzioni speculative.

Comunque in ogni caso anche se centrasse da sola non basterebbe, un processore out of order senza speculazione (e ci sono o c'erano) non dovrebbe soffrire del problema.
Come non soffrono i processori in order perché di solito sono tutti senza speculazione.

[cdimauro]

Sì, il paper originale (che trovi nel sito di Meltdown che è stato tirato sù appositamente) spiega molto meglio il tutto, mostrando anche le istruzioni eseguite dal processore, e perché funziona con l'esecuzione out-of-order.

[Sandro kensan]

Originariamente inviato da Yrbaf

Non ho letto gli articoli originali ma ancora non capisco cosa centri l'esecuzione out of order (che tra l'altro non vedo, ma magari vedrei se vedessi i testi originali).
Il colpevole pare solo l'esecuzione speculativa e la relativa gestione della cache che non fa un Undo completo (o non lo fa abbastanza velocemente dando tempo di leggerla) degli effetti delle istruzioni speculative.

Anch'io ho capito che se c'è una esecuzione speculativa allora le tracce vengono lasciate in un modo o nell'altro in quanto potrebbe essere che l'azione coinvolga la cache in certi casi oppure la memoria normale in altri per cui misurando le latenze si vengono a scoprire i dati della memoria privilegiata.

Ma cdimauro afferma che il vincolo (forse imposto dai produttori di processori che non hanno spazio di azione col microcodice) è quello di non toccare l'esecuzione speculativa sia per quanto riguarda l'out of order che i branch.

[DacocaD]

Si potrebbe programmare un browser che venga eseguito unicamente sulla GPU ? ( magari non le Intel )
Così eliminiamo la gestione di dati sensibili da parte del processore centrale

Per sicurezza vado a depositare il brevetto. Questa idea è da Nobel !!!

[rockroll]

Originariamente inviato da ROBHANAMICI

why? E' un problema generalizzato.

Non è uno ma più problemi (sostanzialmente 3), e solo Intel è coinvolta in tutti. La pezza SW più impattante prestazionalmente riguarda un problema solo di CPU Intel, ed altri rappezzamenti per gli altri problemi non risolvono completamente, ma AMD assicura che ne è coinvolta solo marginalmente.
https://pbs.twimg.com/media/DSrds-iXkAE1BWY.jpg

Ora che le cose si sanno, ti sembra così strano come reagiscono i mercati?

Tieni anche presente che se chi ha la gran parte del mercato è maggiormente coinvolta in fattori negativi, il deprezzamento anche di poco delle sue azioni ha come conseguenza un aumento ben più marcato di quelle della concorrenza meno coinvolta.
Su un mercato (x86/64) che in volumi vale 100 poniamo che Intel valga 80, Amd 10 ed Altri 10, se Intel perde il 10% passando a 72%, e questo viene rimpiazzato da AMD e Altri, ognuno dei due acquisirà 4 punti percentuali degli 8 persi da intel, passando da 10% a 14% con un incremento percentuale del 40%. In queste proporzioni è esattamente quanto sta succedendo (-5% per Intel, +20% per AMD e per Altri).

[rockroll]

Originariamente inviato da Yrbaf

L'articolo di HWUpgrade è impreciso.

L'esecuzione fuori ordine non centra proprio nulla (da sola almeno).

La causa del problema è la gestione della cache assieme all'esecuzione speculativa.

Vero che l'esecuzione speculativa è spesso presente solo in processori out of order, ma non sono la stessa cosa e ci posso essere anche processori out of order che non implementano l'esecuzione speculativa.

L'esecuzione speculativa non è niente di speciale e non è legata ai processi o al kernel, è semplicemente il non fermare / stallare la pipeline quando si incontra un salto (jump).
Ogni istruzione di salto genera una biforcazione del codice, se il salto avviene si deve proseguire dall'indirizzo indicato nel salto e se il salto non avviene si prosegue con l'istruzione successiva al salto.

Il problema è che se il salto avviene o non avviene lo si sa troppo tardi quindi il processore ha due scelte.
Fermarsi per sapere il risultato del salto e poi procedere, ma questo causa stalli della pipeline e perdita di prestazioni o proseguire scegliendo lui (predizione di salto in base a varie tecniche da quelle semplici tipo "salto sempre fatto se all'indietro e salto mai fatto se in avanti" a quelle più raffinate che richiedono storia dei salti passati e ...) una delle due strade e proseguire senza fermarsi.
Se la predizione di salto sarà stata azzeccata si avrà una prestazione massimale (come se il salto non fosse mai esistito) e se la predizione è sbagliata bisognerà annullare l'effetto delle istruzioni eseguite erroneamente come se queste non fossero mai state eseguite, con ovviamente perdita prestazionale.

L'esecuzione fuori ordine è invece la possibilità di eseguire istruzioni non nell'ordine del programma se tali istruzioni non hanno dipendenze tra di loro.
Es.
...
C=A*B
D=C+2
E=A+3
...
In un processore con esecuzione in ordine E sarebbe calcolato dopo (o al più in parallelo) che è stato calcolato D che a sua volta per forza deve aspettare che sia stato calcolato C, mentre in un processore con out of order, verrebbe iniziato il calcolo di C, D sarebbe messo in pausa causa dipendenze ma nel frattempo verrebbe calcolato E.
Di fatto il calcolo di E avverrebbe prima di D e quindi l'esecuzione è fuori ordine (solo l'esecuzione materiale è fuori ordine i risultati devono essere comunque sempre presentati in ordine per conservare la semantica del codice).
E questo non centra con l'esecuzione speculativa anche se di solito l'esecuzione speculativa è presente solo in processori che sono anche out of order.

PS
Anche sulle CPU senza speculazione hw ci sono delle tecniche per minimizzare il costo dei salti (es. i delay slot usati su Mips, l'uso di istruzioni condizionali per evitare l'uso di salti su Arm ed altre cpu)

Grazie per la tua chiarissima esposizione: finalmente si capisce bene la problematica, anche se queste soluzioni di ottimizzazione lasciano molto perplesso chi non è addentrato (quasi come gli effetti relativistici spiegati alla massa).
Mi piacerebbe sapere dove documentarsi in rete su arcani di questo tipo.

Un estraneo ai fatti giudicherebbe secondo buon senso molto più oneroso scandire la logica di dipendenze nelle variabili del codice per applicare elaborazione "out of order" o addirittura ricorrere a statistiche predittive ed altre considerazioni probabilistiche per decidere se preeseguire magari inutilmente istruzioni successive ad un salto condizionato... piuttosto che lasciandare andare le cose avante belle semplici logiche e pulite nel sacrosanto rispetto del codice da eseguire.
Ma è poi così drammatico se lo stack di pipeline per qualche istante non lavora, piuttosto che lavorare magari inutilmente?

[rockroll]

Originariamente inviato da MaxFabio93

Prima di tutto AMD e ARM hanno minori vulnerabilità rispetto ai processori Intel, secondo la stessa Intel rimarca sempre con forza la sicurezza e i controlli nei suoi prodotti, cosa che evidentemente non è stata fatta a sufficienza visto che i danni sono maggiormente li. Se poi è vero che la cosa si conosceva da anni...tutto nascosto a discapito come sempre degli utenti.

Quoto completamente.

Non si può difendere a prescindere una società che ha la faccia tosta di affermare che "non c'è un bug nei processori e tutto funziona come previsto"... peccato che quel che non funziona è quello che non hanno previsto (o hanno preferito non prevedere)!

[carlottoIIx6]

Originariamente inviato da ROBHANAMICI

why? E' un problema generalizzato.

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.

[carlottoIIx6]

Originariamente inviato da MaxFabio93

Prima di tutto AMD e ARM hanno minori vulnerabilità rispetto ai processori Intel, secondo la stessa Intel rimarca sempre con forza la sicurezza e i controlli nei suoi prodotti, cosa che evidentemente non è stata fatta a sufficienza visto che i danni sono maggiormente li. Se poi è vero che la cosa si conosceva da anni...tutto nascosto a discapito come sempre degli utenti.

http://www.bitsandchips.it/9-hardwar...le-proprie-cpu

[rockroll]

Originariamente inviato da carlottoIIx6

http://www.bitsandchips.it/9-hardwar...le-proprie-cpu

Estrapolato dal tuo link:
"Nel mentre il comunicato di Intel (quello che cerca di far credere che tutti sono coinvolti un egual misura) ha avuto successo, in quanto ha fermato l'ascesa del titolo di AMD, che da un +10,5% è sceso ad un +7,5% finale, ed al contempo ha limitato la caduta del titolo Intel, passato da un -7% ad un -4,5%."

Ho sempre detto che AMD o altro concorrente potrebbe fare CPU migliori di Intel (e a questo punto direi che ci è realmente riuscita), ma per lo meno nell'immediato cambierebbe ben poco: lo strapotere ed il fattore condizionante del quasi monopolio Intel, a prescindere da come acquisito, non si riesce a scalfire solo con argomentazioni tecnologiche (e di convenienze di acquisto).

[fdl88]

Non ho capito se spectre v2 affligge solo alcune CPU AMD

P.S. Ho visto soluzioni per praticamente tutti i sistemi (desktop, Android, iOS, ecc) ma non per le console. Qualcuno ha notizie a riguardo?

[cdimauro]

Originariamente inviato da Sandro kensan

Anch'io ho capito che se c'è una esecuzione speculativa allora le tracce vengono lasciate in un modo o nell'altro in quanto potrebbe essere che l'azione coinvolga la cache in certi casi oppure la memoria normale in altri per cui misurando le latenze si vengono a scoprire i dati della memoria privilegiata.

Ma cdimauro afferma che il vincolo (forse imposto dai produttori di processori che non hanno spazio di azione col microcodice) è quello di non toccare l'esecuzione speculativa sia per quanto riguarda l'out of order che i branch.

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.

Originariamente inviato da rockroll

Non è uno ma più problemi (sostanzialmente 3), e solo Intel è coinvolta in tutti. La pezza SW più impattante prestazionalmente riguarda un problema solo di CPU Intel,

Gli stessi ricercatori che hanno trovato la falla hanno precisato che l'impatto prestazionale è "negligible" (parole loro, ovviamente).

Notizia di ieri. Per chi s'informa, ovviamente.

Originariamente inviato da rockroll

Grazie per la tua chiarissima esposizione: finalmente si capisce bene la problematica, anche se queste soluzioni di ottimizzazione lasciano molto perplesso chi non è addentrato (quasi come gli effetti relativistici spiegati alla massa).

E' normale. Chi non è addentrato in certi argomenti può soltanto far viaggiare la fantasia e lasciarsi andare a battutine e attacchi privi di senso.

Mi piacerebbe sapere dove documentarsi in rete su arcani di questo tipo.

Su Appunti Digitali sono stati scritti diversi articoli da ingegneri che lavoravano per nVidia e AMD, e che sono abbastanza "potabili" per chi è a digiuno di micro/architetture.

Altrimenti ci sono svariati testi di Architetture degli Elaboratori, col Patterson fra i classici, che affrontano molto più estensivamente (nonché accademicamente) gli argomenti.

Infine, ci sono sempre i manuali per le ottimizzazioni che sono pubblicati da Intel e AMD che riportano numerose informazioni su loro specifiche microarchitetture.

Un estraneo ai fatti giudicherebbe secondo buon senso molto più oneroso scandire la logica di dipendenze nelle variabili del codice per applicare elaborazione "out of order" o addirittura ricorrere a statistiche predittive ed altre considerazioni probabilistiche per decidere se preeseguire magari inutilmente istruzioni successive ad un salto condizionato... piuttosto che lasciandare andare le cose avante belle semplici logiche e pulite nel sacrosanto rispetto del codice da eseguire.

Difatti è un'assunzione che può fare soltanto un estraneo ai fatti, per l'appunto, che non ha la minima idea di come funzionino i processori moderni e di quali tecniche vengano usate per migliorare le prestazioni rispetto alla primitiva esecuzione in stretto ordine e senza speculazioni.

Mentre esperti del settore ovviamente la pensano diversamente. Ecco cosa viene riportato già nel solo abstract del paper, ad appena la TERZA riga, che è stato pubblicato dai ricercatori di sicurezza che hanno individuato il famigerato Meltdown:

"Out-of-order execution is an indispensable performance feature and present in a wide range of modern processors."

Direi che sia piuttosto eloquente. Ovviamente per chi capisce E vuol capire.

Ma è poi così drammatico se lo stack di pipeline per qualche istante non lavora, piuttosto che lavorare magari inutilmente?

Cosa sarebbe questo "stack di pipeline"? E' un termine coniato da un "estraneo ai fatti"?

Se è così, vale il solito consiglio: è sempre meglio parlare soltanto di cose di cui si ha conoscenza. Quanto meno di base.

Originariamente inviato da rockroll

Quoto completamente.

Non si può difendere a prescindere una società che ha la faccia tosta di affermare che "non c'è un bug nei processori e tutto funziona come previsto"... peccato che quel che non funziona è quello che non hanno previsto (o hanno preferito non prevedere)!

Altre perle da "estraneo ai fatti"? O hai delle fonti per questo?

[yeppala]

Già disponibile la patch di sicurezza per i telefoni Windows:
- W10M FCU build 15254.158
- W10M CU build 15063.850
- W10M AU build 14393.2007
Noi su Windows siamo già al sicuro, mentre i telefoni Android dovranno pregare i santi...
=> Lunga vita a W10M

[cdimauro]

Già. Peccato che anche i Nokia-Microsoft che ho comprato a moglie e figlia avrebbero dovuto avere W10M, e invece sono rimasti alla 8.1. Dunque in balia di queste problematiche.

Dunque grazie, Microsoft, per aver messo sulla graticola i tuoi stessi clienti, trattandoli peggio di Google con Android.

P.S. E' bene ricordare che i processori usati sui dispositivi W10M, come pure Android, sono basati su ARM. Quindi "mal comune, mezzo gaudio": non è solo Intel che piange.

[yeppala]

Con Interop Tools puoi aggiornare qualsiasi telefono a W10M. Il mio Lumia 630 in questo momento monta W10M FCU

[Lampetto]

Originariamente inviato da cdimauro

Già. Peccato che anche i Nokia-Microsoft che ho comprato a moglie e figlia avrebbero dovuto avere W10M, e invece sono rimasti alla 8.1. Dunque in balia di queste problematiche.

Dunque grazie, Microsoft, per aver messo sulla graticola i tuoi stessi clienti, trattandoli peggio di Google con Android.

P.S. E' bene ricordare che i processori usati sui dispositivi W10M, come pure Android, sono basati su ARM. Quindi "mal comune, mezzo gaudio": non è solo Intel che piange.

Non mi permetto di dissentire perchè sei tu l'esperto, ma faccio un ragionamento logico.

Punto primo, avendo avuto anche io i Nokia-Microsoft da te menzionati, Lumia 920, 930 e non più supportati ne so qualcosa (si sapeva da tempo perchè hanno oltrepassato i 36 mesi di garantiti per il supporto di sicurezza) non credo abbia messo sulla graticola nessuno all'epoca, difficilmente oggi si può pensare di supportare terminali ormai scomparsi, se poi bontà sua Microsoft decidesse di fixare anche i terminali WP8.1 ormai fuori produzione da anni sarebbe pure bello, nel frattempo sto cercando di capire se Samsung fixerà anche il mio A5 2017, un telefono di un anno, fino ad oggi non so nulla.

Punto secondo, i processori ARM sono coinvolti in maniera molto marginale dalle falle in questione, un eventuale attacco risulta molto difficile da attuare e dubito che qualcuno compia lo sforzo necessario per bucare i terminali di tua Moglie o di tua figlia, a meno che non abbiano segreti industriali o lavorino per il governo.

Infine non so che terminali siano, ma dubito che sia stata una spesa elevata all'epoca vista la scarsa diffusione, penso che come tutti li hai presi a prezzi stracciati.

Poi si può discutere se 36 mesi sono pochi o molti, ma mi risulta che su terminali non più aggiornati rimasti a Windows 8.1 il supporto di sicurezza è proseguito ben oltre la scadenza, oltretutto installare windows 10 su uno Snapdragon S2 o S4 non credo si avrebbe avuto un terminale fluido come si era abituati, considerando che all'epoca oltre il processore non all'altezza persino la RAM era appena sufficiente, e non parlo dei 530 con 512 mb, anche se qualcuno è riuscito a ficcare W10 anche li..

Ma di cosa stiamo parlando? di una linea ormai morta e sepolta rimasta come reliquia? Il problema grave è qualche centianaia di milioni di terminali non più supportati in giro per il mondo, non qualche decina di rimasugli da museo che non se li caga nessuno, il problema sono i milioni di Computer, server e Workstation, in particolare e nella maggioranza con processori Intel, macchine che costano una cifra e che la soluzione sembra solo provvisoria.. quello è il problema..

[TheQ.]

Originariamente inviato da yeppala

Già disponibile la patch di sicurezza per i telefoni Windows:
- W10M FCU build 15254.158
- W10M CU build 15063.850
- W10M AU build 14393.2007
Noi su Windows siamo già al sicuro, mentre i telefoni Android dovranno pregare i santi...
=> Lunga vita a W10M

Veramente Google ha una soluzione che non impatta le prestazioni della CPU, a differenza della soluzione Microsoft.
Per i Pixel è già stata fornita una patch.
Per gli android Stock (come lo Xiaomi Mi A1) arriverà a breve. In genere si patcha ogni primo giorno del mese.
Il problema sono tutti gli altri smartphone di marke con distro personalzizate di android. Forse la mancanza di patch spingerà gli utenti a distri libere ed alternative di android (ubuntu touch?!)