Meltdown, Spectre e perché Microsoft mi ha convinto a desistere.

[borgata]

Inviato da retalv

Vulnerabilità è ovunque ci sia un difetto di progettazione con mancanza di controlli di sistema, il bug è la stessa cosa a livello software. Vogliamo fare i sofisti?

No, il bug può essere sia a livello software che hardware. Si parla di bug quando le cose non funzionano come dovrebbero, in questo caso invece funzionano esattamente come progettato, solamente che non erano state progettate per bene, dato che non si è tenuto conto di un possibile sfruttamento di queste caratteristiche per violare la sicurezza del sistema

In ogni caso voleva solo essere una precisazione, non modificava certo il succo del discorso.

Ovviamente gli esempi che si trovano in rete e spiegano il funzionamento di queste falle sono molto semplificati, la realtà è molto più complessa. Per questo era piuttosto difficile anche solo concepire come sfruttare queste falle. Del resto il problema è saltato fuori oggi dopo vent'anni, non è un caso.

Inviato da retalv

Assolutamente senza volerti offendere, ma lasciamelo dire in modo bonario ...
"Anima candida..!"

Nessuna offesa, ma ti dico con molta franchezza che non mi ritengo tale. A mio parere un'ipotesi del genere sarebbe semplicemente molto improbabile.

Se proprio vogliamo buttarla sul complottismo secondo me è molto più probabile che Intel si sia resa conto da tempo del problema ma abbia preferito le prestazioni alla sicurezza, contando sul fatto che nessuno avrebbe tirato fuori un exploit. E invece Project Zero li ha messi con le spalle al muro.
Del resto può essere piuttosto conveniente acquisire un vantaggio sulla concorrenza a scapito della sicurezza, quando questa ha un costo prestazionale elevato

Il vero problema di queste vulnerabilità comunque è il comportamento di Intel a riguardo: a parte il cercare di minimizzare il problema e di fare tutta l'erba un fascio (come se i problemi degli altri fossero della stessa entità dei propri), le soluzioni proposte da Intel di fatto non tappano le falle ma forniscono gli strumenti per farlo. E questo significa che rimarrà in giro tanto software che sarà vulnerabile.
Non so se hai letto le esternazioni di Linus Torvalds (che, al solito, non le manda a dire), ma la sua indignazione era dovuta proprio al modo in cui Intel sta affrontando il problema.

Inviato da retalv

Tradotto: entro il 2018 modificheranno l'architettura delle nuove CPU per annullare i rischi, il che porterà ad avere nuove matherboard che possano ospitarli entro i primi 6 mesi del 2019...

Le motherboard non c'entrano nulla, la vulnerabilità sta nei processori. E già da tempo si sapeva che questa generazione di motherboard sarebbe stata incompatibile con la prossima generazione.
Del resto nulla di diverso dal solito, Intel taglia la compatibilità con le schede madre ad ogni cambio di microarchitettura, stavolta ha fatto solo un po' peggio cambiandola per una semplice revisione (ma i motivi sono altri).

Inviato da retalv

In questa ottica, tu, io e chiunque abbia una CPU più vecchia di 5 anni non ce lo faremmo un pensierino per toglierci il problema ...

Secondo me stai ampiamente sopravvalutando la percezione di questo problema da parte della massa d'utenza: se ne sbatteranno quasi tutti.
Guarda per esempio il topic in cui si chiede consiglio su un portatile... in cui ad un certo punto è saltato fuori che l'utente voleva Intel. Di certo non per la sicurezza, visto il momento!

Oltretutto se uno vuole stare molto più al sicuro già oggi c'è una bella alternativa, i Ryzen di AMD. E non deve neppure aspettare fine anno (quando saranno in uscita anche i Ryzen basati su Zen2 a 7nm, che pare potranno essere ancora più competitivi grazie a frequenze molto più alte). Intel rischia una certa emorragia di utenti.

PS; certo che le class action bisogna vincerle, ma stai certo che se partono la possibilità che questo avvenga l'hanno intravista.

[retalv]

Inviato da borgata

No, il bug può essere sia a livello software che hardware. Si parla di bug quando le cose non funzionano come dovrebbero, in questo caso invece funzionano esattamente come progettato, solamente che non erano state progettate per bene, dato che non si è tenuto conto di un possibile sfruttamento di queste caratteristiche per violare la sicurezza del sistema

In ogni caso voleva solo essere una precisazione, non modificava certo il succo del discorso.

Scherzi? Non è un errore di progettazione creare un sistema di sicurezza che non riesce a fare fino in fondo quello che deve? Certo se aspettavano che lo scoprissi io che sto a un visionario informatico quanto un pesce rosso, avrebbero aspettato che il sole diventasse una gigante rossa...

Inviato da borgata

Ovviamente gli esempi che si trovano in rete e spiegano il funzionamento di queste falle sono molto semplificati, la realtà è molto più complessa. Per questo era piuttosto difficile anche solo concepire come sfruttare queste falle. Del resto il problema è saltato fuori oggi dopo vent'anni, non è un caso.

Quindi quelli di Pale Moon sono dei genietti visionari o ci hanno preso per caso?

Inviato da borgata

Se proprio vogliamo buttarla sul complottismo secondo me è molto più probabile che Intel si sia resa conto da tempo del problema ma abbia preferito le prestazioni alla sicurezza, contando sul fatto che nessuno avrebbe tirato fuori un exploit. E invece Project Zero li ha messi con le spalle al muro.
Del resto può essere piuttosto conveniente acquisire un vantaggio sulla concorrenza a scapito della sicurezza, quando questa ha un costo prestazionale elevato

Ma quale complotto, questa è un'operazione commerciale e il fatto di aver reso pubblico il problema non fa altro che darne conferma.

Inviato da borgata

Il vero problema di queste vulnerabilità comunque è il comportamento di Intel a riguardo: a parte il cercare di minimizzare il problema e di fare tutta l'erba un fascio (come se i problemi degli altri fossero della stessa entità dei propri), le soluzioni proposte da Intel di fatto non tappano le falle ma forniscono gli strumenti per farlo. E questo significa che rimarrà in giro tanto software che sarà vulnerabile.
Non so se hai letto le esternazioni di Linus Torvalds (che, al solito, non le manda a dire), ma la sua indignazione era dovuta proprio al modo in cui Intel sta affrontando il problema.

Chiamali fessi... chissà perché lo fanno...
Le ho lette le esternazioni e sai a Intel quanto interesano?

Inviato da borgata

Le motherboard non c'entrano nulla, la vulnerabilità sta nei processori. E già da tempo si sapeva che questa generazione di motherboard sarebbe stata incompatibile con la prossima generazione.
Del resto nulla di diverso dal solito, Intel taglia la compatibilità con le schede madre ad ogni cambio di microarchitettura, stavolta ha fatto solo un po' peggio cambiandola per una semplice revisione (ma i motivi sono altri).

Centrano perché di fatto saranno da cambiare e le dovrà cambiare anche chi non voleva cambiare CPU. Mi pareva ovvio il motivo per cui le ho tirate in ballo...

Inviato da borgata

Secondo me stai ampiamente sopravvalutando la percezione di questo problema da parte della massa d'utenza: se ne sbatteranno quasi tutti.

Credo che sia tua la sottovalutazione di quanto faccia correre le persone la paura indotta. Aspetta, è ancora presto: tutti quelli che hanno la tendinite al polso destro e hanno imparato a usare il mouse con la sinistra non sanno nemmeno che esiste il "problema", ma chi di dovere penserà a mettere il sale sulla coda all'utenza a tempo debito... scommettiamo un caffè virtuale? (Scusa ma in Sardegna non vengo.)

Fatturato Intel 2016: 59,38 miliardi USD
Fatturato AMD 2016: 4,27 miliardi USD

Fine 2017: fatturato Intel in crescita, fatturato AMD in caduta libera.

L'unica preoccupazione di Intel è questa... fatturato soli chips SAMSUNG 69 miliardi USD ... di cosa stiamo parlando?

[LoryOne]

Inviato da retalv

Scherzi? Non è un errore di progettazione creare un sistema di sicurezza che non riesce a fare fino in fondo quello che deve?

Purtroppo no, non è possibile neppure progettarlo un sistema di sicurezza quale s'intende un antivirus , poichè il codice che da origine alla falla progettuale sfruttabile è del tutto lecito e non scindibile dalle comuni operazioni di accesso alla memoria lecite/illecite.
L'unica cosa che si può fare o che si è già fatto è :
- Aggiungere al kernel codice di verifica e controllo che ne rallenta inevitabilmente l'operatività.
- Virtualizzare il più possibile i browser nell'esecuzione di codice JavaScript
- Attendere che lo script malevolo sfruttabile, al quale può essere associata una firma, da quel momento diventi riconoscibile.
Il problema legato alla class action ai danni di Intel, è dovuto al fatto che se si mettono assieme le problematiche legate alla sicurezza di Meltdown e Spectre, il quadro che ne deriva è che i processori Intel (con produzione vecchia di addirittura 10 anni e più) risultano i più vulnerabili alle diverse varianti rispetto alla controparte AMD.
Un po come dire che Intel ha venduto per anni processori fallati, privilegiando le performances rispetto alla sicurezza operazionale delle sue unità di processo centrale ad un costo tale che, a valle della problematica esposta, non giustifica il prezzo corrisposto da ogni utente che l'abbia acquistate, soprattutto in ambito server.
Intel minimizza, però ammette il problema ed attraverso Brian Krzanich fa intendere che saranno poste in essere modifiche architetturali contro Meltdown/Spectre, ma SOLO su prodotti di futura commercializzazione.
Ergo...la problematica è hardware.

[borgata]

Inviato da retalv

Scherzi? Non è un errore di progettazione creare ...

Esattamente: è un errore di design, ma non un bug.
Un bug è quando facendo 2+2 anziché ottenere 4 ottengo 5. Se però ottengo 4 e 4 ti permette di fare cose non previste, allora non si chiama bug.
Ripeto, era solo una puntualizzazione, nulla di davvero importante in questo discorso.

Inviato da retalv

Quindi quelli di Pale Moon sono dei genietti visionari o ci hanno preso per caso?

Quelli di palemoon avevano solo supporto che per come lavora l'IMC si poteva essere vulnerabili. Ma qui non solo la questione è differente (non riguarda direttamente l'IMC) ma non era stato sviluppato neppure un "proof of concept" che mettesse in mostra il problema, era solo un'ipotesi.

Inviato da retalv

Ma quale complotto, questa è un'operazione commerciale e il fatto di aver reso pubblico il problema non fa altro che darne conferma.

Beh, questo genere di cose si chiamano complotti, al di la dell'accezione legata alla fantasia di alcune teorie che può essere data al termine.

Inviato da retalv

Centrano perché di fatto saranno da cambiare e le dovrà cambiare anche chi non voleva cambiare CPU. Mi pareva ovvio il motivo per cui le ho tirate in ballo...

Ripeto, l'incompatibilità delle schede madre era già prevista da tempo ed è in linea di massima operazione abituale per Intel ormai da parecchie generazioni. La questione di cui stiamo trattando non cambia nulla in tal senso.

Inviato da retalv

Fine 2017: fatturato Intel in crescita, fatturato AMD in caduta libera.

In realtà AMD ha concluso per la prima volta da molto tempo l'anno fiscale in positivo e in forte crescita, grazie ai nuovi prodotti del 2017, e la situazione non potrà che migliorare nel prossimo anno.

Inviato da retalv

Scusa ma in Sardegna non vengo

Ehehe ma perchè, è un bellissimo posto dove passare le vacanze!

[retalv]

Inviato da borgata

Ehehe ma perchè, è un bellissimo posto dove passare le vacanze!

Certo, ma non ci vengo uguale...

Inviato da borgata

In realtà AMD ha concluso per la prima volta da molto tempo l'anno fiscale in positivo e in forte crescita, grazie ai nuovi prodotti del 2017, e la situazione non potrà che migliorare nel prossimo anno.

Hai ragione i dati 2017 sono diversi.
Fatturato 2017: Intel 62,8 mld, AMD 5,33 mld
Utile operativo: Intel 5,4 miliardi di dollari, AMD 82 milioni di dollari ... c'è proprio da fare festa, l'utile operativo è meno di 1/5 riferito ai rispettivi fatturati... quando recuperano le passività pregresse?

Inviato da borgata

Ripeto, l'incompatibilità delle schede madre era già prevista da tempo...

Ripeto, non centra una cippa se è previsto che si cambi la scheda madre ad ogni nuova CPU, quello che non era previsto era di dover cambiare la CPU senza averne bisogno, la qual cosa si porta dietro anche la scheda madre. Se hai comprato A + B e dopo anni per qualche motivo sei "costretto" a ricomprare A è ovvio che dovrai comprare anche B che non è più compatibile con la nuova A e diventa anch'essa costrizione.

Inviato da borgata

Beh, questo genere di cose si chiamano complotti...

Fatti coraggio allora... è da quando hai cominciato a spendere denaro che sei vittima di complotti. Uno specifico abbastanza vecchio riguarda le sigarette, quando aggiungevano direttamente nicotina, poi altri componenti di concia del tabacco (ad azione nettamente più blanda della nicotina ma legali) per "fidelizzare" il consumatore ed incrementarne la dipendenza. Più in generale quello che tu chiami complotto è semplicemente creare un'esigenza, quello ch fanno o tentano di fare tutti i giorni le campagne pubblicitarie, ad esempio...

Inviato da borgata

Un bug è quando facendo 2+2 anziché ottenere 4 ottengo 5. Se però ottengo 4 e 4 ti permette di fare cose non previste, allora non si chiama bug. Ripeto, era solo una puntualizzazione, nulla di davvero importante in questo discorso.

Invece è molto importante, perché l'unica differenza tra un pallottoliere (2+2=4) e la central processing unit è la sezione logica. Nel primo è esterna (chi lo sta usando), nel secondo è pre-generata. Un "errore di design" come lo chiami tu è un errore di programmazione (voluto o fortuito) relativo alla logica di sicurezza che vuole proteggere dati sensibili riguardanti la computazione stessa.

Se la logica di sicurezza funziona avremo risultato VERO, ma se la logica è per qualche motivo fallace e permette il superamento anche parziale di se stessa, malgrado la logica di funzionamento continui a dare risultato VERO (fa quello per cui è stata scritta sul silicio) la logica intrinseca non fornisce il medesimo stato della logica operativa, alias fornisce FALSO (2+2<>4).

Da quel poco che ho capito, il microcodice è un interprete scritto in codice macchina che si interpone tra l'hardware e l'architettonica del computer. A grandi linee mi risulta essere, in questo caso, una patch tale e quale a quelle che vengono applicate ai software, solo che avendo a che fare con silicio immodificabile si è costretti ad operare in un livello esterno alla CPU.

Se da una macchina virtuale interagisci nelle aree di memoria delle altre senza aver impostato i permessi lo chiami BUG, se lo fa la CPU lo chiami vulnerabilità? Se per correggere un problema di logica di un software applichi una patch e per un problema di logica di una CPU applichi un microcodice, dove sta la differenza?

-----------------------------

Non sono un tecnico quindi non riesco a controbattere efficacemente alle vostre argomentazioni sulla cosa, ma mi piacciono le similitudini: anche questa volta vorrei farvene una... vi farà passare qualche secondo...

In un Comune d'Italia (il classico utente di PC) viene deciso di acquistare un nuovo e moderno autobus (CPU) equipaggiato di guida autonoma. L'addetto porta l'autobus ad uno dei due capolinea, carica la mappa della città, definisce il percorso, le fermate obbligatorie e quelle a sola richiesta e il secondo capolinea, quindi avvia il sistema e scende dall'autobus.

La guida autonoma si collega ai satelliti per avere le coordinate sulla propria posizione, analizza la mappa e sceglie il percorso in modo da coprire l'intero tracciato di fermate e raggiungere il capolinea opposto quindi analizza i limiti di velocità imposti dal codice stradale cittadino per ottenere una stima sui tempi di percorrenza.

L'autobus chiude le porte e si avvia alla prima fermata. A questa salgono due uomini e una ragazza (Word, PDFCreator ed Excel): vidimano il biglietto e si mettono a sedere presi nei loro impegni.

L'autobus raggiunge la seconda fermata. A questa salgono altre due donne (KeePass e Malwarebytes) e scende uno degli uomini (Word): tutte vidimano il biglietto e si siedono.

L'autobus raggiunge la terza fermata. Salgono altre due donne (VirtualBox e Syncovery) ma nessuno scende.

Alla quarta fermata nessuno sale e nessuno fa richiesta per scendere. L'autobus prosegue.

Alla quinta fermata sale un ragazzo assieme a due donne (VMware Workstation e Firefox) ma nessuno scende. Il ragazzo è zoppicante e Firefox lo aiuta a salire. Le donne vidimano il biglietto: VMware Workstation si siede dietro alla donna della terza fermata (VirtualBox), ma davanti a KeePass. Il ragazzo non vidima alcun ticket (abbonato?) e senza dare nell'occhio si avvicina alle tre donne.

Alla sesta fermata la guida autonoma si accorge che uno dei passeggeri non ha ancora vidimato il biglietto/abbonamento. Il progettatore della guida autonoma ha considerato l'eventualità di un viaggio a scrocco, quindi la soubroutine avverte la centrale operativa della presenza di un "portoghese" a bordo (eccezione o come la volete chiamare), carica altri 8 passeggeri e prosegue nella corsa.

Settima fermata e l'autobus si ferma ma non apre le porte di discesa-salita: la logica di programmazione obbliga lo stazionamento in attesa degli accertatori del titolo di viaggio.
Il ragazzo, che aveva appena sfilato il borsellino dalla borsa di KeePass, comincia ad avere paura e fa cose che a mente lucida non avrebbe mai fatto: prende ad ostaggio le due donne a lui più vicine VirtualBox e VMware Workstation minacciandole con un coltello a serramanico di 12cm!

Lui non sa che entrambi sono incinte: VirtualBox presa dalla concitazione sviene e questa sarà la sua fortuna ma VMware Workstation, donna più matura, cerca di far ragionare il ragazzo. Questo, ormai fuori di testa, trafigge al fianco la donna semplicemente per farla stare zitta. Vedendo quello che succede, Firefox che è una ragazza di 20 anni, sviene. Malwarebytes che è guardia giurata ma disarmata non ha giurisdizione in quella situazione e vedendo il coltello in pugno al ragazzo rimane inerme. Il ragazzo resosi finalmente conto di ciò che ha appena fatto, rompe il vetro che funge da uscita di sicurezza e fugge. Dopo pochi minuti l'autobus viene raggiunto dagli accertatori del titolo di viaggio che non possono fare altro che constatare quello che è appena accaduto e a loro volta chiamare le forze dell'ordine.

I presenti non possono che raccontare l'accaduto: Firefox si riprende dallo svenimento, e VMware Workstation prende la strada dell'obitorio. Le forze dell'ordine eseguono le rilevazioni del caso avviando l'ovvia ricerca dell'assassino. Dopo 8gg dal fatto KeePass si presenta in questura per la denuncia di azioni fraudolente sul suo conto corrente.

-----------------------------

La dichiarazione del produttore dell'autobus riguardo l'accaduto fu ...

"Ci rammarichiamo di non aver saputo preventivare una escalation di situazioni avverse e nel futuro attueremo i provvedimenti del caso per prevenire il ripetersi di situazioni similari. Teniamo però a precisare che il sistema intrinsicamente non ha fallito e potremmo dire che in qualsiasi momento della vicenda 2 + 2 ha sempre dato come risultato 4. Esprimiamo il nostro cordoglio ai parenti delle vittime."

Ecco... vorrei che ora qualcuno spiegasse ai figli di VMware Workstation e a KeePass che quanto successo è imputabile a un "errore di design" o vulnerabilita di sistema e che VMware Workstation è (purtroppo) un "danno collaterale" all'errore di design, insomma che qualcuno spiegasse loro che sarebbe bastato aver implementato un design lungimirante.

In altre parole, il sistema ha funzionato perfettamente e non esiste un bug del sistema ma il bug era solo nella LOGICA del progettista e della direzione aziendale dell'azienda che ha ponderato come più "importante" il sicuro recupero di quell'euro di biglietto (velocità processore) al posto di una seppure poco probabile "svolta avversa".

[LoryOne]

Tratto da qui: https://meltdownattack.com/

What is the difference between Meltdown and Spectre?
"Meltdown breaks the mechanism that keeps applications from accessing arbitrary system memory."
Qui si sta parlando del kernel del S.O.
Liberamente tradotto, Meltdown rompe quei meccanismi che mantengono le applicazioni al di fuori della possibilità di leggere indirizzi di memoria arbitrari. Arbitrari significa TUTTO l'address space.
Il kernel address space e lo user address space sono tenuti distinti dal S.O. che quando carica il sistema DEVE necessariamente avere i privilegi al di sopra dell'admin, ossia SYSTEM.
"Consequently, applications can access system memory."
Di conseguenza, le applicazion in user space possono bypassare i meccanismi di protezione del kernel per leggere memoria in kernel space.
Fin qui sembrerebbe tutta colpa del S.O., eppure è qui che casca l'asino: è la logica operazionale interna del processore che lo consente, bypassando il S.O.
Ecco perchè deve essere aggiunto codice al kernel per prevenire cio che il processore consente al di la dei limiti imposti dal sistema.
Microcodice e patch del S.O. devono lavorare in tandem, poichè l'uno non esclude l'altro.
"Spectre tricks other applications into accessing arbitrary locations in their memory. Both attacks use side channels to obtain the information from the accessed memory location."
Spectre mette a disposizione ad applicazioni diverse, di accedere ad address space in memoria che diviene condivisa tra le applicazioni <<e aggiungo che sempre grazie al S.O. dovrebbe essere distinta>>. Entrambi gli attacchi fanno uso del side channel (canale di comunicazione tra address space) per ottenere le informazioni tra locazioni di memoria accessibili.
Fin qui sembrerebbe tutta colpa del S.O., eppure è qui che casca l'asino: è la logica operazionale interna del processore che lo consente, bypassando il S.O.
Ma allora il software non c'entra nulla ?
Si, eccome: Uno script fa uso di istruzioni che mettono il processore in condizione di fare uso della sua logica funzionale fallata, pertanto accedono ad informazioni che il S.O. considera protette e che invece non lo sono più a causa del processore.

Torvalds dice ad Intel che il suo microcodice è spazzatura, è colpa dell'hw, ma il kernel viene rivisto ed appesantito. Lo stesso fa Microsoft, che però non può dare addosso ad Intel.
Intel asserisce che quel che è fatto è fatto, si rivedrà la logica operazionale nel processo di produzione futuro per le future CPU.
Nel mezzo si pone AMD che invece non risulta fallace per lo stesso numero di varianti che affliggono Intel e che, per tale motivo, potrà essere in posizione di vantaggio nel futuro acquisto da parte dell'utenza...Mah, previsioni un po troppo rosee, visto che non è immune al 100% ed il processo produttivo è avviato anche per lei.
Porre un rimedio al volo lato software è la "soluzione" (chiamiamola palliativo) nell'immediatezza della circostanza.
Al momento, non si evidenziano colpi riusciti, ma se ci fate caso chiunque, in tutti questi anni, potrebbe aver scritto codice all'apparenza innocuo (magari anche considerato spazzatura) per applicazioni considerate lecite senza nemmeno rendersi conto di aver sollevato l'eccezione e non essere stato in grado di sfruttarla...oppure si ?: I processori incriminati, sono anni che si comportano così.

[retalv]

Inviato da LoryOne

Tratto da qui: https://meltdownattack.com/

Grazie.

Inviato da LoryOne

Al momento, non si evidenziano colpi riusciti, ma se ci fate caso chiunque, in tutti questi anni, potrebbe aver scritto codice all'apparenza innocuo (magari anche considerato spazzatura) per applicazioni considerate lecite senza nemmeno rendersi conto di aver sollevato l'eccezione e non essere stato in grado di sfruttarla...oppure si ?: I processori incriminati, sono anni che si comportano così.

Vero.

Quando scrivevo "a pappagallo" di venti anni senza evidenze mi mettevo a ridere... non è mai stato usato solo perché nessuno se n'è accorto... ma dai..! sarebbe come credere che nessuna agenzia ha mai usato soluzioni analoghe solo perché nessuno se n'è reso conto.

Leggevo che anche la famiglia dei Qualcomm® Snapdragon™ è affetta da questi "problemini" e che il peggiore è il 845 che può vantare tutto il cucuzzaro.

Immagino che i device più a rischio siano proprio questi semplicemente perché solitamente online H24 con Android. Vuoi usare lo smatphone per tutto..? Il piatto è servito!

[borgata]

Inviato da LoryOne;

Entrambi gli attacchi fanno uso del side channel (canale di comunicazione tra address space) ...

Giusto un appunto. Il "side channel" non è un canale di comunicazione che viene utilizzato nell'attacco, ma una tecnica di attacco che sfrutta le peculiarità hardware di un sistema per violarlo ("side channel" quindi nel senso di "con metodi alternativi").

In questo caso si parla di "Cache timing side-channels", ossia di metodi di attacco che utilizzano le temporizzazioni della cache.

Inviato da retalv;

Hai ragione i dati 2017 sono diversi.
Fatturato 2017: Intel 62,8 mld, AMD 5,33 mld
Utile operativo: Intel 5,4 miliardi di dollari, AMD 82 milioni di dollari ... c'è proprio da fare festa, l'utile operativo è meno di 1/5 riferito ai rispettivi fatturati... quando recuperano le passività pregresse?

Beh, non vorrai paragonare i risultati finanziari di un colosso come Intel con quelli di un'azienda di dimensioni molto minori come AMD.
La situazione di AMD fino a poco tempo fa era critica: un debito a lungo termine di due miliardi in scadenza, fondo cassa al limite e bilancio in rosso da anni. Adesso ha finalmente chiuso l'anno in positivo, ha un fondo cassa adeguato per non soffocare a causa del debito ed è in crescita grazie ai suoi prodotti. Direi che la situazione è rosea oltre le previsioni che si potevano fare fino a non molto tempo fa.

Inviato da retalv;

Ripeto, non centra una cippa se è previsto che si cambi la scheda madre ad ogni nuova CPU, quello che non era previsto era di dover cambiare la CPU senza averne bisogno, la qual cosa si porta dietro anche la scheda madre.

Beh, certamente.
Ma sono abbastanza sicuro che ben pochi sentiranno l'esigenza di aggiornare il proprio computer, per lo meno in ambito consumer. In ambito enterprise dipenderà da quanto le patch incideranno sulle prestazioni.
E poi, come dicevo, rimane sempre il "problema" AMD che oggi, a differenza del recente passato, offre prodotti competitivi su cui chi aggiorna potrebbe indirizzarsi.

Inviato da retalv;

Più in generale quello che tu chiami complotto ...

Non sono io a chiamarli complotti, è semplicemente il loro nome, ed è slegato dall'accezione di complotto inteso come "teoria strampalata".
Anche qui comunque non mi sembra il caso di insistere sui termini, l'importante è capirsi.

Inviato da retalv;

Invece è molto importante, ...

Non è importante nel senso che alla fine si tratta di una questione di lana caprina. Colloquialmente puoi chiamarlo bug se vuoi, ma tecnicamente è sbagliato (e certamente non ci strapperemo i capelli per questo).

In questo caso si sta creando un sistema talmente complesso che è estremamente difficile determinare tutte le possibilità che la combinazione dei vari fattori può dare. Il sistema si comporta come progettato, chi l'ha progettato però non ha previsto (o l'ha previsto e se ne è fregato) che potesse essere utilizzato in modo tale da violare la sicurezza del sistema.

Inciso: ll microcodice è un po' il "software dell'hardware", ossia un software che agisce a bassissimo livello e viene preso in pasto direttamente dalla logica in hardware. Esempio tipico: un'istruzione complessa viene tradotta dal microcodice in più semplici istruzioni implementate in hardware.
Processori molto semplici (come i primi RISC) non avevano microcodice ma eseguivano tutte le istruzioni direttamente in hardware.
Il vantaggio del microcodice è la possibilità di aggiornarlo per correggere dei bug o dei problemi di design del processore, o persino migliorarne le capacità. Lo svantaggio è che di norma le funzionalità hardware sono più efficienti (ma allo stesso tempo istruzioni troppo semplici rendono complesso il software, e istruzioni troppo complesse in hardware hanno un elevato costo implementativo).

Inviato da retalv;

Se da una macchina virtuale interagisci nelle aree di memoria delle altre senza aver impostato i permessi lo chiami BUG, se lo fa la CPU lo chiami vulnerabilità?

Ancora una volta: no.
Dove stia il problema non è importante, la differenza tra bug e difetto di design sta nel tipo di problema, non nel "luogo" in cui si verifica. Vulnerabilità è generico, si può essere vulnerabili per esempio sia a causa di un bug o di un difetto di design.
Se io mi aspetto un risultato e ne ottengo un altro è un bug. Se io ottengo il risultato che pensavo di ottenere ma questo mi crea problemi, è un difetto di design.

Perdonami se non leggo la metafora!

[retalv]

Inviato da borgata

Non sono io a chiamarli complotti, è semplicemente il loro nome, ed è slegato dall'accezione di complotto inteso come "teoria strampalata".

Ma anche no. Il "complotto" generalmente è tale quando lo sgami prima che sia portato a termine, quando è andato a segno prende vari altre definizioni, ad esempio truffa.

Inviato da borgata

Se io mi aspetto un risultato e ne ottengo un altro è un bug. Se io ottengo il risultato che pensavo di ottenere ma questo mi crea problemi, è un difetto di design.

Bene, mi aspettavo che certe aree di memoria non potessero essere lette. Per un errore di design possono leggerle. Quindi è un bug.

[borgata]

Inviato da retalv

Bene, mi aspettavo che certe aree di memoria non potessero essere lette. Per un errore di design possono leggerle. Quindi è un bug.

In realtà quelle aree di memoria non vengono lette, ma è possibile leggere una copia di dati normalmente non accessibili in cache tramite un "side channel attach" basato sulle temporizzazione della cache.
Quindi è un difetto di design!

Per capire di che tipo di vulnerabilità stiamo parlando, è come se io riuscissi a leggere un dato nel registro di un processore monitorando la temperatura in una certa area del chip.
Non mi pare di poter dire che il chip sia buggato per questo, eppure sono in grado di leggere il dato e violare la sicurezza, cosa che ovviamente non era prevista.
Del resto il processore funziona correttamente, non ho solo pensato che qualcuno poteva leggere un dato misurando la temperatura.
L'esempio è un po' fantasioso (ma neppure troppo!), ma era giusto per far capire perchè non si parla di bug.

Inviato da retalv

Ma anche no. Il "complotto" generalmente è tale quando lo sgami prima che sia portato a termine, quando è andato a segno prende vari altre definizioni, ad esempio truffa.

Francamente non ho mai sentito una definizione del genere.
Ho dato quindi un'occhiata alle definizioni dei vari dizionari online e non mi pare si accenni a nulla del genere. Hai sotto mano una fonte autorevole?

[borgata]

Inviato da retalv

Quando scrivevo "a pappagallo" di venti anni senza evidenze mi mettevo a ridere... non è mai stato usato solo perché nessuno se n'è accorto... ma dai..! sarebbe come credere che nessuna agenzia ha mai usato soluzioni analoghe solo perché nessuno se n'è reso conto.

Io non penserei solo alle agenzie governative (nel qual caso si potrebbe anche pensare a qualcosa di voluto), ma anche a cybercriminali che ovviamente si sono ben guardati dal diffondere notizia di questa gallina dalle uova d'oro.

É proprio a causa di questo rischio che il problema è stato rivelato pubblicamente, perchè l'unico modo per essere sicuri è quello di porre rimedio al problema, non certo nascondere la testa sotto la sabbia.
Del resto, come avevo già scritto, ormai è noto che la "security by obscurity" non funziona.

Inviato da retalv

Leggevo che anche la famiglia dei Qualcomm® Snapdragon™ è affetta da questi "problemini" e che il peggiore è il 845 che può vantare tutto il cucuzzaro.

Il problema affligge praticamente tutti i processori ARM ad alte prestazioni, ossia quelli che fanno uso di esecuzione speculativa.
Questo significa che buona parte dei processori top di gamma da varie generazioni a questa parte sono vulnerabili (chi più chi meno), mentre quelli con core a basso consumo sono "by design" immuni (essendo processori in order).

[retalv]

Inviato da borgata

Francamente non ho mai sentito una definizione del genere.
Ho dato quindi un'occhiata alle definizioni dei vari dizionari online e non mi pare si accenni a nulla del genere. Hai sotto mano una fonte autorevole?

Fonte autorevole..? Su internet..?

Comunque non c'è bisogno di accennarlo, è intrinseco nella definizione stessa... un monarca non lo "complotti" ma semmai lo destituisci tramite un complotto o ancor meglio una cospirazione.

http://www.treccani.it/vocabolario/complotto/
http://www.treccani.it/vocabolario/congiura/
http://www.treccani.it/vocabolario/cospirazione/

Devoto - Oli
Vocabolario della lingua italiana

Complotto
Intrigo rivolto copertamente a dano di enti o persone determinate.
Complottare
Tramare, macchinare di nascosto a danno dell'autorità o del prossimo.
Cospirazione
Concorso di persone o di energie (non necessariamente ostili) a un determinato fine (non necessariamente dannoso).

[LoryOne]

Inviato da borgata

Giusto un appunto. Il "side channel" non è un canale di comunicazione che viene utilizzato nell'attacco, ma una tecnica di attacco che sfrutta le peculiarità hardware di un sistema per violarlo ("side channel" quindi nel senso di "con metodi alternativi").

In questo caso si parla di "Cache timing side-channels", ossia di metodi di attacco che utilizzano le temporizzazioni della cache.

Puntualizzazione più che corretta, direi tecnicamente doverosa, che sviscera ancora più a fondo la problematica.

[LoryOne]

Inviato da borgata

cut..
Inciso: ll microcodice è un po' il "software dell'hardware", ossia un software che agisce a bassissimo livello e viene preso in pasto direttamente dalla logica in hardware. Esempio tipico: un'istruzione complessa viene tradotta dal microcodice in più semplici istruzioni implementate in hardware. cut...

Concordo.
Pensiamo ad un processore come un foglio sottile che contiene transistors, resistenze, condensatori e diodi, tutti uniti da piste che consentono alla corrente di scorrere tra le componenti hw e fornire tensioni e correnti in uscita distinte da quelle in ingresso, che costituiscono un output per uno stadio ed un input per un altro a catena: Pensiamo anche che, per produrre un'operazione complessa, sia necessario scomporre tale operazione in più istruzioni basilari da dare in pasto alla logica circuitale per coordinare adeguatamente i componenti hw interessati; Ogni processore, quindi, possiede la conoscenza di molte operazioni basilari per eseguire molte operazioni complesse, ma se opportunamente istruito su quali e quante istruzioni basilari impiegare per svolgere più operazioni con un unica istruzione, il suo set d'istruzioni si riduce a favore di una sola chiamata per svolgerne diverse altre.
Chiamiamo lo "spezzone di codice" che si frappone fra l'istruzione unica invocata che compie diverse operazioni e quelle basilari impegnate, microcodice. Se il microcodice può subire un update o un upgrade, è possibile correggere "al volo" il comportamento del processore nell'eseguire l'istruzione invocata.

[borgata]

Inviato da retalv

Comunque non c'è bisogno di accennarlo, è intrinseco nella definizione stessa...

Beh oddio... non mi pare affatto!
Del resto, anche tu subito dopo scrivi:

Inviato da retalv

... un monarca non lo "complotti" ma semmai lo destituisci tramite un complotto o ancor meglio una cospirazione.

Il monarca è stato destituito in seguito ad un complotto, quindi anche se il complotto è giunto a compimento sempre di complotto si parla.
Direi che il chiamarsi complotto non dipenda affatto ne dall'esito ne dal momento in cui lo si cita, ossia se prima o dopo il suo compimento (a parte i discorsi sul revisionismo storico dei vincitori, ovviamente ).

Comunque è solo un termine, non credo pregiudichi il discorso che stavamo facendo.

PS: beh dai, anche in rete trovi fonti autorevoli, il sito web della treccani per esempio lo considero tale in questo contesto.