Vulnerabilità dei processori Meltdown e Spectre. Avviate già tre class action

[amd-novello]

Originariamente inviato da Sandro kensan

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.

[Alekx]

Originariamente inviato da gioloi

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.

[Alekx]

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

[calabar]

Originariamente inviato da gioloi;

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.

Originariamente inviato da Bellaz89;

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).

[yeppala]

Microsoft ha comunicato che queste patch di sicurezza hanno un impatto negativo sulle prestazioni soprattutto sulle vecchie versioni di Windows, come Windows 7 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/mic...indows-systems
=> Ecco un'altra ragione per passare a Windows 10

[tallines]

Originariamente inviato da cdimauro

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.........

[cdimauro]

Originariamente inviato da Lampetto

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
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.

[cdimauro]

Originariamente inviato da digieffe

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).

[cdimauro]

Originariamente inviato da recoil

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.

[cdimauro]

Originariamente inviato da digieffe

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.

Originariamente inviato da gioloi

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.

*

[cdimauro]

Originariamente inviato da calabar

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:

Originariamente inviato da amd-novello

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.

[cdimauro]

Originariamente inviato da Alekx

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).

Originariamente inviato da Alekx

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

CVD. Ma qui siamo ormai a ruota libera...

[cdimauro]

Originariamente inviato da Bellaz89

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.

*

Originariamente inviato da yeppala

Microsoft ha comunicato che queste patch di sicurezza hanno un impatto negativo sulle prestazioni soprattutto sulle vecchie versioni di Windows, come Windows 7 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/mic...indows-systems
=> Ecco un'altra ragione per passare a Windows 10

ROFL. Ad "adapter" sarà venuta una sincope con annesso ictus fulminante.

Originariamente inviato da tallines

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.

[repompeo]

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

[calabar]

Originariamente inviato da cdimauro;

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.

Originariamente inviato da cdimauro;

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.

Originariamente inviato da cdimauro;

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.

Originariamente inviato da cdimauro;

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.

[amd-novello]

È l'anno delle class action questo.

[cdimauro]

Originariamente inviato da calabar

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.

[recoil]

Originariamente inviato da cdimauro

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...)

[fraussantin]

Originariamente inviato da cdimauro

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.

[gioloi]

Originariamente inviato da calabar

È 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.

Originariamente inviato da fraussantin

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.