Link alla notizia: https://www.hwupgrade.it/news/sicurezza-software/vulnerabilita-dei-processori-meltdown-e-spectre-avviate-gia-tre-class-action_73352.html

Il problema sulla vulnerabilità, Meltdown e Spectre per i processori Intel, ha già creato le prime class action. La volontà è quella di dimostrare di avere in qualche modo subito dei danni.

Click sul link per visualizzare la notizia.

Penso anch'io che il problema non siano gli utenti che non hanno ricevuto praticamente alcun danno ma sia Internet con i propri server fortemente rallentati dal bug dei µp Intel.

Ossia quando arriveranno nei negozi processori coi bug corretti a livello hardware?

Ossia quando arriveranno nei negozi processori coi bug corretti a livello hardware?

Sarebbe gia' possibile, penso.
In teoria, qualunque processore in-order dovrebbe essere immune da questo tipo di bug.

Secondo le dichiarazioni di Intel, non si tratta di difetto di progettazione, ma è così che le CPU dovevano funzionare. :eek:
In pratica sono state scardinate tutte le fondamenta dell'informatica dei calcolatori! :eekk:

Secondo le dichiarazioni di Intel, non si tratta di difetto di progettazione, ma è così che le CPU dovevano funzionare. :eek:
In pratica sono state scardinate tutte le fondamenta dell'informatica dei calcolatori! :eekk:
Infatti è così. Semplicemente dovevano scegliere tra prestazioni e sicurezza, e hanno scelto ovviamente la prima. Detto questo, le vulnerabilità in questione sono quasi impossibili da sfruttare su un utente casalingo, e molto difficili comunque per tutto il resto. Il vero problema è il cloud, ma posso capire la scelta fatta.

Penso anch'io che il problema non siano gli utenti che non hanno ricevuto praticamente alcun danno ma sia Internet con i propri server fortemente rallentati dal bug dei µp Intel.

Mi rispondo da solo proseguendo una discussione del precedente articolo che tratta del bug Meltdown in cui un utente Intel mi faceva notare che alcuni test rilevavano su Windows un calo sensibile di prestazioni. Io da bravo fan AMD mi sono ripromesso di vedere se è vero o no però con esempi reali di programmi.

Su YT ci sono due video affiancati di Zelda con un 8700K@5.1GHz, il video a destra è senza patch mentre quello a sinistra è con la patch, Zelda fa le stesse azioni e gli stessi movimenti nei due video, quindi si possono vedere le differenze nelle immagini e nei fps.

Però si è usato un emulatore per fare andare zelda su PC e quindi si è un po' fuori gli usi tipici di un pc ma comunque la differenza è visibile ad occhio nudo sia in termini di qualità delle immagini che in termini di fps durante tutto il video.

https://www.youtube.com/watch?v=bkS53b_BmIg

Questa una immagine del video:

https://drive.google.com/open?id=1c3i8_tiVPj_llAv8NLraSeDySLiYQliv

5 fps di differenza si vedono spesso nel video e le immagini sono più scure.

Infatti è così. Semplicemente dovevano scegliere tra prestazioni e sicurezza, e hanno scelto ovviamente la prima. Detto questo, le vulnerabilità in questione sono quasi impossibili da sfruttare su un utente casalingo, e molto difficili comunque per tutto il resto. Il vero problema è il cloud, ma posso capire la scelta fatta.

Be inzomma, se per causa di queste falle vengono scardinati servizi Cloud di colossi come Amazon, Microsoft, Google e i centinaia di provider cloud sparsi per il mondo, mi sa che non bastano le dichiarazioni se dati sensibili finiscono in mani sbagliate, potrebbe costargli carissimo.

Oggi più che mai la sicurezza informatica è un valore aggiunto, più dei numerini di benchmark per bimbiminkia...
Si investono miliardi per la sicurezza, certe leggerezze non dovrebbero essere ammesse

Per Intel un problema non da poco mi sa......

Come l' esempio portato da Lampetto, alias se sono coinvolte grosse aziende........o anche altri tipi di aziende ehhhhh, non ci sono al mondo solo le aziende citate, ce ne sono di aziende di grossissime dimensioni in tutto il mondo........ potrebbero veramente essere dolori per Intel .

Soprattutto se poi a queste grosse aziende, vengono rubati i dati.....chiaro che ci deve essere la prova che i dati sono stati sottratti, però una bella gatta da pelare per Intel............

Che poi Intel ha già avuto problemi in passato o in un recente passato................>

https://www.hwupgrade.it/forum/showpost.php?p=45286890&postcount=740

Potrebbero essere vulnerabilità pericolose ma fino ad ora non risulta che qualcuno abbia sfruttato queste vulnerabilità.

Fino a che il danno non c`é, esso non può venire risarcito.

Secondo le dichiarazioni di Intel, non si tratta di difetto di progettazione, ma è così che le CPU dovevano funzionare. :eek:
Infatti le CPU si comportano correttamente.

Quale parte non sarebbe stata implementata correttamente, e dunque dove starebbero i bug?

I manuali delle architetture x86 e x64 si possono scaricare liberamente dal sito di Intel o di AMD. Mi faresti vedere di preciso dov'è che l'implementazione non rispecchierebbe le specifiche?
In pratica sono state scardinate tutte le fondamenta dell'informatica dei calcolatori! :eekk:
Che sarebbero? Anche qui, almeno un esempio e/o approfondimento non guasterebbe, grazie.

Mi rispondo da solo proseguendo una discussione del precedente articolo che tratta del bug Meltdown in cui un utente Intel mi faceva notare che alcuni test rilevavano su Windows un calo sensibile di prestazioni. Io da bravo fan AMD mi sono ripromesso di vedere se è vero o no però con esempi reali di programmi.

Su YT ci sono due video affiancati di Zelda con un 8700K@5.1GHz, il video a destra è senza patch mentre quello a sinistra è con la patch, Zelda fa le stesse azioni e gli stessi movimenti nei due video, quindi si possono vedere le differenze nelle immagini e nei fps.

Però si è usato un emulatore per fare andare zelda su PC e quindi si è un po' fuori gli usi tipici di un pc ma comunque la differenza è visibile ad occhio nudo sia in termini di qualità delle immagini che in termini di fps durante tutto il video.

https://www.youtube.com/watch?v=bkS53b_BmIg

Questa una immagine del video:

https://drive.google.com/open?id=1c3i8_tiVPj_llAv8NLraSeDySLiYQliv

5 fps di differenza si vedono spesso nel video e le immagini sono più scure.
Non mi sembra che ci siano differenze in termini di qualità. Le parti più scure sono dovute ad altri elementi che l'engine del gioco inserisce, come ad esempio delle nuvole.

Per il resto, ci sono appunto quelle differenze di FPS. Circa 5FPS in meno su 100 rientra fa il 5%, che è molto di più di ciò che in genere si registra nei giochi. Probabilmente in questo caso la differenza la fa l'overhead dell'emulatore rispetto a un normale gioco (che non deve emulare niente, e gira "nativamente").

Be inzomma, se per causa di queste falle vengono scardinati servizi Cloud di colossi come Amazon, Microsoft, Google e i centinaia di provider cloud sparsi per il mondo, mi sa che non bastano le dichiarazioni se dati sensibili finiscono in mani sbagliate, potrebbe costargli carissimo.

Oggi più che mai la sicurezza informatica è un valore aggiunto, più dei numerini di benchmark per bimbiminkia...
Si investono miliardi per la sicurezza, certe leggerezze non dovrebbero essere ammesse
Se sai come sviluppare processori senza falle di sicurezza non hai che mostrare come: vedrai che ti pagheranno a peso d'oro.

Forse non hai visto in che modo funzionino queste vulnerabilità. Almeno per Meltdown (che ho analizzato a fondo), non è affatto roba banale: il meccanismo è cervelloticamente geniale, e non è che può elaborarlo il primo che passa. Tant'è che è da almeno 10 anni che è rimasto nel limbo e solo di recente, con studi sulle vulnerabilità delle microarchitetture moderne, è venuto fuori.
Per Intel un problema non da poco mi sa......

Come l' esempio portato da Lampetto, alias se sono coinvolte grosse aziende........o anche altri tipi di aziende ehhhhh, non ci sono al mondo solo le aziende citate, ce ne sono di aziende di grossissime dimensioni in tutto il mondo........ potrebbero veramente essere dolori per Intel .

Soprattutto se poi a queste grosse aziende, vengono rubati i dati.....chiaro che ci deve essere la prova che i dati sono stati sottratti, però una bella gatta da pelare per Intel............

Che poi Intel ha già avuto problemi in passato o in un recente passato................>

https://www.hwupgrade.it/forum/showpost.php?p=45286890&postcount=740
I problemi di sicurezza non li ha solo Intel, mi pare.

Non mi sembra che ci siano differenze in termini di qualità. Le parti più scure sono dovute ad altri elementi che l'engine del gioco inserisce, come ad esempio delle nuvole.

Per il resto, ci sono appunto quelle differenze di FPS. Circa 5FPS in meno su 100 rientra fa il 5%, che è molto di più di ciò che in genere si registra nei giochi. Probabilmente in questo caso la differenza la fa l'overhead dell'emulatore rispetto a un normale gioco (che non deve emulare niente, e gira "nativamente").

Per la differenza tra le immagini imputabili a questo o quest'altro non discuto per la mia ignoranza sui videogiochi. Per gli fps attribuibili all'overhead sono d'accordo con te. Un vg non è emulato ma gira nativamente e quindi l'esempio non è la norma dei videogiochi.

Ossia quando arriveranno nei negozi processori coi bug corretti a livello hardware?

Sarebbe gia' possibile, penso.
In teoria, qualunque processore in-order dovrebbe essere immune da questo tipo di bug.
casomai in produzione , e al massimo già castrato a livello di microcode e funzionalità.

per avere processori ottimizzati come lo erano fino ad oggi dovremo aspettare qualche annetto , forse +di 5

In pratica sono state scardinate tutte le fondamenta dell'informatica dei calcolatori! :eekk:

no per ''fortuna'' solo alcune ottimizzazioni che davano boost a certi calcoli.

sino ad ora sembra che l'utente medio non verrà penalizzato dalle patch, il rallentamento dovrebbe incidere in maniera significativa (si dice sino al 30%) solo,su quel tipo di applicativi che ricorrono a massicci e frequenti scambi di dati fra memoria di massa e ram (vedi data center, virtualizzazione, etc), per cui chi fa gaming, editing video, photoshop, rendering, naviga sul web e scrive su word non dovrebbe avere problemi, bisogna aspettare qualche giorno affinchè dei benchmark completi confermino tutto ciò..
detto questo, secondo me il discorso delle class action è sostanzialmente infondato dal punto di vista della sicurezza, perchè per richiedere un risarcimento si dovrà dimostrare che c'è stato un danno, il discorso si fa più complesso su due altri versanti invece: 1- intel (ma anche microsoft, apple e tanti altri) sapeva di questo problema da almeno sei mesi, ma la notizia è stata fatta uscire solo adesso, qualcuno potrebbe dire che si è cercato di evitare di esporre una vulnerabilità cosí ghiotta per gli hackers prima che fossero disponibili le patch per correggere il problema, ma nel frattempo intel in questi sei mesi ha continuato a fatturare miliardi vendendo cpu che sapeva essere vulnerabili, e che sapeva avrebbero avuto un sostanziale calo di prestazioni una volta applicate le patch 2 - tutte quei servizi di cluod, data centers e virtualizzazione, che costituiscono una sostanziale fetta del fatturato di intel, dopo le patch si ritroveranno ad avere una potenza di calcolo dei propri sistemi ridotta in media del 15/20%, e qui il danno c'è ed è pure bello grosso, in pratica è come se compro un trattore da 100cv che uso per lavorare conto terzi, e all'improvviso mi ritrovo una macchina da 80cv, ovviamente non sarò in grado di effettuare gli stessi lavori di prima entro le stesse tempistiche, se ci mettiamo anche che la proporzione del problema è praticamente globale, beh, fatevi due conti e capite che se non trovano una soluzione efficace in tempi brevi anche sul versante delle prestazioni, Intel (ma anche moltissimi altri) avranno grossi problemi.

più che gli utenti 'privati' da capire l'impatto a livello di server, dove, per quanto ancora da quantificare (ma si sarà ben in grado di analizzarlo dato che è una delle 'voci' principali) l'impatto sulle prestazioni

penso poi che il vero danno a livello 'massa' sia di immagine, e non è aspetto marginale

detto questo, secondo me il discorso delle class action è sostanzialmente infondato dal punto di vista della sicurezza, perchè per richiedere un risarcimento si dovrà dimostrare che c'è stato un danno, il discorso si fa più complesso su due altri versanti invece: 1- intel (ma anche microsoft, apple e tanti altri) sapeva di questo problema da almeno sei mesi, ma la notizia è stata fatta uscire solo adesso, qualcuno potrebbe dire che si è cercato di evitare di esporre una vulnerabilità cosí ghiotta per gli hackers prima che fossero disponibili le patch per correggere il problema,
Sì, è esattamente questa la motivazione: trovare almeno un workaround per cercare di tamponare il problema.

Pratica comune in questi casi.
ma nel frattempo intel in questi sei mesi ha continuato a fatturare miliardi vendendo cpu che sapeva essere vulnerabili, e che sapeva avrebbero avuto un sostanziale calo di prestazioni una volta applicate le patch
Questo è sostanzialmente corretto, ma bisognerebbe dimostrare da quando Intel (e gli altri vendor per quanto riguarda le altre vulnerabilità) abbiano avuto conferma degli impatti prestazionali.

Infatti il solo avere a disposizione i dettagli della vulnerabilità non è di per sé sufficiente a comprenderne la portata a livello pratico. Anche perché serve avere il workaround e testarlo con codice reale.
2 - tutte quei servizi di cluod, data centers e virtualizzazione, che costituiscono una sostanziale fetta del fatturato di intel, dopo le patch si ritroveranno ad avere una potenza di calcolo dei propri sistemi ridotta in media del 15/20%, e qui il danno c'è ed è pure bello grosso, in pratica è come se compro un trattore da 100cv che uso per lavorare conto terzi, e all'improvviso mi ritrovo una macchina da 80cv, ovviamente non sarò in grado di effettuare gli stessi lavori di prima entro le stesse tempistiche, se ci mettiamo anche che la proporzione del problema è praticamente globale, beh, fatevi due conti e capite che se non trovano una soluzione efficace in tempi brevi anche sul versante delle prestazioni, Intel (ma anche moltissimi altri) avranno grossi problemi.
E' possibile, ma c'è anche un'altra cosa da considerare. I processori funzionano correttamente: come da specifiche. Se prendi il manuale che definisce nel dettaglio l'ISA, tutto viene rispettato.

Infatti, come dicevo in un altro thread, l'istruzione che tenta di leggere la memoria del kernel (mi riferisco a Meltdown, nello specifico, che è quello che ha portato a dover patchare i kernel, e quindi rallentare le syscall) viene bloccata, e quelle seguenti, che in qualche modo hanno utilizzato (speculativamente) il contenuto di quella cella, a loro volta sono state invalidate (rollback: come se non fossero state eseguite).
Non c'è nulla, in nessuna parte dell'architettura (ISA) che sia stata alterata: né i registri del processore né la memoria. Niente di niente.
Quindi il processore ha elaborato quelle istruzioni rispettando fedelmente le specifiche dell'ISA.

Questo è una carta che Intel potrebbe giocarsi nei processi.

Al netto dall'aver venduto processori conoscendo l'impatto della vulnerabilità a causa della patch.

Se sai come sviluppare processori senza falle di sicurezza non hai che mostrare come: vedrai che ti pagheranno a peso d'oro.

Forse non hai visto in che modo funzionino queste vulnerabilità. Almeno per Meltdown (che ho analizzato a fondo), non è affatto roba banale: il meccanismo è cervelloticamente geniale, e non è che può elaborarlo il primo che passa. Tant'è che è da almeno 10 anni che è rimasto nel limbo e solo di recente, con studi sulle vulnerabilità delle microarchitetture moderne, è venuto fuori.


Non sto certo dicendo che sono diventati idioti, ma riferendomi all'esempio di Matrix83, se è vero che prestazioni maggiori si ottengono anche portando all'estremo la linea di confine oltre il quale si mette a rischio la sicurezza, allora è una prassi pericolosa.
Io al massimo posso progettare una lampadina o una radio con batteria, antenna e condensatore :D :D
e non so neanche se l'esempio è corretto, ovvero che si è spinto troppo sulle prestazioni a discapito della sicurezza, ma posso anche pensare che le prestazioni siano un bel motore per la scelta di un processore e di una marca.
Naturalmente non ho la benchè minima prova, è solo per capire come mai qualcuno ha spinto per una class action...

se è vero che prestazioni maggiori si ottengono anche portando all'estremo la linea di confine oltre il quale si mette a rischio la sicurezza, allora è una prassi pericolosa.

Capisco il ragionamento, ma esiste l'architettura a prova di bomba?
Da quanto ho capito, la "falla" sfrutta una modalità operativa dei processori Intel nota e documentata, non un difetto di funzionamento.
Perché questa modalità potesse essere (teoricamente) sfruttata a fini malevoli ci sono voluti ben 10 anni. E parliamo dei processori più diffusi al mondo, non di una piccola nicchia fuori dagli schermi radar dei cracker. Significa che non era poi così facile da sfruttare, quindi anch'io concordo con chi dice che è stata una scelta legittima.
I nuovi processori non avranno più questa vulnerabilità, ma probabilmente ne avranno altre che saranno scoperte e sfruttate fra tot anni.

Non sto certo dicendo che sono diventati idioti, ma riferendomi all'esempio di Matrix83, se è vero che prestazioni maggiori si ottengono anche portando all'estremo la linea di confine oltre il quale si mette a rischio la sicurezza, allora è una prassi pericolosa.
Io al massimo posso progettare una lampadina o una radio con batteria, antenna e condensatore :D :D
e non so neanche se l'esempio è corretto, ovvero che si è spinto troppo sulle prestazioni a discapito della sicurezza, ma posso anche pensare che le prestazioni siano un bel motore per la scelta di un processore e di una marca.
Naturalmente non ho la benchè minima prova, è solo per capire come mai qualcuno ha spinto per una class action...

Il problema vero lo ha gia' spiegato cdimauro: in realta', Meltdown non sfrutta alcun bug in senso stretto, visto che l'architettura funziona CORRETTAMENTE.

Anzi, il motivo per cui Meltdown esiste e' proprio perche' la CPU genera un'eccezione nel momento in cui del codice utente tenta di accedere ad un indirizzo di memoria riservato al kernel.

A livello di ISA, tutto va come deve andare, solo che l'esecuzione OoO ha causato una variazione dello stato della micro-architettura, ed e' questa la chiave dell'attacco.

E' tutto talmente cervellotico che e' pure difficile credere che qualcuno sia arrivato a 'ste cose.

Scusate ma le patch su win 10 dovrebbero essere già arrivate o no?
Perchè a me ancra non le trova.

Capisco il ragionamento, ma esiste l'architettura a prova di bomba?
Da quanto ho capito, la "falla" sfrutta una modalità operativa dei processori Intel nota e documentata, non un difetto di funzionamento.
Perché questa modalità potesse essere (teoricamente) sfruttata a fini malevoli ci sono voluti ben 10 anni. E parliamo dei processori più diffusi al mondo, non di una piccola nicchia fuori dagli schermi radar dei cracker. Significa che non era poi così facile da sfruttare, quindi anch'io concordo con chi dice che è stata una scelta legittima.
I nuovi processori non avranno più questa vulnerabilità, ma probabilmente ne avranno altre che saranno scoperte e sfruttate fra tot anni.

Non ho seguito la discussione perché queste argomentazioni le trovo sterili, invece mi piace questo commento che ho quotato che fa pulizia su un modo di pensare che non ha attinenze con la realtà. Chi ha programmato sa che ci sono sempre bachi in un programma complesso e che non occorre tirare in ballo la CIA o l'NSA per capire che il proprio programma ha dei difetti che si manifestano solo in certe fortuite circostanze.

Anzi direi di più, il problema della programmazione è di non riuscire a trovare i bachi quando il programma non funziona ma dovrebbe funzionare. Dopo un po' di anni ci si rende conto di come la complessità renda impossibile un programma senza bachi e ce ne si fa una ragione.

Forse hanno ragione quelli che vogliono insegnare a programmare (logo) fin dalle elementari con metodi adatti, ci sarebbe un po' di cultura.

Il problema vero lo ha gia' spiegato cdimauro: in realta', Meltdown non sfrutta alcun bug in senso stretto, visto che l'architettura funziona CORRETTAMENTE.

Anzi, il motivo per cui Meltdown esiste e' proprio perche' la CPU genera un'eccezione nel momento in cui del codice utente tenta di accedere ad un indirizzo di memoria riservato al kernel.

A livello di ISA, tutto va come deve andare, solo che l'esecuzione OoO ha causato una variazione dello stato della micro-architettura, ed e' questa la chiave dell'attacco.

E' tutto talmente cervellotico che e' pure difficile credere che qualcuno sia arrivato a 'ste cose.

premetto che non ancora ho finito di leggere il paper, ma

pur rispettando le specifiche dell'ISA la cpu non garantisce l'isolamento tra kernel ed user mode: se fosse voluto allora non è un bug ma un errore di progettazione a livellio di uArch.

Non importa se ciò è ottenuto in modo cervellotico, avrebbero dovuto inserirebun "discard/invalidate" su tutte le componenti interessate in uArch a livello hardware (di fatto un rollback completo e non solo sui registri del'ISA) con ovvia penalizzazione.

Infatti, come dicevo in un altro thread, l'istruzione che tenta di leggere la memoria del kernel (mi riferisco a Meltdown, nello specifico, che è quello che ha portato a dover patchare i kernel, e quindi rallentare le syscall) viene bloccata, e quelle seguenti, che in qualche modo hanno utilizzato (speculativamente) il contenuto di quella cella, a loro volta sono state invalidate (rollback: come se non fossero state eseguite).
Non c'è nulla, in nessuna parte dell'architettura (ISA) che sia stata alterata: né i registri del processore né la memoria. Niente di niente.
Quindi il processore ha elaborato quelle istruzioni rispettando fedelmente le specifiche dell'ISA.

Questo è una carta che Intel potrebbe giocarsi nei processi.

Al netto dall'aver venduto processori conoscendo l'impatto della vulnerabilità a causa della patch.

non so come funziona questo tipo di processo, se va dimostrata la malafede o se basta aver subito il danno
la questione però non è legata solo a Intel, almeno per quanto riguarda Spectre che affligge un po' tutti

mi domando se la class action sia giusto farla nei confronti di Intel, o se il consumatore dovrebbe invece fare causa al produttore del computer e questi poi rivalersi su Intel al momento di pagare i danni
cosa succede, ipotizziamo, se un utente subisce un furto di informazioni perché ha una versione di Windows o di OS X vecchia che non riceve patch di sicurezza per arginare il problema? è ancora colpa di Intel o piuttosto ci si dovrebbe rivolgere al produttore quindi Apple, Dell ecc. (che poi si faranno risarcire da Intel ma quelle sono beghe loro)?

Capisco il ragionamento, ma esiste l'architettura a prova di bomba?
Da quanto ho capito, la "falla" sfrutta una modalità operativa dei processori Intel nota e documentata, non un difetto di funzionamento.
Perché questa modalità potesse essere (teoricamente) sfruttata a fini malevoli ci sono voluti ben 10 anni. E parliamo dei processori più diffusi al mondo, non di una piccola nicchia fuori dagli schermi radar dei cracker. Significa che non era poi così facile da sfruttare, quindi anch'io concordo con chi dice che è stata una scelta legittima.
I nuovi processori non avranno più questa vulnerabilità, ma probabilmente ne avranno altre che saranno scoperte e sfruttate fra tot anni.

ll tempo per sfruttare a fini malevoli una "falla" non dipende dalla "difficoltà" della stessa ma dalle risorse investite.
Da quanto emerso dalle discussioni in questi giorni, l'attacco era stato teorizzato più di qualche anno fa, ma "dimostrato il possibile sfruttamento" (PoC) solo di recente 7/2017. Dunque, può essere stato tranquillamente trascurato per diversi anni, mentre le case potrebbero porvi rimedio prima di attendere che possano essere sfruttate, è solo questione di scelte.

intanto facendo questo test l'asus è a posto ma il dell no

https://s18.postimg.org/6eq23zpmd/image.png (https://postimg.org/image/6eq23zpmd/)

spero non facciano un malware in tempi brevi :D
comunque per i siti che frequento io dovrei essere a posto.

ll tempo per sfruttare a fini malevoli una "falla" non dipende dalla "difficoltà" della stessa ma dalle risorse investite.
Da quanto emerso dalle discussioni in questi giorni, l'attacco era stato teorizzato più di qualche anno fa, ma "dimostrato il possibile sfruttamento" (PoC) solo di recente 7/2017
Non mi pare che stiamo dicendo cose molto diverse. Se il possibile sfruttamento è stato dimostrato solo di recente, significa che non era così evidente, altrimenti le risorse le avrebbero impegnate ben prima. Nessuno spreca tempo e denaro su un binario morto, o ritenuto tale.

due cose mi fanno sorridere:

Gli esperti giuridici in tal senso fanno notare come i consumatori dovranno provare di aver subito un danno reale e concreto dalla vulnerabilità di Spectre e Meltdown ossia dovranno provare appunto di aver subito la perdita di dati sensibili o situazioni simili tali da pregiudicare attività di pericolo e dunque possibile di azione legale connesse ad esse.

Il danno lo hanno subito quando hanno comprato CPU bacate, cosa altro puo' provare un consumatore ?


Secondo le indiscrezioni però i ricorrenti potrebbero appellarsi al rallentamento provocato dai futuri aggiornamenti del sistema, elemento su cui però Intel ha già risposto dichiarando come le patch non porteranno a rallentamenti vistosi tali da pregiudicarne l'uso normale.

E' come chiedere all'oste come e' il vino.

due cose mi fanno sorridere:

Gli esperti giuridici in tal senso fanno notare come i consumatori dovranno provare di aver subito un danno reale e concreto dalla vulnerabilità di Spectre e Meltdown ossia dovranno provare appunto di aver subito la perdita di dati sensibili o situazioni simili tali da pregiudicare attività di pericolo e dunque possibile di azione legale connesse ad esse.

Il danno lo hanno subito quando hanno comprato CPU bacate, cosa altro puo' provare un consumatore ?


certo ma intel si farà passare come ignara

Se il possibile sfruttamento è stato dimostrato solo di recente, significa che non era così evidente
Magari era solo difficile da realizzare, o magari si è pensato di tenere la bocca chiusa nella speranza che nessuno se ne accorgesse.
Oltretutto stiamo dando per scontato che solo ora sia stato realizzato l'exploit, ma non sappiamo se qualcuno lo stesse sfruttando da anni senza rivelarlo (per motivi banalmente intuibili).

Non c'è nulla, in nessuna parte dell'architettura (ISA) che sia stata alterata: né i registri del processore né la memoria. Niente di niente.
Quindi il processore ha elaborato quelle istruzioni rispettando fedelmente le specifiche dell'ISA.
Questo è una carta che Intel potrebbe giocarsi nei processi.
Stai quindi dicendo che la colpa non è di chi realizza i processori ma di chi ha progettato l'ISA?
Quindi secondo te a chi sarebbe da imputare questa colpa?

Oppure è compito di chi realizza il processore assicurarsi che la propria implementazione non sia in qualche modo vulnerabile agli exploit?

Ovvio poi che questo è abbastanza teorico, sappiamo bene che le strutture complesse senza difetti non esistono.
E difatti credo che le class action non si basino sul difetto in se, ma sulle scelte che sono state fatte dopo la sua scoperta documentata.

Magari era solo difficile da realizzare, o magari si è pensato di tenere la bocca chiusa nella speranza che nessuno se ne accorgesse.
Oltretutto stiamo dando per scontato che solo ora sia stato realizzato l'exploit, ma non sappiamo se qualcuno lo stesse sfruttando da anni senza rivelarlo (per motivi banalmente intuibili).
Che fosse difficile è, infatti, quanto sostengo anch'io.
Quanto al poter tenere segreta una notizia di tale portata, riguardante i più diffusi processori al mondo, per anni e nell'era di Facebook e Twitter, lo ritengo altamente improbabile.
Secondariamente, se la falla fosse davvero stata sfruttata per anni senza che ce ne si accorgesse, mi sorgerebbero anche dubbi sulla sua reale pericolosità.
A questo punto verrebbe da concludere: se abbiamo vissuto bene finora con questa falla, teniamocela e risparmiamoci il calo prestazionale dovuto alla patch.
Io credo che le cose stiano diversamente.

Quanto al poter tenere segreta una notizia di tale portata, ...
È rimasta nell'ombra per tanti anni, avranno pensato che era così difficile da individuare che magari si sarebbe potuta rivelare quando ormai i processori affetti sarebbero stati vecchi, riducendo di molto l'impatto mediatico.
Se non fosse stato per project zero di Google, magari non sarebbe saltata fuori ancora per anni.

Secondariamente, se la falla fosse davvero stata sfruttata per anni senza che ce ne si accorgesse, mi sorgerebbero anche dubbi sulla sua reale pericolosità.
Una falla che avesse permesso di sottrarre dati sensibili senza che nessuno mai se ne accorgesse direi che è una falla estremamente pericolosa. Il genere più pericoloso di tutti.

Ch
A questo punto verrebbe da concludere: se abbiamo vissuto bene finora con questa falla, teniamocela e risparmiamoci il calo prestazionale dovuto alla patch.
Io credo che le cose stiano diversamente.

Io spero sempre in un fix piú docile.

Visto che i microcode si possono aggiornare, magari ora hanno dato un taglio netto alle funzionalità pericolose,. Ma con la ricerca potrebbero trovare piccoli accorgimenti per evitare il problema senza portare degrado alle prestazioni.

Io mi ricordo che Microsoft, 10 o 15 anni fa, aveva rilasciato degli aggiornamenti per Windows che andavano ad aggiornare il microcodice delle CPU, forse in occasione di un qualche Service Pack. Quindi non è da escludere che un intervento di questo tipo si possa ripetere, così da mettere al sicuro tutti quanti

Ovvio poi che questo è abbastanza teorico, sappiamo bene che le strutture complesse senza difetti non esistono.
E difatti credo che le class action non si basino sul difetto in se, ma sulle scelte che sono state fatte dopo la sua scoperta documentata.

Esatto, non ci sono colpe o responsabilità, c'è la complessità che noi tutti vogliamo e quella si paga in termini di bug. Quindi se proprio vogliamo trovare un colpevole allora è l'utente che vuole microprocessore sempre più veloci e a cui non interessano i limiti fisici, economici, di risorse umane e di gestione della complessità. Si vuole andare sempre più veloci ma è una cosa assurda, la realtà è limitata.

sì bhe non è che adesso è colpa del fato. si poteva dire chiaramente che si sceglieva la velocità a discapito della sicurezza 15 anni fa. a nessuno è interessato?

magari perchè lo sapevano 4 gatti. dire che ci meritiamo questo baco perchè abbiamo volontariamente scelto la velocità non ha senso.

sì bhe non è che adesso è colpa del fato. si poteva dire chiaramente che si sceglieva la velocità a discapito della sicurezza 15 anni fa. a nessuno è interessato?

magari perchè lo sapevano 4 gatti. dire che ci meritiamo questo baco perchè abbiamo volontariamente scelto la velocità non ha senso.

Perché se AMD sceglieva di mettere in commercio solo processori con elaborazione in order che sono i più sicuri qualcuno glieli avrebbe comprati? Processori che vanno alla metà (un numero a caso) della velocità non li compra nessuno e ci sarebbero stati i cori di gente col pollice verso. Iniziando dai videogiocatori, alle testate specializzate, agli azionisti, ai commessi di mediaworld.

Eppure l'eleaborazione in order è meno complessa e più gestibile e quindi foriera di meno bug presenti, passati e futuri. In particolare non ci sarebbe stato questo bug.

Una falla che avesse permesso di sottrarre dati sensibili senza che nessuno mai se ne accorgesse direi che è una falla estremamente pericolosa. Il genere più pericoloso di tutti.
E' pericolosa se permette di sottrarre dati a tua insaputa, ma poi gli effetti si devono vedere in qualche modo.
Esempio: mi fregano tutti codici d'accesso ai miei conti bancari e io non me ne accorgo. Gravissimo, ma poi dovrò registrare un ammanco nei miei conti, altrimenti i dati che me li hanno fregati a fare?
Voglio dire: se non vogliamo essere facili prede di questa paranoia del XXI secolo per la quale siamo costantemente controllati, hackerati, manipolati da tutto e tutti, dobbiamo cominciare a chiederci a chi giova tutto questo.
Magari sono 20 anni che mi stanno controllando a mia insaputa, ma finché non ne vedo un qualche effetto pratico per me, fino a prova contraria, non sta succedendo nulla.
"Eh, ma dopo è tardi!"
Ok, ma così non se ne esce più.

Perché se AMD sceglieva di mettere in commercio solo processori con elaborazione in order che sono i più sicuri qualcuno glieli avrebbe comprati?

era bello poter scegliere. ho delle cpu di 6 anni fa e fanno benissimo il loro dovere. non credo di accorgermi del rallentamento della patch.

ma ormai è inutile discutere del passato.

Che fosse difficile è, infatti, quanto sostengo anch'io.
Quanto al poter tenere segreta una notizia di tale portata, riguardante i più diffusi processori al mondo, per anni e nell'era di Facebook e Twitter, lo ritengo altamente improbabile.
Secondariamente, se la falla fosse davvero stata sfruttata per anni senza che ce ne si accorgesse, mi sorgerebbero anche dubbi sulla sua reale pericolosità.
A questo punto verrebbe da concludere: se abbiamo vissuto bene finora con questa falla, teniamocela e risparmiamoci il calo prestazionale dovuto alla patch.
Io credo che le cose stiano diversamente.

Io la penso esattamente come te. Pensiamo forse che ste cose non si sapevano ? Che la casa re delle CPU non sapesse come opera una sua creatura ? Che la regina delle GPU non facesse le stesse cose ? Che Microsoft non sapesse come opera un Hw ? E ce ne sarebbero di somande a cui ci si attende una risposta.

Il fatto e' che qualche cosa di troppo grande poteva succedere o stava succendendo e allora si sono letteralmente cagati sotto e ora si corre ai ripari.

Forse di tutte le chiacchiere che si stanno facendo in questi giorni si parla della sola punta dell'aisberg senza vedere quello nascosto sotto.

Inoltre sara' un caso che i cinesi sono anni che NON vogliono CPU americane?
Metidate gente metidate !!!! :mbe: :mbe:

E' pericolosa se permette di sottrarre dati a tua insaputa, ma poi gli effetti si devono vedere in qualche modo.
È probabile che un exploit del genere se lo tengano per attacchi ben più mirati (e remunerativi) del tuo conto in banca. E attacchi ce ne sono stati parecchi, il problema è che se non sai come hanno fatto, non hai neppure idea del fatto che ci sia una falla di questo tipo.

Cpu di 6 anni fa erano comunque OOO.
Beh ma non è che per evitare queste falle devi per forza avere un processore in-order... semplicemente questo tipo di processori non sono affetti da questa falla per come questa lavora, ma con gli opportuni accorgimenti anche un processore out-of-order non ne è affetto (come suppongo avverrà con le prossime generazioni di processori).

Microsoft ha comunicato che queste patch di sicurezza hanno un impatto negativo sulle prestazioni soprattutto sulle vecchie versioni di Windows, come Windows 7 :ciapet: e Windows 8, perchè su questi vecchi OS si verifica un maggior numero di transizioni fra lo spazio utente e kernel a causa del fatto che la gestione del rendering dei caratteri è implementata tutta a livello kernel. In Windows 10 invece è stata spostata in user space.
https://cloudblogs.microsoft.com/microsoftsecure/2018/01/09/understanding-the-performance-impact-of-spectre-and-meltdown-mitigations-on-windows-systems
=> Ecco un'altra ragione per passare a Windows 10 :D

I problemi di sicurezza non li ha solo Intel, mi pare.
Si lo, ma sembra che Intel ne abbia di più, poi.....infatti la class action......le tre class action, sono per Intel .

Se poi un domani partono anche per AMD o.........

Non sto certo dicendo che sono diventati idioti, ma riferendomi all'esempio di Matrix83, se è vero che prestazioni maggiori si ottengono anche portando all'estremo la linea di confine oltre il quale si mette a rischio la sicurezza, allora è una prassi pericolosa.
Io al massimo posso progettare una lampadina o una radio con batteria, antenna e condensatore :D :D
e non so neanche se l'esempio è corretto, ovvero che si è spinto troppo sulle prestazioni a discapito della sicurezza, ma posso anche pensare che le prestazioni siano un bel motore per la scelta di un processore e di una marca.
Naturalmente non ho la benchè minima prova, è solo per capire come mai qualcuno ha spinto per una class action...
Arrivo tardi, perché ti hanno già dato delle ottime risposte (in particolare gioloi).

Aggiungo soltanto una cosa che è importante per chiarire meglio come si arriva a situazioni come queste: non esiste un confine ben definito oltre il quale si mette a rischio la sicurezza.

Il problema fondamentale è che quando fai certe modifiche all'hardware o al software (perché i bug si possono introdurre in entrambi) NON sai a priori se stai intaccando la sicurezza del sistema! Anche perché non è che esista una definizione oggettiva di sicurezza, eh!

Insomma, non sai se cambiando la riga x alla fine il sistema sia diventano "meno sicuro" (messo tra virgolette appunto perché non esiste una definizione). E una verifica formale, benché TEORICAMENTE fattibile, è assolutamente impossibile da realizzare a livello pratico a causa del mostruosamente elevato numero di casi da verificare.

In sintesi, quanto esposto è ciò che MOLTO probabilmente è capitato in questo caso, come in miriadi di altri casi, sia con hardware sia con software complessi.

Difatti la vulnerabilità è rimasta ben nascosta fino a ora, ossia quando un pugno di "folli" si sono messi a sguazzare nei meandri delle microarchitetture (perché non è solo Intel che ne soffre) tirando fuori questa genialata che ha prodotto il terremoto.

Spero di essere stato chiaro.

premetto che non ancora ho finito di leggere il paper, ma

pur rispettando le specifiche dell'ISA la cpu non garantisce l'isolamento tra kernel ed user mode: se fosse voluto allora non è un bug ma un errore di progettazione a livellio di uArch.

Non importa se ciò è ottenuto in modo cervellotico, avrebbero dovuto inserirebun "discard/invalidate" su tutte le componenti interessate in uArch a livello hardware (di fatto un rollback completo e non solo sui registri del'ISA) con ovvia penalizzazione.
Non è così. Bisogna studiare bene a fondo la portata di queste nuove tecniche per capire che è stato scoperchiato il classico vaso di pandora, liberando orrori incredibili. Inimmaginabili prima.

Infatti eseguire il rollback di tutti i cambiamenti apportati dall'esecuzione di quelle istruzioni, come chiedi, non è oggettivamente possibile. Non lo è perché, pur rimettendo a posto tutto a livello micro-architetturale, ci sono delle cose che NON possono essere ripristinate. Una su tutte: il tempo macchina. Quello scorre in ogni singolo core e/o thread hardware a prescindere che le istruzioni eseguite siano state tutte invalidate, inclusi eventuali effetti collaterali a livello di micro-architettura.

Infatti se finisci di studiare il paper ti renderai conto che l'attacco è basato proprio sulla misura temporale di determinate cose.

Ricordi che t'avevo detto di aver trovato una soluzione per bloccare Meltdown lasciando mappata la memoria del kernel nello spazio d'indirizzamento virtuale del processo, in modo da eliminare nuovamente l'overhead introdotto dalle attuali patch sulle syscall? Sì, funziona con le tecniche descritte nel paper, e quindi ero convinto che fosse tutto risolto.

Peccato che oggi mi sia venuta in mente una variante che è ispirata a quegli esempi, ma che funziona in modo diverso. Ed è una variante che funzionerebbe anche se venissero cancellate completamente TUTTE le operazioni svolte internamente dalla micro-architettura in quel pezzo di codice incriminato.
Quel che è peggio, si tratta di una variante che sarebbe perfettamente in grado di funzionare anche con la mia soluzione, rendendola quindi vana.
Non l'ho testata ovviamente, ma sono ragionevolmente sicuro del funzionamento di questa variante che ho elaborato, anche se dovrebbe essere decisamente più lenta dell'attuale Meltdown (opera su un bit alla volta).

Per cui pretendere il rollback di tutte le operazioni NON risolverebbe affatto tutte le vulnerabilità. In buona sostanza, si starebbe soltanto spostando il problema "in avanti", verso un nuovo confine che, però, non è un muro invalicabile, e attende soltanto di essere superato con qualche nuova tecnica geniale.

Spero che quanto scritto serva una buona volta a far prendere coscienza che ci troviamo di fronte a qualcosa di completamente nuovo, che ci riserverà altre (amare) sorprese per il futuro. Personalmente è da quando mi sono messo a studiare questo problema che ho il cervello continuamente a caccia di dettagli di ISA e/o microarchitettura sfruttabili per carpire preziose informazioni: è un fiume in piena, perché c'è tanta roba che aspetta di essere messa alla prova.

Comunque, e per chiudere, la soluzione migliore rimane quella messa in piedi con le patch: dividere nettamente i due spazi d'indirizzamento di kernel e user land. Con buona pace degli sviluppatori di s.o., che si possono stracciare le vesti quanto vogliono, ma mettere assieme nello stesso posto due cose così diverse e delicate solo per questioni di velocità ha portato a vulnerabilità di questo genere. Che non esistono soltanto nel software, ma anche nell'hardware, e puntare il dito soltanto sui produttori di hardware lo trovo decisamente meschino, vista la quantità industriale di bug che affligge il software (s.o. in primis).

non so come funziona questo tipo di processo, se va dimostrata la malafede o se basta aver subito il danno
Penso che l'unica cosa dimostrabile sia il danno. E' molto difficile che si possa parlare di malafede, visto che la vulnerabilità è presente da almeno 10 anni, e nessuno, nemmeno i maggiori esperti di sicurezza, se n'era accorto prima che venissero divulgate queste nuove tecniche di cui ho parlato prima.
la questione però non è legata solo a Intel, almeno per quanto riguarda Spectre che affligge un po' tutti
Meltdown affligge anche alcuni ARM.

Comunque queste nuove tecniche possono portare a risultati nefasti su tutti i processori. Al momento Intel ne sta pagando maggiormente le conseguenze, perché si tratta della micro-architettura "desktop" più diffusa e, quindi, studiata. Infatti è stato eseguito persino il reverse-engineering del branch predictor; giusto per sottolineare a che punto si sono spinti questi ricercatori di sicurezza.

Nulla vieta che, adesso che il vaso di Pandora sia aperto, altri esperti si mettano a spulciare per bene i dettagli delle micro-architetture di altri produttori di processori, facciano anche lì reverse-engineering di branch predictor et similia, e che arrivino a tirare fuori simili vulnerabilità.

Ormai le danze sono aperte...
mi domando se la class action sia giusto farla nei confronti di Intel, o se il consumatore dovrebbe invece fare causa al produttore del computer e questi poi rivalersi su Intel al momento di pagare i danni
cosa succede, ipotizziamo, se un utente subisce un furto di informazioni perché ha una versione di Windows o di OS X vecchia che non riceve patch di sicurezza per arginare il problema? è ancora colpa di Intel o piuttosto ci si dovrebbe rivolgere al produttore quindi Apple, Dell ecc. (che poi si faranno risarcire da Intel ma quelle sono beghe loro)?
Se Intel produce workaround e/o nuovi firmare e li passa ai partner produttori di schede madri, non dovrebbe essere più ritenuta oggetto di pretese.

In questi casi la storia c'insegna che è il produttore di CPU a dover affrontare le conseguenze dei problemi dei propri prodotti, quando in altri casi la prassi è di rivolgersi all'anello della catena con cui il consumatore è stato a diretto contatto.

ll tempo per sfruttare a fini malevoli una "falla" non dipende dalla "difficoltà" della stessa ma dalle risorse investite.
Da quanto emerso dalle discussioni in questi giorni, l'attacco era stato teorizzato più di qualche anno fa, ma "dimostrato il possibile sfruttamento" (PoC) solo di recente 7/2017. Dunque, può essere stato tranquillamente trascurato per diversi anni, mentre le case potrebbero porvi rimedio prima di attendere che possano essere sfruttate, è solo questione di scelte.
Almeno per quanto riguarda Meltdown, l'idea è stata resa pubblica a luglio da uno sviluppatore che l'aveva (soltanto) teorizzata non riuscendo a produrre alcun PoC che funzionasse, ma subito dopo è stata ripresa dagli esperti di Google che hanno elaborato un PoC funzionante, e che hanno poi contattato tutti i produttori di CPU.
Non mi pare che stiamo dicendo cose molto diverse. Se il possibile sfruttamento è stato dimostrato solo di recente, significa che non era così evidente, altrimenti le risorse le avrebbero impegnate ben prima. Nessuno spreca tempo e denaro su un binario morto, o ritenuto tale.
*

Magari era solo difficile da realizzare, o magari si è pensato di tenere la bocca chiusa nella speranza che nessuno se ne accorgesse.
Non ha alcun senso. La vulnerabilità è lì da almeno 10 anni. Una volta che ne vieni a conoscenza e ti rendi conto della gravità, ci lavori e la sistemi: non ti metti a nicchiare indefinitamente producendo 400 MILIONI di pezzi l'anno e quindi col rischio di dover pagare una colossale cifra per eventuali risarcimenti di danno e/o campagne di rientro & sostituzione.
Oltretutto stiamo dando per scontato che solo ora sia stato realizzato l'exploit, ma non sappiamo se qualcuno lo stesse sfruttando da anni senza rivelarlo (per motivi banalmente intuibili).
E questo mi pare che nessuno lo potrà mai sapere. Se qualcuno l'avesse già sfruttato, vorrebbe dire che NON si tratterebbe di un esperto di sicurezza, ma di gentaglia (sì, NSA inclusa).
Stai quindi dicendo che la colpa non è di chi realizza i processori ma di chi ha progettato l'ISA?
No.
Quindi secondo te a chi sarebbe da imputare questa colpa?
Al caso: shit happens, come dicono gli anglofoni.

Non c'è stata intenzione di sacrificare la sicurezza sull'altare delle prestazioni: è stato un fattore puramente contingente, come spiegato negli altri messaggi.
Oppure è compito di chi realizza il processore assicurarsi che la propria implementazione non sia in qualche modo vulnerabile agli exploit?
E in che modo, visto che c'è un ben noto teorema della Teoria della Computabilità che non lascia scampo né al software né all'hardware?

Come già detto prima, non c'è modo di stabilire a priori se un cambiamento possa minare o meno la "sicurezza" di un sistema (sia esso hardware o software).
Ovvio poi che questo è abbastanza teorico, sappiamo bene che le strutture complesse senza difetti non esistono.
Non possiamo sapere se esistano o meno, per la precisione.
E difatti credo che le class action non si basino sul difetto in se, ma sulle scelte che sono state fatte dopo la sua scoperta documentata.
Si basano anche sul difetto di per sé. Cosa alquanto opinabile, come abbiamo già avuto modo di discutere.

EDIT:
sì bhe non è che adesso è colpa del fato.
Perché non potrebbe esserlo? I bug/falle/vulnerabilità non è che normalmente siano intenzionali...
si poteva dire chiaramente che si sceglieva la velocità a discapito della sicurezza 15 anni fa.
Vedi sopra: come fai a stabilirlo? Normalmente, se non è immediatamente e banalmente evidente, NON puoi.

Io la penso esattamente come te. Pensiamo forse che ste cose non si sapevano ? Che la casa re delle CPU non sapesse come opera una sua creatura ? Che la regina delle GPU non facesse le stesse cose ? Che Microsoft non sapesse come opera un Hw ? E ce ne sarebbero di somande a cui ci si attende una risposta.
Uno che sa come funzionano queste cose, le risposte se le dà.

Il problema è quando queste domande se le fanno chi non ha competenze/conoscenza in materia, e quindi la risposta rapida la trova subito: ovviamente scadendo nel complottismo spicciolo.
Il fatto e' che qualche cosa di troppo grande poteva succedere o stava succendendo e allora si sono letteralmente cagati sotto e ora si corre ai ripari.
CVD
Forse di tutte le chiacchiere che si stanno facendo in questi giorni si parla della sola punta dell'aisberg senza vedere quello nascosto sotto.
CVD (e si scrive iceberg).
Inoltre sara' un caso che i cinesi sono anni che NON vogliono CPU americane?
Metidate gente metidate !!!! :mbe: :mbe:
CVD. Ma qui siamo ormai a ruota libera...

Ci mancherebbe. Era per rispondere a chi punta il dito all'esecuzione OOO proponendo come soluzione di ritornare a un'esecuzione In-Order (che e' una non soluzione).
Come hai detto tu la soluzione e' fixare i processori mantenendo l'esecuzione attuale.
*
Microsoft ha comunicato che queste patch di sicurezza hanno un impatto negativo sulle prestazioni soprattutto sulle vecchie versioni di Windows, come Windows 7 :ciapet: e Windows 8, perchè su questi vecchi OS si verifica un maggior numero di transizioni fra lo spazio utente e kernel a causa del fatto che la gestione del rendering dei caratteri è implementata tutta a livello kernel. In Windows 10 invece è stata spostata in user space.
https://cloudblogs.microsoft.com/microsoftsecure/2018/01/09/understanding-the-performance-impact-of-spectre-and-meltdown-mitigations-on-windows-systems
=> Ecco un'altra ragione per passare a Windows 10 :D
ROFL. Ad "adapter" sarà venuta una sincope con annesso ictus fulminante. :asd:
Si lo, ma sembra che Intel ne abbia di più, poi.....infatti la class action......le tre class action, sono per Intel .

Se poi un domani partono anche per AMD o.........
Vedi sopra negli altri commenti.

oggi 9 gennaio mi ha istallato KB4056887 ed il computer si blocca mentre gioco ho un xeon 771@775 E5450@4.5ghz disistallato, tutto tornato come prima,secondo voi a chi devo mandare avvaffanccculo

Non ha alcun senso. La vulnerabilità è lì da almeno 10 anni. Una volta che ne vieni a conoscenza e ti rendi conto della gravità, ci lavori e la sistemi:
Indubbiamente, ma devi poterlo fare senza penalizzare troppo i tuoi prodotti o perdi in competitività, oltre a rendere palese la cosa. E magari per farlo serve tempo, nel frattempo che fai, non produci nulla? No, piuttosto fai finta di nulla e cerchi di tirare fuori una soluzione valida.

Al caso: shit happens, come dicono gli anglofoni.
Questo però sai bene che non significa che non ci sia un colpevole, in ogni cosa ci sono delle responsabilità e poi quando "shit happens" qualcuno ne paga le conseguenze, anche se alla fine era impossibile evitarlo.

Nel campo dell'industria queste cose capitano di continuo, anche solo perchè se si dovessero seguire alla lettera tutte le regole non si sarebbe in grado di essere competitivi (anche se poi alla fine anche seguendole i disastri sarebbero capitati comunque).

Purtroppo a volte essere in certe posizioni significa avere certe responsabilità, anche se ciò di cui sei responsabile non è del tutto sotto controllo. E in quei casi devi solo sperare che non succeda nulla quando la responsabilità è tua.

Si basano anche sul difetto di per sé. Cosa alquanto opinabile, come abbiamo già avuto modo di discutere.
Non ho approfondito, ma mi pareva riguardassero solo la gestione della vicenda.
Beh, credo che in questo caso bisognerà dimostrare il dolo, se hanno avviato la class action ho idea che qualcosa abbiano, da vedere poi se regge in tribunale.

Perché non potrebbe esserlo? I bug/falle/vulnerabilità non è che normalmente siano intenzionali...
Vedi sopra: come fai a stabilirlo? Normalmente, se non è immediatamente e banalmente evidente, NON puoi.
Beh, certo non possiamo stabilirlo noi con le chiacchiere. Ma in un tribunale, con testimoni, intercettazioni, materiale cartaceo e digitale, chi può sapere cosa salta fuori?
Noi possiamo supporre in base alle informazioni che ci arrivano, ma su certe cose non avremo mai prove se non delle sentenze, quando ci saranno.

È l'anno delle class action questo.

Indubbiamente, ma devi poterlo fare senza penalizzare troppo i tuoi prodotti o perdi in competitività, oltre a rendere palese la cosa. E magari per farlo serve tempo, nel frattempo che fai, non produci nulla? No, piuttosto fai finta di nulla e cerchi di tirare fuori una soluzione valida.
Questo è ciò che è avvenuto (e sta avvenendo) da quando Intel è a conoscenza della vulnerabilità.

Ma, ripeto, se ne fosse a conoscenza da parecchio da tempo sarebbe da suicidio non averla già sistemata, perché più vende e più processori ne sono affetti, e molto più alto è il rischio di essere coinvolta in azioni risarcitorie et similia.
Questo però sai bene che non significa che non ci sia un colpevole, in ogni cosa ci sono delle responsabilità e poi quando "shit happens" qualcuno ne paga le conseguenze, anche se alla fine era impossibile evitarlo.
Questo, però, è anche un altro discorso. Qui stiamo parlando di come capitano queste... beh... capitano! Sono ormai chip (e software) troppo complessi.
Nel campo dell'industria queste cose capitano di continuo, anche solo perchè se si dovessero seguire alla lettera tutte le regole non si sarebbe in grado di essere competitivi (anche se poi alla fine anche seguendole i disastri sarebbero capitati comunque).
Ma qui il caso è diverso: le regole sono state seguite tutte. Infatti i chip funzionano ESATTAMENTE come da specifiche, manuali delle architetture alla mano.

E' tutta roba pubblica che finisce in mano agli sviluppatori, sistemisti, esperti di sicurezza, ecc..

Posso chiedere quale sarebbe il problema se vendo processori che rispettano le specifiche che ho pubblicato, MA presentano queste problematiche? Dovrei essere colpevole di cosa, in questo caso (mi riferisco sempre a Meltdown, che ho studiato)?
Purtroppo a volte essere in certe posizioni significa avere certe responsabilità, anche se ciò di cui sei responsabile non è del tutto sotto controllo. E in quei casi devi solo sperare che non succeda nulla quando la responsabilità è tua.
Chiaro. Ma se non c'è dolo, le cose cambiano.
Non ho approfondito, ma mi pareva riguardassero solo la gestione della vicenda.
Beh, credo che in questo caso bisognerà dimostrare il dolo, se hanno avviato la class action ho idea che qualcosa abbiano, da vedere poi se regge in tribunale.
Esattamente. Comunque ho parlato brevemente delle class action in qualche precedente messaggio, ma non ricordo di quale thread. La prima sostiene che Intel ne fosse conoscenza da tantissimo tempo.

Ma, come hai detto, devono dimostrarlo in tribunale.
Beh, certo non possiamo stabilirlo noi con le chiacchiere. Ma in un tribunale, con testimoni, intercettazioni, materiale cartaceo e digitale, chi può sapere cosa salta fuori?
Certamente. Al solito Intel verrà passata al setaccio, come avvenuto in passato con le altre cause che ha avuto.
Noi possiamo supporre in base alle informazioni che ci arrivano, ma su certe cose non avremo mai prove se non delle sentenze, quando ci saranno.
Al momento per me è stato sufficiente quel che ho letto su queste vulnerabilità: sono troppo cervellotiche. Difatti il primo esperto che ha teorizzato Meltdown non è nemmeno riuscito a creare un PoC; ci sono voluti gli altri esperti che hanno esaminato il suo lavoro e sono finalmente riusciti a crearne uno.

Per cui, di fronte a ciò, assumo per default l'assenza del dolo.

Penso che l'unica cosa dimostrabile sia il danno. E' molto difficile che si possa parlare di malafede, visto che la vulnerabilità è presente da almeno 10 anni, e nessuno, nemmeno i maggiori esperti di sicurezza, se n'era accorto prima che venissero divulgate queste nuove tecniche di cui ho parlato prima.

come sviluppatore software sono un po' preoccupato da questa definizione di danno
i bug sono ovunque, inutile negarlo, ma più che risolverli tempestivamente appena vengono scoperti uno cosa può fare?

se parliamo di un bug grave, che avrebbe dovuto essere scoperto in fase di QA, la colpa è sicuramente di chi lo ha rilasciato
in questo caso però le CPU stanno funzionando come da specifica, io non parlerei di bug per Meltdown e soprattutto Spectre

fare causa dimostrando negligenza o malafede perché Intel (o altri produttori CPU) una volta avvertiti del problema non hanno preso prontamente contromisure mi sta benissimo, ma una class action contro una falla dell'architettura che è stata scoperta da ricercatori con i contropeni mi sta meno bene
non lavoro, per ora, in società del calibro di Intel quindi non penso avrò mai una class action, ma l'idea di poter andare a processo perché quando ho sviluppato un sw (che ha funzionato per anni senza che nessuno dicesse beh) non ho considerato una casistica molto al limite non mi piace per niente, a maggior ragione se non ci sono stati danni agli utenti ma è tutto su carta (per quanto ne sappiamo ovviamente...)

Questo è ciò che è avvenuto (e sta avvenendo) da quando Intel è a conoscenza della vulnerabilità.

Ma, ripeto, se ne fosse a conoscenza da parecchio da tempo sarebbe da suicidio non averla già sistemata, perché più vende e più processori ne sono affetti, e molto più alto è il rischio di essere coinvolta in azioni risarcitorie et similia.

.

Piú che altro non avrebbe avuto senso.

Son passati anni e anni in cui ha dominato il mercato e amd era li a guardare. Sulla fascia consumer specialmente poteva aver già fixato con il microcode il problema da subito.

Cmq vista la velocità con cui sono usciti i fix sicuramente la cosa era nota da diversi mesi.

Al di la della class action, che in america sono un business, il ceo che si vende le azioni poco prima delle dichiarazioni è grave, e mi sa che se non ha agganci buoni rischia sul serio.

È probabile che un exploit del genere se lo tengano per attacchi ben più mirati (e remunerativi) del tuo conto in banca. E attacchi ce ne sono stati parecchi, il problema è che se non sai come hanno fatto, non hai neppure idea del fatto che ci sia una falla di questo tipo.
Ragionamento che fila. Però la nuova "scoperta" deve a questo punto far luce su precedenti "misteri". Intendo, ora che questa gravissima falla rimasta nascosta per tanti anni è stata finalmente scoperta, dovrebbe consentirci di dare una spiegazione reale e documentata a vecchi attacchi rimasti finora inspiegati. In caso contrario, ricadiamo nel più trito complottismo dove ciascuno si sente autorizzato a pensare il peggio del peggio, ma nella pratica non si sa quali siano i rischi effettivi e se gli attacchi si siano realmente verificati.

Ovviamente quello del conto in banca era un esempio.

Cmq vista la velocità con cui sono usciti i fix sicuramente la cosa era nota da diversi mesi.

Al di la della class action, che in america sono un business, il ceo che si vende le azioni poco prima delle dichiarazioni è grave, e mi sa che se non ha agganci buoni rischia sul serio.
Condivido. Un'indagine è il minimo che deve aspettarsi.

Si segnalano gravi problemi su Linux Ubuntu 16.04 dopo aver applicato le relative patch di sicurezza che correggono questa falla, la macchina non parte più: :ciapet:
https://ubuntuforums.org/showthread.php?t=2382157
(https://ubuntuforums.org/showthread.php?t=2382157)

come sviluppatore software sono un po' preoccupato da questa definizione di danno
i bug sono ovunque, inutile negarlo, ma più che risolverli tempestivamente appena vengono scoperti uno cosa può fare?
Esattamente. Altrimenti non rilasciamo più né hardware né software se c'è la ghigliottina pronta a ogni errore.

Sappiamo che i bug esistono ed esisteranno sempre: o si accetta la situazione (e quindi che possano saltare fuori), o chiudiamo baracca.
se parliamo di un bug grave, che avrebbe dovuto essere scoperto in fase di QA, la colpa è sicuramente di chi lo ha rilasciato
in questo caso però le CPU stanno funzionando come da specifica, io non parlerei di bug per Meltdown e soprattutto Spectre
*
fare causa dimostrando negligenza o malafede perché Intel (o altri produttori CPU) una volta avvertiti del problema non hanno preso prontamente contromisure mi sta benissimo, ma una class action contro una falla dell'architettura che è stata scoperta da ricercatori con i contropeni mi sta meno bene
non lavoro, per ora, in società del calibro di Intel quindi non penso avrò mai una class action, ma l'idea di poter andare a processo perché quando ho sviluppato un sw (che ha funzionato per anni senza che nessuno dicesse beh) non ho considerato una casistica molto al limite non mi piace per niente, a maggior ragione se non ci sono stati danni agli utenti ma è tutto su carta (per quanto ne sappiamo ovviamente...)
Totalmente d'accordo.
Piú che altro non avrebbe avuto senso.

Son passati anni e anni in cui ha dominato il mercato e amd era li a guardare. Sulla fascia consumer specialmente poteva aver già fixato con il microcode il problema da subito.
A quanto pare non basta una modifica al microcodice, altrimenti sarebbe già arrivata.
Cmq vista la velocità con cui sono usciti i fix sicuramente la cosa era nota da diversi mesi.
Spectre è stato reso noto a Giugno, e Meltdown a luglio.
Al di la della class action, che in america sono un business, il ceo che si vende le azioni poco prima delle dichiarazioni è grave, e mi sa che se non ha agganci buoni rischia sul serio.
Infatti.
Ragionamento che fila. Però la nuova "scoperta" deve a questo punto far luce su precedenti "misteri". Intendo, ora che questa gravissima falla rimasta nascosta per tanti anni è stata finalmente scoperta, dovrebbe consentirci di dare una spiegazione reale e documentata a vecchi attacchi rimasti finora inspiegati.
Mi pare difficile che sia possibile, senza elementi che possano ricondurre senza alcun dubbio a queste vulnerabilità.
In caso contrario, ricadiamo nel più trito complottismo dove ciascuno si sente autorizzato a pensare il peggio del peggio, ma nella pratica non si sa quali siano i rischi effettivi e se gli attacchi si siano realmente verificati.
*