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

[TheQ.]

maaaaa dopo la patch perchè se lancio la conversione di un video da 4 Gb della telecamera il processore va al 46% di 2.93GHz invece che al 100%?

[TheZioFede]

la questione di android è sempre la solita alla fine... è vero che treble toglie la scusa dei driver ma dubito che per i terminali di fascia basa cambierà molto...
alla fine ci guadagno abbastanza poco vendendo quelli anche con supporto quasi nullo...

[Yrbaf]

Originariamente inviato da rockroll

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

Oltre a quanto già consigliato puoi consultare le dispense in Italiano del corso di Architetture II dell'Università di Torino.

Cerca Gunetti (che è un docente) + architettureII e troverai la pagina del sito con i pdf delle Slide che spiegano parecchia roba (in modo abbastanza comprensibile ma ovviamente un minimo di basi le richiedono) e con i rimandi a testi (almeno 3) da consultare per approfondimenti.

Ah non centrano nulla con questo bug, sono solo corsi su RISC, ILP (statica e dinamica), Branch Prediction Speculativa e non, MultiIssue, Cache, Architetture dei processori moderni con vari casi concreti esaminati, ...ecc

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

L'elaborazione out of order è sicuramente più onerosa ed infatti richiedendo anche più energia di solito i processori più parsimoniosi (vedi Atom, almeno quelli vecchi, ma anche molti Arm) sono InOrder.
Però i più veloci sono invece OoO.

Non è lavoro inutile perché tu fai del lavoro nella speranza che sia produttivo.
Le istruzioni speculative è vero che se il salto (o cambio di Program Counter) è predetto in modo errato sono lavoro inutile che potrebbe generare pure ulteriore lavoro per l'operazione di undo.
Ma è anche vero che tu speri di azzeccare spesso/con elevata incidenza (sempre è statisticamente impossibile) la predizione e quindi quando questo avviene ti sei solo portato avanti a fare lavoro che tanto dovevi comunque fare.

Ovvio che se i meccanismi di predizione sono poco efficienti allora alla fine vai più piano che senza questi sofismi.
E' lo stesso con la cache.
Un sistema dotato di cache ha tempi di accesso alla ram più lenti di un sistema senza cache (perché devi attraversare tutti i livelli di cache).
Però poi tu conti sul fatto che per pochi cache miss totale (con hit in ram) avrai molti cache hit conseguenti.
Certo che se fai solo cache miss allora un sistema senza cache andrebbe più veloce di te.

[HSH]

ma le vecchie cpu tipo Marvell Armada , kirkwood armv7 sono affette anche loro?

[cdimauro]

Originariamente inviato da yeppala

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

E' lo stesso telefono delle donne di casa. Come va? Hai avuto cali prestazionali?

Originariamente inviato da Lampetto

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

Tranquillo: è un forum di discussione, dove chiunque può dire la sua. Qui non stiamo parlando di questione tecniche, peraltro.

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

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

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

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

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

Non è questo il punto. Il punto è che Microsoft aveva annunciato l'aggiornamento a W10M di tutti i dispositivi WP8, e non l'ha fatto. Non c'entrano niente i 36 mesi di supporto: avrebbe dovuto mantenere la parola data.

A saperlo prima NON avrei comprato quei telefoni.

Inoltre aveva già lasciato a piedi me, che sono stato un pioniere, prendendo uno dei primi WP7, che ha aggiornato soltanto fino alla 7.8 e lasciandomi quindi a piedi.

Per cui la terza possibilità non gliela concedo più: Microsoft ha finito con me per quanto riguarda gli smartphone. A meno che non riuscirà ad avere quote di mercato comparabili agli altri player E un parco app dello stesso livello.

/OT.

[cdimauro]

Originariamente inviato da pabloski

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

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

Decisamente drastica. Comporterà un notevole calo delle prestazioni. Ci sono benchmark pre-post patch?

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

Interessante.

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

Questo, lo dovresti sapere, è un non-sequitur: sono due cose logicamente diverse che non c'entrano niente l'una con l'altra.

[cdimauro]

Originariamente inviato da Erotavlas_turbo

Complotto? Già dimenticato lo scandalo Prism nel NSA del 2013 e lo scandalo Vault 7 del 2017 CIA? Queste sono forme volute di controllo da parte degli USA verso gli altri stati dato che le CPU Intel sono prodotte in USA sotto il controllo del governo tramite NSA e CIA.

Sì, già dimenticato. Passiamo avanti, visto che è il solo spauracchio complottista che viene tirato fuori regolarmente ogni volta che si parla di problemi di sicurezza.

In realtà, Intel sapeva dei bug delle loro CPU dal 2007 dai tempi dell'architettura core 2 fonte e sembra che abbia modificato la gestione della memoria introducendo e mantenendo i bug.

Il link l'hai letto? Mi pare di no. Non è che puoi postare cose a caso quando il thread parla di SPECIFICHE vulnerabilità, e ricamarci sopra il classico fantascenario complottista.

Potresti cortesemente DIMOSTRARE come da quel link si arrivi alla fantasticheria che ti sei sparato più sotto?

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

Il microcodice delle CPU e l'IME sono due cose COMPLETAMENTE DIVERSE.

Così, tanto per continuare sulla scia di cose messe assieme a caso, solo perché si parla di sicurezza.

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

Ho già letto tutto. E t'è sfuggito anche un link che riporta una graziosa tabella con diversi processori ARM che sono affetti ANCHE da Meltdown.

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

Vedi sopra: questo è puro complottismo basato su un link sparato ad muzzum solo perché si parla di sicurezza.

DIMOSTRA come da quel link si arrivi allo scenario allucinante che ti sei inventato di sana pianta.

D'altra parte ti ricordo che l'onere della prova è tuo, visto che è la TUA tesi.

Ne abbiamo parlato anche in altre sedi. Un software o hardware closed source non ti garantisce alcuna trasparenza e la storia recente parla chiaro. Le corrispondenti versioni open forniscono trasparenza e permettono di risolvere prima il problema.

Sì, ne abbiamo già parlato, e ti ho portato una DIMOSTRAZIONE (Teorema, in realtà) che l'open di per sé NON garantisce alcunché.

Dimostrazione che né tu né altri avete minimamente scalfito, a parte cercare di aggirarla con giochetti di parole, perché dovreste riscrivere la matematica per piegarla alle vostre fantasie.

Anche Snowden auspica l'adozione di hardware o software open source fonte e lui conosce bene la situazione.

Puoi anche chiedere a lui che smonti il mio teorema, allora: tanto è del campo e gli sarà facile, no?

In mancanza mi attengo a ciò che ho dimostrato.

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

Mi quoto:

"ti ho portato una DIMOSTRAZIONE (Teorema, in realtà) che l'open di per sé NON garantisce alcunché."

[cdimauro]

Originariamente inviato da Sandro kensan

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

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

mettono insieme il branch prediction con la speculative execution in un bel esempio molto facile da comprendere.

Al momento non ho tempo di leggere anche quel link, perché sono esausto.

A naso direi che la branch prediction venga utilizzata soltanto nei casi di Spectre.

In Meltdown ti serve l'esecuzione speculativa + l'out-of-order. Non si affida affatto alla branch prediction.

Invece il paper che mi hai suggerito di leggere è troppo complicato e non ci sono esempi nel testo che mi permettono di seguire i lunghi discorsi che loro fanno nel paper. Troppo complicato per me questo metodi di apprendimento e comprensione. È come comprendere un teorema senza formule ma con una descrizione a parole come facevano gli antichi: troppo complicato.

Posso confermarti che è un paper abbastanza complesso da digerire per chi non è ferrato con gli argomenti.

Lascia perdere: c'è da mettersi le mani nei capelli (per chi li ha ) per capire la genialata che si trova dietro a Meltdown. Tanto di cappello, veramente, a chi l'ha scoperto.

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

In estrema sintesi, sì, ma manca un pezzo dello scenario (il ruolo che ha il probe array) che è molto interessante ed è la chiave per capire come funziona l'attacco.

Posso confermare, peraltro, che le mie idee sono applicabili ai casi descritti nel paper Meltdown.

Però un amico mi ha inviato un link a un tweet in cui uno studente è riuscito a sniffare la memoria del kernel senza gli espedienti del paper. Per cui in questo caso le mie contromisure non dovrebbero funzionare; ma mancano di PoC di questo tizio, non posso confermare al momento.

[Yrbaf]

Originariamente inviato da HSH

ma le vecchie cpu tipo Marvell Armada , kirkwood armv7 sono affette anche loro?

Il kirkwood se non ricordo male è ARMv5 e quindi in order e senza speculazione.
Ergo non soffre del problema.

Nella famiglia Armada però ci sono un sacco di processori di cui alcuni Out of Order (es. quelli basati su Cortex A9, A15, A57) e quindi alcuni modelli potrebbero essere affetti.

PS
Mi pare di aver visto che Cortex A8 sia nella lista degli affetti dai problemi, anche se A8 è un processore InOrder.
Mentre non sono affetti (tutti InOrder) A5, A7, A35, A53, A55

[cdimauro]

Originariamente inviato da Yrbaf

L'elaborazione out of order è sicuramente più onerosa ed infatti richiedendo anche più energia di solito i processori più parsimoniosi (vedi Atom, almeno quelli vecchi, ma anche molti Arm) sono InOrder.
Però i più veloci sono invece OoO.

Non è lavoro inutile perché tu fai del lavoro nella speranza che sia produttivo.
Le istruzioni speculative è vero che se il salto (o cambio di Program Counter) è predetto in modo errato sono lavoro inutile che potrebbe generare pure ulteriore lavoro per l'operazione di undo.
Ma è anche vero che tu speri di azzeccare spesso/con elevata incidenza (sempre è statisticamente impossibile) la predizione e quindi quando questo avviene ti sei solo portato avanti a fare lavoro che tanto dovevi comunque fare.

Ovvio che se i meccanismi di predizione sono poco efficienti allora alla fine vai più piano che senza questi sofismi.
E' lo stesso con la cache.
Un sistema dotato di cache ha tempi di accesso alla ram più lenti di un sistema senza cache (perché devi attraversare tutti i livelli di cache).
Però poi tu conti sul fatto che per pochi cache miss totale (con hit in ram) avrai molti cache hit conseguenti.
Certo che se fai solo cache miss allora un sistema senza cache andrebbe più veloce di te.

*

C'è sempre un trade-off. In questo caso il fatto che Meltdown sia presente a partire dal PentiumPro, che è la prima CPU out-of-order di Intel (il precedente Pentium era in-order), dovrebbe far capire che non è stato un atto voluto, ma un errore di distrazione dei progettisti che non hanno tenuto conto di scenari complicati come quelli che sono descritti nel paper Meltdown, per quanto riguarda esclusivamente la sicurezza (visto che i processori operano correttamente con tutti i calcoli che gli vengono dati in pasti).

La macchinosità di Meltdown dovrebbe essere garanzia, per chi ha avuto modo di sbatterci le corna e studiarsela, che non stiamo parlando cose banalotte, come il dottore che dimentica la pinza nella pancia del paziente, ma di questioni estremamente complicate che possono sfuggire a quelli che, in ultima analisi, sono pur sempre degli esseri umani e... sbagliano.

Poi, vabbé, sappiamo che i forum sono pieni di geni delle microarchitetture (non sto riferendo a te, sia chiaro. ) che si sentono in diritto di pontificare pur non avendo la minima idea di quello che dicono...

Originariamente inviato da HSH

ma le vecchie cpu tipo Marvell Armada , kirkwood armv7 sono affette anche loro?

C'era una tabella, ma non trovo più il link.

Comunque se sono processori out-of-order, è possibile che siano affetti.

[Sandro kensan]

Originariamente inviato da cdimauro

Al momento non ho tempo di leggere anche quel link, perché sono esausto.

A naso direi che la branch prediction venga utilizzata soltanto nei casi di Spectre.

In Meltdown ti serve l'esecuzione speculativa + l'out-of-order. Non si affida affatto alla branch prediction.

Mi sa che ho fatto confusione. C'è un if, un branch, nell'algoritmo ma non viene sfruttata la predizione. In effetti viene sfruttata l'esecuzione speculativa e l'out of order.

[Erotavlas_turbo]

Originariamente inviato da cdimauro

Sì, già dimenticato. Passiamo avanti, visto che è il solo spauracchio complottista che viene tirato fuori regolarmente ogni volta che si parla di problemi di sicurezza.

Mi fa ridere quando le persone pur di nascondere la realtà utilizzano la parola complottista.
Mi dispiace aver toccato la tua ex Intel, i dati e i fatto parlano chiaro fonte. Poi puoi continuare a dire ciò che vuoi. L'importante è credere alle favole.

Originariamente inviato da cdimauro

Il link l'hai letto? Mi pare di no. Non è che puoi postare cose a caso quando il thread parla di SPECIFICHE vulnerabilità, e ricamarci sopra il classico fantascenario complottista.

Potresti cortesemente DIMOSTRARE come da quel link si arrivi alla fantasticheria che ti sei sparato più sotto?

Certo, Intel ha cambiato la gestione della memoria MMU:

Basically the MMU simply does not operate as specified/implimented in previous generations of x86 hardware. It is not just buggy, but Intel has gone further and defined "new ways to handle page tables" (see page 58).

Non sono parole mie, ma dello sviluppatore di openSSL che ne capisce molto più di chiunque in questo forum senza offesa fonte.

Originariamente inviato da cdimauro

Il microcodice delle CPU e l'IME sono due cose COMPLETAMENTE DIVERSE.
Così, tanto per continuare sulla scia di cose messe assieme a caso, solo perché si parla di sicurezza.

Certo che sono cose diverse, il risultato ottenuto è lo stesso un trojan nella CPU.

Originariamente inviato da cdimauro

Ho già letto tutto. E t'è sfuggito anche un link che riporta una graziosa tabella con diversi processori ARM che sono affetti ANCHE da Meltdown.

Si e no. Solo alcune architetture ARM e i problemi sono risolvibili senza cambiare CPU diversamente da Intel. Anche tu non hai letto con dettaglio fonte.

Originariamente inviato da cdimauro

Vedi sopra: questo è puro complottismo basato su un link sparato ad muzzum solo perché si parla di sicurezza.

DIMOSTRA come da quel link si arrivi allo scenario allucinante che ti sei inventato di sana pianta.

D'altra parte ti ricordo che l'onere della prova è tuo, visto che è la TUA tesi.

Cosa devo dimostrare? Il programmatore di openSSL dice chiaramente di non comprare le CPU Intel architettura core 2 perché sono buggate dal punto di vista della sicurezza fonte. Dato che adesso è emerso un problema riconducibile al cambio di gestione della memoria avvenuto a suo tempo...basta fare uno più uno. Non ho dimostrazioni matematiche ne della validità ne della falsificazione della mia tesi.

Originariamente inviato da cdimauro

Sì, ne abbiamo già parlato, e ti ho portato una DIMOSTRAZIONE (Teorema, in realtà) che l'open di per sé NON garantisce alcunché.

Dimostrazione che né tu né altri avete minimamente scalfito, a parte cercare di aggirarla con giochetti di parole, perché dovreste riscrivere la matematica per piegarla alle vostre fantasie.

Ma quale dimostrazione? Non c'è nessuna dimostrazione in nessun senso ne che il codice open sia più sicuro ne il contrario. Io vedo solo incapacità di analizzare fatti.

Originariamente inviato da cdimauro

Puoi anche chiedere a lui che smonti il mio teorema, allora: tanto è del campo e gli sarà facile, no?

In mancanza mi attengo a ciò che ho dimostrato.

Lui ha fatto la storia ed è grazie a persone come lui che l'umanità non ha ancora perso la dignità. La libertà di parola e di espressione sono i valore più grandi. Visto che fai tanto l'altezzoso provare a contattarlo su twitter e sentiamo se ti risponde.

Originariamente inviato da cdimauro

Mi quoto:

"ti ho portato una DIMOSTRAZIONE (Teorema, in realtà) che l'open di per sé NON garantisce alcunché."

Bravissimo.

[Sandro kensan]

Originariamente inviato da emiliano84

Interessante questo commento che ho trovato in giro

Non si tratta di un bug software ma di un bug hardware per cui è necessario modificare come funziona il kernel Linux cosa che se fatta in fretta può provocare immensi danni a tutto Internet.

[Sandro kensan]

Questa l'immagine dell'uso della CPU del server EPIC:

https://www.vg247.it/2018/01/06/epic...o-di-fortnite/

in cui si vede che dal momento della Patch per Intel del bug Meltdown i server hanno fatto un +30% di CPU utilization.

[sintopatataelettronica]

Originariamente inviato da emiliano84

Interessante questo commento che ho trovato in giro

A me l'articolo sembra il solito banale complottismo da 4 soldi.. non ha veramente senso.

Senza voler difendere Google (che mi sta sulle scatole veramente) mi domando come si fa a paragonare un difetto o bug trovato in qualche prodotto Microsoft a questa roba qui che è la falla più grossa che si sia mai vista e che affligge tutti i processori, tutti, da 10 anni a questa parte.

Logico che Google non ha diffuso i dati mesi fa: e meno male che hanno avuto l'accortezza di non farlo. Ma ti rendi conto il casino che poteva succedere e i danni che si potevano arrecare senza che nessuna contromisura fosse pronta prima della resa pubblica della cosa ?

Boh, qua sempre più gli interessi personali e il fanatismo prevalgono veramente sul buon senso e la ragionevolezza.

[rockroll]

Originariamente inviato da Yrbaf

Oltre a quanto già consigliato puoi consultare le dispense in Italiano del corso di Architetture II dell'Università di Torino.

Cerca Gunetti (che è un docente) + architettureII e troverai la pagina del sito con i pdf delle Slide che spiegano parecchia roba (in modo abbastanza comprensibile ma ovviamente un minimo di basi le richiedono) e con i rimandi a testi (almeno 3) da consultare per approfondimenti.

Ah non centrano nulla con questo bug, sono solo corsi su RISC, ILP (statica e dinamica), Branch Prediction Speculativa e non, MultiIssue, Cache, Architetture dei processori moderni con vari casi concreti esaminati, ...ecc


L'elaborazione out of order è sicuramente più onerosa ed infatti richiedendo anche più energia di solito i processori più parsimoniosi (vedi Atom, almeno quelli vecchi, ma anche molti Arm) sono InOrder.
Però i più veloci sono invece OoO.

Non è lavoro inutile perché tu fai del lavoro nella speranza che sia produttivo.
Le istruzioni speculative è vero che se il salto (o cambio di Program Counter) è predetto in modo errato sono lavoro inutile che potrebbe generare pure ulteriore lavoro per l'operazione di undo.
Ma è anche vero che tu speri di azzeccare spesso/con elevata incidenza (sempre è statisticamente impossibile) la predizione e quindi quando questo avviene ti sei solo portato avanti a fare lavoro che tanto dovevi comunque fare.

Ovvio che se i meccanismi di predizione sono poco efficienti allora alla fine vai più piano che senza questi sofismi.
E' lo stesso con la cache.
Un sistema dotato di cache ha tempi di accesso alla ram più lenti di un sistema senza cache (perché devi attraversare tutti i livelli di cache).
Però poi tu conti sul fatto che per pochi cache miss totale (con hit in ram) avrai molti cache hit conseguenti.
Certo che se fai solo cache miss allora un sistema senza cache andrebbe più veloce di te.

Ancora una volta ti ringrazio per la tua disponibilità e la chiarezza delle tue risposte, oltre che per le referenze informative che mi fornisci. Molti su questo forum dovrebbero prendere esempio da te.

I miei dubbi da "profano" erano appunto sul grado di probabilità di azzeccarla, necessariamente abbastanza elevato da compensare statisticamente le perdite dovute a tali processi.
Ma ripensandoci, anche se da un punto di vista puramente teorico non vedo algoritmi applicabili alla bisogna, da un punto di vista pratico ovvero di apprendimento di precedenti comportamenti la cosa ha il suo senso: se nella maggioranza più o meno elevata dei casi precedenti un ramo di codice si è comportato in un modo A anziche B andando a buon fine, posso assumere che anche in futuro posso puntare sulla predominanza di comportamenti A anzichè B per raggiungere lo scopo (in fin dei conti siamo in un'era di invadenza della famigerata A.I.).
PS: A ripensarci ulteriormente tutto il giro del fumo, cioè Branch (Speculative) Prediction, OutOFOrder Execution ... ed addirittura quello che chiamerei Parallele SubTasking, potrebbero essere molto facilitati se non proprio risolti da un'attenta programmazione (e non da un tanto al kilo come spesso avviene); il programmatore in fase di codifica sa assai spesso che probabilità ha un salto condizionato di essere eseguito, e basta che ponga la condizioe di salto relativa all'evento meno probabile (tipicamente, salto per condizione di errore, che si spera avvenga raramente); inoltre dovrebbe avere a disposizione un linguaggio che gli permetta di evidenziare le istruzioni ovvero le sequenze di esse parallelizzabili, attribuendo ciè un tag di (pari) priorità a ciascun ramo dove voglia sforzarsi di fare questa distinzione, cosa molto più facile per lui in sede di stesura codice che per la macchina che deve esaminare ciecamente tutte le dipendenze delle variabili. Ovviamente le cpu dovrebbero comportarsi in conseguenza di questi assunti.
Se poi nella babilonia dei linguaggi attuali si sono fatti i salti mortali per evitare l'uso dell'odiato GOTO, ovvero si è perso il controllo della traduzione dello stesso in codice oggetto, non so che farci, io per scrivere software di base ho quasi sempre lavorato in Assembler Main Frames

[Sandro kensan]

Originariamente inviato da rockroll

Ancora una volta ti ringrazio per la tua disponibilità e la chiarezza delle tue risposte, oltre che per le referenze informative che mi fornisci. Molti su questo forum dovrebbero prendere esempio da te.

I miei dubbi da "profano" erano appunto sul grado di probabilità di azzeccarla, necessariamente abbastanza elevato da compensare statisticamente le perdite dovute a tali precessi.
Ma ripensandoci, anche se da un punto di vista puramente teorico non vedo algoritmi applicabili alla bisogna, da un punto di vista pratico ovvero di apprendimento di precedenti comportamenti la cosa ha il suo senso: se nella maggioranza più o meno elevata dei casi precedenti un ramo di codice si è comportato in un modo A anziche B andando a buon fine, posso assumere che anche in futuro posso puntare sulla predominanza di comportamenti A anzichè B per raggiungere lo scopo (in fin dei conti siamo in un'era di invadenza della famigerata A.I.).

Io non so come facciano ma immagino che i cicli for e i while li becchino tutti e infatti tali cicli sono dei branch condizionati che saltano sempre ad eccezione di una volta quando il ciclare finisce. Cicli che ciclano una sola volta sono rari.

[Yrbaf]

Il metodo più semplice è la predizione statica.
Ad esempio la tecnica elementare del "salto indietro sempre fatto" garantisce di azzeccarre tutti i cicli di un loop tranne quello di uscita e quindi un basso tasso di errore (su loop con molti cicli).

Ovviamente una tecnica che va bene in certi casi può non andare bene o essere pure pessima in altri.
E quindi si rendono necessarie tecniche più complesse (che diventano predizione dinamica quando tengono conto della storia passata dei salti cambiando nel tempo la predizione) se si vuole coprire con buona % di successo le varie casistiche.

Nelle slide citate trovate vari esempi o citazioni (branch prediction buffer a 1 bit ed a 2 bit, predittori correlati, schema a torneo), poi nelle cpu attuali di oggi si usano cose ancora molto più complesse.
Alcune probabilmente pure coperte da segreto industriale.

[rockroll]

Originariamente inviato da Lampetto

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

Possibile, ma non è garantito

Come gravità si tratterebbe non di aggiornare un carburatore ma di sostituire un condotto pompa benzina non più adatto ai carburanti attuali, difettoso già da progetto, che ora rischia di riversare benzina sulla testata (calda) del motore.

Se ci fossero ancora decine di milioni di Topolino in circolazione, non so la FiCA, ma un'azienda seria lo farebbe.

[rockroll]

Originariamente inviato da sintopatataelettronica

A me l'articolo sembra il solito banale complottismo da 4 soldi.. non ha veramente senso.

Senza voler difendere Google (che mi sta sulle scatole veramente) mi domando come si fa a paragonare un difetto o bug trovato in qualche prodotto Microsoft a questa roba qui che è la falla più grossa che si sia mai vista e che affligge tutti i processori, tutti, da 10 anni a questa parte.

Logico che Google non ha diffuso i dati mesi fa: e meno male che hanno avuto l'accortezza di non farlo. Ma ti rendi conto il casino che poteva succedere e i danni che si potevano arrecare senza che nessuna contromisura fosse pronta prima della resa pubblica della cosa ?

Boh, qua sempre più gli interessi personali e il fanatismo prevalgono veramente sul buon senso e la ragionevolezza.

Affligge tutti i processori, tutti? E magari tutti in egual misura? Vero?

Comoda e molto onesta la nota divulgata da Intel, che tenta di equiparare in un'unico calderone chi ha le rogne chi ne è praticamente esente!