E' possibile sfruttare i bug della CPU per attaccare un sistema?

http://en.wikipedia.org/wiki/Microcode
Si, questo era chiaro, ma non è riferito alla classe x86

Stò guardando i manuali della documentazione tecnica dell' Intel IA32 e IA64..
ma questa possibilità di update del microcode non la vedo..

Guarda, copio direttamente un pezzo da http://en.wikipedia.org/wiki/Microcode :


D'altronde nel mio post precedente riportavo il link del del microcode per il p4.

si, ho capito pure questo, ma non mi indica in che modo queste patches entrano nella CPUx86
in pratica, c'è un istruzione o opcode che carica in memoria questo microcodice ?
se si, io nei documenti ufficiali di Intel non li ho trovati..
http://www.intel.com/design/core2du...uo+tab_techdocs

Però non vorrei che la questione si dovesse interpretare invece in modo diverso,
cioè che nel kernel del SO, mediante l'uprgade, sono state eliminate tutte le operazioni
che possono generare un microcodice potenzialmente difettoso...

mah..

noneee...si tratta di microcodice! Il sistema operativo, il kernel e tutto il resto non centrano niente!! Non ti so dire nella fattispecie che istruzioni vengono coinvolte nell'aggiornamento anche perché non ho un processore intel, in ogni caso non mi sorprende il fatto che non ci sia riferimento nella documentazione del processore..queste sono cose rivolte agli ingenieri che sviluppano microcode, non di certo ad un normale programmatore: il linguaggio utilizzato per le routine del microcode non è nemmeno documentato!!

grazie per l'aiuto quasi quasi ci provo....
ah...in linux non ho cartelle etc/firmware....ho lib/firmware...uso ubuntu...ma non credo c'entri la distribuzione

riporto un pezzettino del microcode che ho scaricato per la mia cpu (core 2 duo serie t7000)

Occorre una precisazione...

Un microprocessore moderno ha, per ragioni di complessità, una struttura modulare: è composto da una serie di blocchi funzionali, ognuno dei quali svolge una determinata funzione. Tali blocchi funzionali sono collegati tra loro da percorsi regolati da porte; potete immaginare queste porte come degli interruttori estremamente veloci, pilotati da segnali di abilitazione opportunamente calcolati in base all'istruzione da eseguire. Altri segnali sono destinati a modificare il comportamento dei singoli blocchi: per esempio per usare un sommatore con riporto (full adder) per eseguire una sottrazione bisogna settare il carry (riporto) ed invertire bit a bit il sottraendo (nella logica in complemento a due per invertire il segno di un numero si invertono tutti i suoi bit e si somma uno); in questo caso, quindi, bisogna predisporre due segnali che, rispettivamente, attivino il bit di carry e facciano passare il sottraendo attraverso un invertitore prima di farlo arrivare al sommatore.
Tutti questi segnali di controllo provengono da registri interni al processore (invisibili dall'esterno e da non confondersi con i registri comunemente conosciuti) che fungono da buffer per mantenerli attivi.
La domanda cruciale è ora: dove va il processore a prendere le sequenze di bit con le quali caricare questi suoi registri interni?
I processori con un organizzazione logica più semplice, come i risc ed i primi processori cisc, copiano queste sequenze direttamente dai bit delle istruzioni di programma da eseguire o riescono a ricavarle attraverso una semplice decodifica: questa è quella che viene definita logica cablata.
Aumentando il numero di istruzioni, duplicando alcuni dei suddetti blocchi funzionali per poter eseguire calcoli in parallelo (stiamo comunque parlando ancora delle varie parti di una sola cpu non di sistemi multicore, infatti il primo processore intel ad utilizzare due unità di esecuzione degli interi, sia pure non uguali, è stato il pentium) si va incontro ad un aumento di complessita tale da non rendere progettualmente conveniente la realizzazione della logica cablata atta ad eseguire il tutto: centinaia di istruzioni appartenenti a decine di classi diverse, operanti su tipi di dati di dimensione e codifica diverse (interi [8,16,32,64bit], mmx, sse [1,2,3,4], 3dnow, 3dnowext) che magari condividono gli stessi registri e vanno interpretati a seconda del contesto (fpu-mmx). In una situazione del genere tentare di realizzare una unità di esecuzione in logica cablata è inutile: non perché sia impossibile, visto che la progettazione si svolge con l'ausilio di programmi che all'aumentare della complessità non hanno particolari problemi se non quello di richiedere più tempo per sbrogliare il tutto, ma perché la rete di decodifica così ottenuta potrebbe arrivare ad essere più lenta delle unità di esecuzione che deve controllare; questo comporterebbe quindi un serio limite alla frequenza massima di lavoro del processore.
Ed è qui che entra in azione la cosiddetta logica microprogrammata.
Visto che si può affrontare tranquillamente la complessità dell'ottenere tutti i segnali necessari a pilotare l'attivazione e lo stato di tutte le unità di esecuzione e di tutti i percorsi che le uniscono, per ciascuna istruzione, tipo di dato, dimensione dello stesso (ci pensa l'apposito sw) perché non precalcolare il tutto ed inserirlo in una tabella? Geniale!
Ecco ottenuto il microcodice.
Vantaggi? Strutturando opportunamente la tabella la si può gestire come un vero e proprio programma: per ogni riga si può specificare operandi (segnali che attivano la provenienza ed il percorso dei dati sorgenti e destinazione), operatori (segnali che attivano le unità di esecuzione che useranno i dati per produrre il risultato di un'operazione), salti (la prossima istruzione da eseguire si trova alla riga x della tabella), ecc. Per ogni ciclo di clock basta ricopiare le varie parti della riga corrente nei registri che contengono i vari segnali di attivazione ed il gioco è fatto, in una frazione del tempo necessario alla corrispondente logica cablata per ottenere lo stesso rusultato. Il risultato di tutto ciò è che si riporta ad una dimensione gestibile umanamente l'enorme complessità di una moderna cpu con diverse unità di esecuzione che operano in parallelo, esecuzione fuori ordine delle istruzioni, ecc.
Può capitare il caso che non sia conveniente implementare il microcodice di una determinata istruzione: se l'istruzione da eseguire è semplice (vedi la somma di cui all'estratto da wikipedia) e nel formato dell'istruzione assembly sono già disponibili operandi sorgenti e destinazione, oltre ovviamente all'operazione da effettuare, può essere più economico in termini di tempo di esecuzione o numero di transistor impiegati realizzarne la decodifica in logica cablata. Chi di voi mastica un pò di assembly x86 ricorderà che spesso l'insieme di istruzioni inc, jnz era più veloce della singola istruzione loop: ovviamente ciò era dovuto al fatto che le due istruzioni più semplici erano realizzate in logica cablata mentre la loop utilizzava la tabella di microprogramma memorizzata in una rom (e quindi molto più lenta).
Immagino che il sistema attuale non sia troppo dissimile e che ci siano istruzioni semplici realizzate in logica cablata ed istruzioni complesse microprogrammate. Suppongo altresi che ci sia ancora una rom contenente il microcodice che viene 'ricopiato' al reset della cpu in una memoria statica e che pertanto sia aggiornabile dal bios o da un qualsivoglia processo eseguito in ring0 anche durante il funzionamento della cpu.
Tornando in topic realizzare un attacco richiederebbe almeno di conoscere l'esatta mappatura dei vari segnali all'interno della tabella di microprogramma e di aver individuato un intoppo tra una sequenza e l'altra sfruttabile per portare la cpu in una condizione tale da sottometterla ai propri intenti.

many thanks!

si..il percorso cambia da una distribuzione all'altra..comunque probabilmente ti ho detto una cavolata io, pardon



probabilmente volevi dire dec, jnz..

Oops..

Esattamente

Quante sciocchezze dici ?
so benissimo cos'è il microcodice delle cpu CISC
probabilmente Intel si riserva la documentazione tecnica, e chissà,
magari modificando il microcode riescono pure ad attivare le TXT e il TPA..

Probabilmente nel Bios c'è un istruzione non documentata che permette di caricare
in opcode memory i famosi 2048 byte dell' update.
Mi sembra però che questo update è di tipo "volatile" cioè deve venir ricaricato ad ogni
accensione della CPU...