Link alla notizia: http://www.hwupgrade.it/news/sicurezza/e-possibile-sfruttare-i-bug-della-cpu-per-attaccare-un-sistema_26000.html

Un ricercatore ha affermato di poter sfruttare alcuni bug presenti nelle CPU Intel per sferrare attacchi in locale o da remoto. Ad ottobre la dimostrazione pratica

Click sul link per visualizzare la notizia.

:eek:
Addirittura?

Non credevo fosse possibile..:eek:

Questo è grave.

Mi domando se l'antivirus sia in grado di intercettare tali malware.

Anche perchè non sono convinto che Intel e AMD saranno così oneste da riconscere tutti i bachi delle loro CPU in modo da permettere alle aziende di sicurezza di preparare contromosse.

E soprattutto sai che dramma aggiornare i bios di 250 pc, in azienda. Credo dovrebbe cambiare la filosofia di aggiornamento permettendo l'aggiornamento del firmware da remoto.

Veramente sarebbe quello il problema il dare la possibilità di modificare il bios da remoto. Basterebbe che non fossero modificabili se non durante le prime fasi di avvio del sistema o solo tramite riconoscimento da bioss con password.

attenzione, questo è un attacco hacker, non è uno scherzo, se premi sul tasto "sono gay" il tuo pc è salvo, se premi su "sono etero" il tuo pc si brucierà!
uno logicamente si fa una lollata, tanto è uno scherzo, e poi preme su "sono etero"... :D
il pc si spegne, esce fumo e si sente puzza di bruciato...
provi a riaccenderlo e niente... :mc:
allora ti accorgi che non era uno scherzo ma un vero attacco che ha sfruttato la povera architettura buggata del tuo procione core 2... :confused: :mbe: :cry:

ps: ma di amd non si sa niente? possibile che solo intel abbia questi bug sfruttabili da malintenzionati? :rolleyes:

in pratica una attacco a livello 1, invisibile a qualsiasi software, sistema operativo compreso. Sembra interessante :D

dipende dal bug.. :D
qualsiasi istruzione che provoca l'azzeramento o il controllo dei flag di segmento protetto,
può dare il controllo totale al programma.. :rolleyes:

Oramai anche le CPU dovrebbero avere una flash x l'upgrade del codice.. :rolleyes:

che qualcuno si riserva una porta di accesso remoto ? magari anche non documentata ? :asd:

dipende dal bug.. :D
qualsiasi istruzione che provoca l'azzeramento o il controllo dei flag di segmento protetto,
può dare il controllo totale al programma.. :rolleyes:

Oramai anche le CPU dovrebbero avere una flash x l'upgrade del codice.. :rolleyes:

che qualcuno si riserva una porta di accesso remoto ? magari anche non documentata ? :asd:

qualcuno ha detto grande fratello? :asd: :look:

Anche gli amd hanno qualche baco, ma meno. Cmq finchè qualcuno non viola un pc davanti a tutti in qualche megaconferenza, nessuno si muove.

infatti deve ancora farlo

che un attacco di questo tipo sia possibile via tcp o javascript mi puzza, in quanto le implementazioni del protocollo e del linguaggio di scripting sono diverse non solo da sistema operativo a sistema operativo ma addirittura, nel secondo caso, da browser a browser... pertanto dubito che un attacco su componenti ad alto livello permetta di sfruttare bachi che faresti fatica a sfruttare da un'applicazione vera e propria eseguita in locale (tant'è che non mi risulta sia una tecnica usata da nessun malware)...

al di là di quello, oltre a incappare nel baco lo devi poi sfruttare per farci qualcosa... insomma, finchè non c'è qualche info in più non ci credo

l'ennesima dimostrazione che tutto ciò che è programmato con del codice informatico è bacato

Secondo me, non sono dei bug (o, quantomeno, non tutti). Del resto, Intel è l'abbreviazione di Intelligence... :D

Anch'io a fine ottobre ci riusciro'!
Nel frattempo gradirei molto che tutti i siti che parlano di software-hardware-security pubblichino degli articoli su di me scrivendo che sono un esperto ricercatore indipendente nel campo della sicurezza :fagiano:

mi state spaventando :(:(:(:(:(:(:(:(

dipende se è vero o meno...
però se fosse vero scoppia una gran bella guerra!

Io navigo in internet con un Pentium III-M, mi devo preoccupare? :rolleyes: Lo chiedo perchè secondo me il mio processore ha più di un milione di bug ( :D ) e non so come potrebbero sfruttarli per entrare nel mio pc...............

Ciao, Whity :)

P.S. Per fortuna come al solito le piattaforme attaccate sono le più usate, quindi non penseranno mai al mio Pentium III-M :D

in pratica una attacco a livello 1, invisibile a qualsiasi software, sistema operativo compreso. Sembra interessante :D
mah, a me risulta che il kernel dei sistemi operativi sia eseguito sul Ring0. Mi sembra quindi veramente poco probabile che un sovraccarico dello stack TCP/IP o un codice interpretato come il JavaScript possa andare ad accedere in maniera diretta ai registri della CPU (a meno che l'attacco via rete/script sia solo il modo per eseguire poi sul sistema un eseguibile opportunamente creato in assembly)

:O ... oh mai god.

il problema non è Ring 0 o che altro, qui si parla di bug a livello di microcodice e non è nemmeno vero che tutti si possono risolvere aggiornando il BIOS, alcuni si risolvono solo cambiando il processore

questo tipo di attacchi non ha molto in comune con i normali attacchi a cui siamo abituati

immaginate che un buffer overflow sia presente a livello di microcodice, vuol dire che posso inviare tramite un'apposita istruzione dell'ISA ( non importa se il programma è scritto in C, Javascript o che altro ) una stringa più lunga di quanto il microcodice si aspetta, a questo punto possono manipolare i flag, i descrittori e qualsiasi altra cosa senza che i meccanismi di protezione entrino in funzione

posso in pratica bypassare BIOS, sistema operativo e quant'altro, quindi non c'è nessuna difesa da parte del sistema operativo nè tantomeno da eventuali software antivirali

Scusate la mia ignoranza ma si parla di bios. Sono abituato a considerare il bios strettamente collegato alla scheda madre e non al processore. Aggiornare il bios non dovrebbe risolvere la questione motherboard e non il processore? :confused:

A Zyklon B
Scusa non sono un bacchettone però avere un nickname del genere è veramente di cattivo gusto, oltre che offensivo...

più di un buffer overflow sicuramente non possono fare,piuttosto ho sempre avuto paura di qualche software che ti potrebbe piallare la bios,questo lo vedo fattibile,anzi è sicuramente fattibile,rimane il fatto che noi utenti privati in caso di buffer overflow riavviamo il pc e tutto torna come prima,per quanto riguarda il piallamento della bios si dovrebbe recuperare con il cd di ripristino!

qui si parla di bug a livello di microcodice e non è nemmeno vero che tutti si possono risolvere aggiornando il BIOS, alcuni si risolvono solo cambiando il processore


È proprio vero. Alcuni bug possono essere intrinsechi al procio (diciamo strutturalmente se mi passate il termine). Su una vecchia rivista 95 forse 96 avevo letto di un bug in un procio intrinseco all'architettura che faceva sballare completamente i calcoli in virgola mobile. Unica soluzione: fare un nuovo procio che comunque tardò e sostituire il vecchio modello.

Che sia la volta che rilascino aggiornamenti gratuiti per proci come gli antivirus?
Oddio comincerebbero ad arrivare una mandria di procioni ogni settimana :eekk:

Ovviamente si scherza. La cosa se è vera è piuttosto seria. Se è possibile sfruttarli anche tramite il protocollo TCP/Ip allora sarà proprio vero che l'unico PC sicuro è un PC spento. A meno che non si inventino un antivirus o firewall tra CPU e Northbridge. Ma anche se fosse come filtrare i dati? mah chissà magari è solo una bufala...e non è possibile una cosa del genere oppure non cosi grave. Magari solo qualche instabilità di sistema che si risolve riavviando il PC

per quanto riguarda il piallamento della bios si dovrebbe recuperare con il cd di ripristino!
Be credo che con opportuni accorgimenti nel bios e l'uso di password come protezione si possa evitare l'installazione di qualsiasi cosa nella rom. Oltretutto flashare la rom del bios non credo sia cosi semplice


PS che non sia una strategia bufala per rispolverare l'utilità del Trusted Computing ??

immaginate che un buffer overflow sia presente a livello di microcodice, vuol dire che posso inviare tramite un'apposita istruzione dell'ISA ( non importa se il programma è scritto in C, Javascript o che altro ) una stringa più lunga di quanto il microcodice si aspetta, a questo punto possono manipolare i flag, i descrittori e qualsiasi altra cosa senza che i meccanismi di protezione entrino in funzione

posso in pratica bypassare BIOS, sistema operativo e quant'altro, quindi non c'è nessuna difesa da parte del sistema operativo nè tantomeno da eventuali software antivirali

fetemi capire (se qualcuno ha metafore adatte si faccia avanti):

in pratica è il processore ad essere bacato.. tutto gira sul processore, allora anche 'ste istruzioni cattive dovrebbero girarci, no? ma comunque prima di entrare nel pc non dovrebbero essere "vagliate" dall' antivirus? No comprendo.. che differenza c'è con un qualunque virus?

non sono assolutamente competente, pardon..

anche l'antivirus gira sulla cpu, quindi penso che anche mentre controlla questi file possa essere intaccato il procio.

immaginate che un buffer overflow sia presente a livello di microcodice, vuol dire che posso inviare tramite un'apposita istruzione dell'ISA ( non importa se il programma è scritto in C, Javascript o che altro ) una stringa più lunga di quanto il microcodice si aspetta, a questo punto possono manipolare i flag, i descrittori e qualsiasi altra cosa senza che i meccanismi di protezione entrino in funzione

il codice Javascript e codice interpretato ed ogni versione di browser per ogni sistema operativo diverso avra' un diverso interprete, verosimilmente con comportamenti differenti. Mi risulta quindi difficile pensare che un Javascript possa da solo far eseguire ad un qualsiasi interprete JS un'istruzione che porti ad uno degli "errata" delle CPU.

il problema non è Ring 0 o che altro, qui si parla di bug a livello di microcodice e non è nemmeno vero che tutti si possono risolvere aggiornando il BIOS, alcuni si risolvono solo cambiando il processore

questo tipo di attacchi non ha molto in comune con i normali attacchi a cui siamo abituati

Ammesso che anche il Javascript abbia avuto successo e sia riuscito ad innescare una condizione anomala della CPU, questa poi portera' ad un valore errato in uno o piu' registri e/o alla scrittura di valori errati in memoria.
Per quanto ne so almeno che un programma non sia eseguito nel Ring 0 non puo' accedere ai registri o a una specifica locazione di memoria; quindi non potrebbe poi eseguire altro codice per proseguire la violazione del sistema.


Resteremo a vedere ulteriori sviluppi da questa conferenza..

È proprio vero. Alcuni bug possono essere intrinsechi al procio (diciamo strutturalmente se mi passate il termine). Su una vecchia rivista 95 forse 96 avevo letto di un bug in un procio intrinseco all'architettura che faceva sballare completamente i calcoli in virgola mobile. Unica soluzione: fare un nuovo procio che comunque tardò e sostituire il vecchio modello.

Che sia la volta che rilascino aggiornamenti gratuiti per proci come gli antivirus?
Oddio comincerebbero ad arrivare una mandria di procioni ogni settimana :eekk:

Ovviamente si scherza. La cosa se è vera è piuttosto seria. Se è possibile sfruttarli anche tramite il protocollo TCP/Ip allora sarà proprio vero che l'unico PC sicuro è un PC spento. A meno che non si inventino un antivirus o firewall tra CPU e Northbridge. Ma anche se fosse come filtrare i dati? mah chissà magari è solo una bufala...e non è possibile una cosa del genere oppure non cosi grave. Magari solo qualche instabilità di sistema che si risolve riavviando il PC


Be credo che con opportuni accorgimenti nel bios e l'uso di password come protezione si possa evitare l'installazione di qualsiasi cosa nella rom. Oltretutto flashare la rom del bios non credo sia cosi semplice


PS che non sia una strategia bufala per rispolverare l'utilità del Trusted Computing ??

quello al quale ti riferisci e' stato forse il primo caso di bug a livello hardware dichiarato al di fuori degli "addetti ai lavori". Affliggeva le prime versioni dei Pentium da 66-100 MHz (vedi Qui (http://en.wikipedia.org/wiki/Pentium#P5.2C_P54C.2C_P54CS))

Gran parte di queste errata sono note ai produttori hardware da tempo e spesso sono corrette con degli aggiornamenti di microcodice rilasciati con i BIOS e diventano attivi al boot.
Inoltre i compilatori di software sono sviluppati in modo che il codice eseguibile che generano non vada mai portare il processore in una condizione indicata negli errata.


A mio avviso stanno alzando un polverone per un problema a tutti gli effetti marginale.
Questo portera' gli utenti alla psicosi da CPU vulnerabile :D :D

Da locale o da remoto... da locale ancora ancora... ma da remoto!?? dove sono i linuxari che tutti i giorni modificano il loro stack tcp/ip e sanno come è fatto?? almeno ci danno chiarimenti...

Comunque boh! basta mettere un firewall e bloccare gli attacchi da rete. Easy no? a meno che anche i firewall siano buggati...

boh.. può essere tutto ma a me sembra terrorismo gratuito.. prendere il controllo di una macchina con un attacco di livello 1?! ma come fai? cambiando i registri?! per me è una bufala!

finche' non vedo qsa di funzionante non mi preoccupo. non e' nemmeno un proof of concept eh

cmq intel ha gia' vpro, amd facilmente seguira' a ruota, cominceremo ad aggiornare i bios come gli antivirus o ad avere firewall sempre + potenti o antivirus/antimalware direttamente sui router. ce ne sono pochi di pc seri connessi DIRETTAMENTE a internet

Cercando un pò per Linux esiste: http://urbanmyth.org/microcode/
Probabilmente esistono progetti simili anche per altri sistemi

EDIT: altro link interessante: http://www.uxc.it/?q=progetto_studente/view/475

[QUOTE=Octane;23356542]quello al quale ti riferisci e' stato forse il primo caso di bug a livello hardware dichiarato al di fuori degli "addetti ai lavori". Affliggeva le prime versioni dei Pentium da 66-100 MHz (vedi Qui (http://en.wikipedia.org/wiki/Pentium#P5.2C_P54C.2C_P54CS))

Si probabilmente è quello. In quegli anni andavo ancora l'asilo :D l'ho letto casualmente eliminando 1 pò di vecchie riviste di mio fratello. Quelle si che erano riviste di informatica serie: antiniubbo ma adatte all'appassionato :sofico:

e dopo aver fatto 2 @@ infinite col bug del phenom, ora pure gli altri si accorgono che sono TUTTE le cpu ad essere buggate... :rolleyes:

vabbé...adesso servirà pure un antivirus sulla scheda madre...

e dopo aver fatto 2 @@ infinite col bug del phenom, ora pure gli altri si accorgono che sono TUTTE le cpu ad essere buggate... :rolleyes:

vabbé...adesso servirà pure un antivirus sulla scheda madre...

Ci sono bug e bug... in particolar modo quello di AMD non ha aiutato al lancio del prodotto (del resto che marketing potevi fare se i tuoi processori a causa di un bug erano più lenti), erano coscienti del bug prestazionale che aveva ma hanno cmq venduto quei processori.

In questo caso la faccenda è diversa, perché all'utente comune non è tangibile questo bug.

Cmq nessuna paura, basta un aggiornamento del microcode ;)

Anche gli amd hanno qualche baco, ma meno. Cmq finchè qualcuno non viola un pc davanti a tutti in qualche megaconferenza, nessuno si muove.

Secondo quale documento ufficiale riesci a dire che ne ha meno?

Scusate tanto:

solo a me sà tanto di BUFALA messa in giro da qualche competitor di Intel?

Comunque tutti i sistemi operativi al boot applicano delle patch al microcode per i problemi conosciuti più gravi.
Se il sistema è patchato è impossibile riuscire a eseguire codice malevolo.
Probabilmente verrà sfruttato qualche bug non ancora corretto perchè non segnalato o ritenuto non pericoloso.

Non credo proprio sia una bufala.. e vedo neanche un motivo valido perchè questo lo sia.

Come al solito HWUpgrade negli ultimi tempi sta arrivando in ridardo sulle notizie anche di qualche giorno. Su Tom's se ne parlava ieri. Su i siti internazionali qualche giorno fa; la notizia non è stata riportata neanche completamente.

Visto che verrà fatta una dimostrazione pubblica in un evento, non può essere una bufula, perchè è una dimostrazione in programma già da un pò... non vi faranno vedere un video, ma procederanno sotto gli occhi dei giornalisti.

Per ora si parla solo di Intel perchè verranno sfruttati alcuni bug dell'architettura Core, magari dopo uno studio di qualche settimane uscirà che questo baco è utilizzabile anche sulle architetture AMD.

Dalle voci che trapelano verranno sfruttati bug via javascript e protocollo TCP\IP. In ogni caso al 70% delle possibilità sarà possibile arginare questi bug con l'aggiornamento del sistema operativo.

E la notizia più clamorosa, è che al termine della presentazione Kris ha già dichiarato che renderà pubbliche a tutti gli utenti quali siano le falle e i sistemi per sfruttarle. Questa è la notizia che fa più paura e viene messa in risalto da altre testate. Ma magari è solo una minaccia rivolta a Intel per farsi sborsare qualche milioncino di dollari per il suo silenzio...

ciao.

Ma magari è solo una minaccia rivolta a Intel per farsi sborsare qualche milioncino di dollari per il suo silenzio...

ciao.

Assoldare un killer costa meno ed è piu' facille. Soprattutto in ambito industriale è una metodologia molto utilizzata. :asd:

Provo a dire la mia anche se non sono un esperto.

Primo, ricordiamoci che tutto (ma proprio tutto tutto tutto) quello che gira su un computer sono SOLO zeri e uni. 000010101010101110101011111010101

La corretta interpretazione di dove finisce una "cosa" e inizia un'altra "cosa" è anche legata a questi zeri&uni ed a precisissime regole di quanto sono lunghe le sequenze. Un errore nell'interpretazione di questi "paletti" può trasformare un pezzo del desktop in un mp3, un suono in un numero in una cella di excel, una jpg in un indirizzo web. Un "dato" in un "comando".
Ora mi pare che questo si possa ottenere in due modi:
*coi buffer overflow (si va a scrivere un dato dove dovrebbe starci una istruzione)
*sbagliando un "calcolo"
Questo secondo mi sembra il punto toccato dal problema.
Le CPU hanno montagne di bug da sempre e il bios è fatto x "correggere al volo" la roba che la cpu macina x evitare che si verifichi la condizione di errore. Basta prendere i datasheet della versione del processore x trovarne a valanghe.
ora, se si passa un dato sbagliato e il bios non lo corregge, la cpu fa delle operazioni sbagliate e magari scambia un indirizzo di memoria dove c'è l'mp3 da suonare per una istruzione che dice "sposta il file pippo nel cestino" o peggio "scrivi 00000000111111" nel settore di avvio dell'HD (cosa che mi sembra anche + facile xchè indipendente dal SO) xchè venga fuori un casino.
Se poi dice "scrivi <codice maligno> nel settore di avvio", beh, la cosa "gira" sotto tutto quindi è ben difficile accorgersene.

Concordo che mi pare roba difficilmente sfruttabile con JS: semmai ci vorrà qualcosa scritto in assembler ed il JS è solo il cavallo di troia x piazzare il codice sul disco e lanciarlo.

FF + Noscript e anche Kris Kaspersky è sistemato! :O

FF + Noscript e anche Kris Kaspersky è sistemato! :O

ho sentito che Firefox e Noscript proteggono anche dai meteoriti e dalle zanzare..:asd:

Io navigo in internet con un Pentium III-M, mi devo preoccupare? :rolleyes: Lo chiedo perchè secondo me il mio processore ha più di un milione di bug ( :D ) e non so come potrebbero sfruttarli per entrare nel mio pc...............

Ciao, Whity :)

P.S. Per fortuna come al solito le piattaforme attaccate sono le più usate, quindi non penseranno mai al mio Pentium III-M :D

..........

grazie per avermi completamente ignorato........ :rolleyes:

Io navigo in internet con un Pentium III-M, mi devo preoccupare? :rolleyes: Lo chiedo perchè secondo me il mio processore ha più di un milione di bug ( :D ) e non so come potrebbero sfruttarli per entrare nel mio pc...............

Ciao, Whity :)

P.S. Per fortuna come al solito le piattaforme attaccate sono le più usate, quindi non penseranno mai al mio Pentium III-M :D


Io uso ancora il PIII 600 per navigare.... mi devo preoccupare anch'io :stordita:

..........

grazie per avermi completamente ignorato........ :rolleyes:

Con un Pentium III piu' che degli attacchi ti devi preoccupare di qualche museo che ti viene a rapinare.

Il tizio esiste veramente, ha scritto anche dei libri, ora non so se sia proprio lui oppure qualcuno che vuol far partire una burla. Poi la cosa mi sa un po di pu##anata.

beh io starei tranquillo, per il semplice fatto che più ci si avvicina all'hardware più le cose diventano gestibili da pochi, perchè assai complesse.

Basti pensare che ci sono milioni di persone che fanno virus software, e una sola che ne ha fatto uno hardware.

Questo non vuol dire che i big debbano sottovalutare il problema, quel che è sicuro è la difficile sfruttabilità di questi bug in situazioni eterogenee.

Invocare un bug hardware, è solitamente abbastanza complicato, e l'effetto prodotto dipende da altre variabili. Comunque, complimenti a questo tizio per la ricerca condotta, indipendentemente da quali risultati ha effettivamente ottenuto

argh...è serio il fatto...ma una volta che si spegne il pc e si riaccende per esempio il codice malevolo sparisce giusto!?o si memorizza nell'hard disk!?

Salve Ragazzacci :cool: ,

Certo che e' comune la senzazione di essere smpre sotto il mirino del craker cattivo di turno.... :muro: , ma a suo tempo naqqquettero apposta le VM :cool: giusto?!
Quindi Io vi dico ecco il grande bluf :Prrr: che ci hanno propinato a tutti noi Pc sempre piu' performanti tanto da supportare anche molte VM cosi' da essere sicuri da eventuali Virus e contemporanemente si poteva navigare magari senza Anti Virus sul Web tanto eventualmente veniva infettata la VM.
Sono come vedete tutte bufale!!! Abbiamo Missili Patriot ma non li comandiamo noi, ma un certo "BANO" detto "TALE" :Prrr: :oink: :p :muro: che da remoto ti ferra la terza guerra mondiale a tutti i Pc al mondo e fa pure centro!!! :muro: :muro: :muro: :cry: :cry: :cry: .
Beh speriamo che :help: a tutti con quello che e' possibile fare, diversamente vedremo a breve il nosto :ciapet: preso a dovere, preparatevi o Voi possessori di codeste CPUs :stordita: :cry:

..........
grazie per avermi completamente ignorato........ :rolleyes:

Usando vecchi pc, il problema maggiore è farci girare sw di protezione aggiornato, non certo i bachi processore. Anzi stai pure molto + al sicuro xchè chi vuoi che "investa" sui bug di processori che spariranno nel giro di poco tempo?

argh...è serio il fatto...ma una volta che si spegne il pc e si riaccende per esempio il codice malevolo sparisce giusto!?o si memorizza nell'hard disk!?
non tutti i bug delle CPU portano necessariamente al riavvio della macchina.
Gran parte portano ad errori nei valori dei registri o a errate scritture in memoria.
Restando sempre nell'ipotetico, se il codice malevolo sfrutta uno di questi bug e riesce ad accedere a far eseguire poi altre istruzioni (magari con privilegi piu' elevati o + verosimilmente a livello piu' basso) allora puo' andare a far scritture su disco, eprom e quant'altro.

Il punto e' sempre lo stesso: Kaperski deve riuscire ad innescare il bug e riuscire a controllarlo ai suoi fini.

ma un bel firewall non riconoscerebbe i pacchetti inviati per controllare in remoto il pc?

dipende dal bug.. :D
qualsiasi istruzione che provoca l'azzeramento o il controllo dei flag di segmento protetto,
può dare il controllo totale al programma.. :rolleyes:

Oramai anche le CPU dovrebbero avere una flash x l'upgrade del codice.. :rolleyes:

che qualcuno si riserva una porta di accesso remoto ? magari anche non documentata ? :asd:

Ehm peccato che nel caso dei microprocessori il "codice" e' fatto di transistors xD

difficile "flasharli"

Ehm peccato che nel caso dei microprocessori il "codice" e' fatto di transistors xD

difficile "flasharli"

non direi..il microcodice (http://en.wikipedia.org/wiki/Microcode) serve infatti allo scopo di ri-programmare alcune funzioni della CPU al boot del sistema. Viene caricato con il BIOS e spesso ne viene fatto un ulteriore override da parte del sistema operativo.

Non ho trovato nessuna reazione online da parte delle società di sicurezza, solo un commento da parte di Prevx.


Recently, some articles have been published after Hack in the Box Security Conference 2008 presentations have been revealed. One of the most interesting topics that will be shown at the conference will be the presentation given by Kris Kaspersky.

Kaspersky (who has nothing to do with Kaspersky Labs) will be presenting his research and proof of concepts on how to exploit Intel CPU bugs to make an attack regardless of the operating system or if applications installed are all updated or not...


http://www.prevx.com/blog/97/CPU-Bug-Attacks-Are-they-really-necessary.html

Se è possibile condurre un "attacco" usando javascript o pacchetti forgiati, ed indipendentemente dall'OS utilizzato, mi sembra evidente che il problema sia legato agli algoritmi di esecuzione "out of order" quando eseguiti su un dual core.
Tuttavia c'è una grande differenza tra il dimostrare una vulnerabilità e utilizzarla per effettuare un attacco.
Vedremo.

Antonio

non ci vedo nulla di clamoroso, se esistono dei bachi legati all'architettura, nel fatto che sia possibile sfruttarli in locale...
ed ottenere per es. un classico buffer overflow...

Che gran bella fesseria che ha scritto stò signore, sono proprio impaziente di vederlo all'opera.

I bug dei processori con Java ed i pacchetti TCP centrano proprio poco !!!

Se io eseguo del codice interpretato il linguaggio macchina è "generato" dell'interprete. Se questo interprete è a conoscenza dei bug dei processori non dovrebbe generare MAI codice che li mandi in stallo o che ricada in uno dei bug noti.
Discorso analogo per i pacchetti TCP.....è lo strato kernel che li "trasforma" ed esegue il linguaggio macchina.
Aggiungo anche che dubito che la JVM e lo strato kernel TCP sia scritti direttamente in assembler ma saranno scritti in C/C++; quindi c'è un altro livello di sicurezza dato dal compilatore che non dovrebbe generare codice che possa incorrere nei bug della cpu.

Ciao
/Matteo

Che gran bella fesseria che ha scritto stò signore, sono proprio impaziente di vederlo all'opera.

I bug dei processori con Java ed i pacchetti TCP centrano proprio poco !!!

Se io eseguo del codice interpretato il linguaggio macchina è "generato" dell'interprete. Se questo interprete è a conoscenza dei bug dei processori non dovrebbe generare MAI codice che li mandi in stallo o che ricada in uno dei bug noti.
e chi l'ha detto che lo sia? :)

Che gran bella fesseria che ha scritto stò signore, sono proprio impaziente di vederlo all'opera.

I bug dei processori con Java ed i pacchetti TCP centrano proprio poco !!!

Se io eseguo del codice interpretato il linguaggio macchina è "generato" dell'interprete. Se questo interprete è a conoscenza dei bug dei processori non dovrebbe generare MAI codice che li mandi in stallo o che ricada in uno dei bug noti.
Discorso analogo per i pacchetti TCP.....è lo strato kernel che li "trasforma" ed esegue il linguaggio macchina.
Aggiungo anche che dubito che la JVM e lo strato kernel TCP sia scritti direttamente in assembler ma saranno scritti in C/C++; quindi c'è un altro livello di sicurezza dato dal compilatore che non dovrebbe generare codice che possa incorrere nei bug della cpu.

Ciao
/Matteo

Caro Matteo, prima di fare lo sbruffone e contestare qualcuno che per raggiungere intellettualmente dovresti vivere ancora 6 o 7 vite (ma io sono sicuro che nemmeno ti bastano), per lo meno accertati delle differenze che ci sono fra Java e JavaScript. Perchè lui parla di JavaScript, non Java, che sono due cose totalmente diverse. Piu' modestia (o maggiore attenzione e comprensione nella lettura delle news).
Tra l'altro il tuo discorso fa ancora acqua, perchè se alcuni bug non sono stati documentati o lo sono stati da poco, stai tranquillo che nessun compilatore è in grado di evitarli, per lo meno nell'immediato.

Che gran bella fesseria che ha scritto stò signore, sono proprio impaziente di vederlo all'opera.

I bug dei processori con Java ed i pacchetti TCP centrano proprio poco !!!

Se io eseguo del codice interpretato il linguaggio macchina è "generato" dell'interprete. Se questo interprete è a conoscenza dei bug dei processori non dovrebbe generare MAI codice che li mandi in stallo o che ricada in uno dei bug noti.
Discorso analogo per i pacchetti TCP.....è lo strato kernel che li "trasforma" ed esegue il linguaggio macchina.
Aggiungo anche che dubito che la JVM e lo strato kernel TCP sia scritti direttamente in assembler ma saranno scritti in C/C++; quindi c'è un altro livello di sicurezza dato dal compilatore che non dovrebbe generare codice che possa incorrere nei bug della cpu.

Ciao
/Matteo

Questo signore ha scritto svariati libri ed è un rinomato esperto del settore. Tu chi sei? Per permetterti di essere così sbruffone dovresti almeno avere un'esperienza nel settore pari o superiori a costui.

Non commento il resto perché hai sparato una serie di balle spaziali alle quali, giustamente, solo chi non ha facoltà di comprendere appieno la serietà del problema può credere.

non ci vedo nulla di clamoroso, se esistono dei bachi legati all'architettura, nel fatto che sia possibile sfruttarli in locale...
ed ottenere per es. un classico buffer overflow...

la cosa che mi rende dubbioso e' che ha dichiarato che e' possibile violare la macchina con lo stesso attacco indipendentemente dal sistema operativo (che quindi hanno gestioni dei processi e della memoria completamente differenti).
Un buffer overflow quindi non avrebbe necessariamente lo stesso risultato su due OS diversi.

Nesssuno, è solo una mia supposizione.
Infatti aspetto con impazienza il mese di ottobre per scoprire se riesce a fare quello che ha detto.

Ripeto per arrivare all'assembler (che è l'unico linguaggio che probabilmente può scatenare i bug delle cpu) partendo dai javascript c'è un "mondo" di software in mezzo.....dubito che siano bacati la jvm, i driver tcp, il kernel ed i compilatori con cui questi software sono stati fatti.

Mandare in overflow una applicazione è una cosa ben diversa rispetto a sfruttare bug delle cpu e sicuramente è fattibile anche con javascript...:D

Questo signore ha scritto svariati libri ed è un rinomato esperto del settore. Tu chi sei? Per permetterti di essere così sbruffone dovresti almeno avere un'esperienza nel settore pari o superiori a costui.

Non commento il resto perché hai sparato una serie di balle spaziali alle quali, giustamente, solo chi non ha facoltà di comprendere appieno la serietà del problema può credere.

Prima di tutto grazie per lo sbruffone, però cerchiamo di capirci.
Non stò denigrando nessuno e non stò dicendo che non sia "bucabile" nessuno dei sistemi citati. Stò solo cercando di dire che per arrivare ed eseguire il microcodice bacato su una cpu partendo da uno script java c'è una pila di software molto lunga.
O tutto il software che c'è sopra al microcode bacato delle cpu è scritto IGNORANDO questi bachi oppure la vedo molto ma molto difficile.

Mi sembra che siamo in un paese libero e ognuno possa esprimere le proprie opinioni; non mi sembra di aver insultato nessuno.

:D

Prima di tutto grazie per lo sbruffone, però cerchiamo di capirci.
Non stò denigrando nessuno e non stò dicendo che non sia "bucabile" nessuno dei sistemi citati. Stò solo cercando di dire che per arrivare ed eseguire il microcodice bacato su una cpu partendo da uno script java c'è una pila di software molto lunga.
O tutto il software che c'è sopra al microcode bacato delle cpu è scritto IGNORANDO questi bachi oppure la vedo molto ma molto difficile.

Mi sembra che siamo in un paese libero e ognuno possa esprimere le proprie opinioni; non mi sembra di aver insultato nessuno.

:D

Aridaje co sto Java... Hai semplicemente detto che il tizio ha detto un mucchio di sciocchezze. I bug in questione presi dal ricercatore sono appunto bug sfruttabili a prescindere dagli strati software coinvolti.

Aridaje co sto Java... Hai semplicemente detto che il tizio ha detto un mucchio di sciocchezze. I bug in questione presi dal ricercatore sono appunto bug sfruttabili a prescindere dagli strati software coinvolti.
Prima cosa leggete l'intervista della persona quì (http://blogs.zdnet.com/security/?p=1492)

riporto una parte di ciò che ha detto :
"Some of the bugs that will be shown are exploitable via common instruction sequences and by knowing the mechanics behind certain JIT Java-compilers, attackers can force the compiler to do what they want (for example: short nested loops lead to system crashes on many CPUs)."

capito?!....Sfruttando alcuni compilatori java posso forzarli a generare sequenze di codice che mandano in crash il sistema....
Che dietro alla parola "certain" si nasconda buchi del software mi piacerebbe saperlo, piuttosto che sparare il messaggio marketing che preoccupa tutti i possessori di pc intel-based.

sbagliato post

attenzione, questo è un attacco hacker, non è uno scherzo, se premi sul tasto "sono gay" il tuo pc è salvo, se premi su "sono etero" il tuo pc si brucierà!
uno logicamente si fa una lollata, tanto è uno scherzo, e poi preme su "sono etero"...
il pc si spegne, esce fumo e si sente puzza di bruciato...
provi a riaccenderlo e niente...
allora ti accorgi che non era uno scherzo ma un vero attacco che ha sfruttato la povera architettura buggata del tuo procione core 2...

ps: ma di amd non si sa niente? possibile che solo intel abbia questi bug sfruttabili da malintenzionati?

Raga.. la situazione può diventare alquanto seria.. e cmq.. un fondo di verità, credo ci sia.. eccome, se c'è! Certo, alla fine, nn credo ke queste persone ke hanno queste capacità, se la possono prendere con un pc desktop ke contenga qualche file.. o qualche immagine persona, ma a livello di business.. la cosa comincia a farsi molto ma molto + seria, specie nelle grandi reti di pc.. in posti dove, c'è un giro d'affari abbastanza elevato. Certamente, è anche lecito pensare al fatto ke, ki comincia, nn si butterà mai su una banca o farà danni ad un'azienda.. con il rischio d essere chiuso dentro dopo qualche mese..

L'attenzione maggiore, (a prescindere dal fatto ke.. questi attacchi siano praticabili o meno, da un numero piuttosto numerabile di gente..), va cmq a tutte queste cpu low cost con cache ridotta.. ke.. a mio avviso, oltre alla cache, x essere destinati al low cost, sicuramente in fase di progettazione è probabile ke x rientrare nella fascia, abbiano + bag di una cpu ke costa il doppio o il triplo.. e infatti NON A CASO.. QUESTE CPU.. NN INCLUDONO NE LA VT E NEPPURE LA TXT.. tecnologie, atte cmq, a limitare questo tipo di problemi con il criptaggio dei dati.. e con altri controlli ke invece sono racchiuse in quelle cpu dove queste tecnologie sono presenti e ke cmq, possono definirsi "di prima scelta".

X quanto riguarda i vecchi computer.. penso ke possiamo stare + tranquilli.. xché ki sviluppa questo tipo d'attacco, mira a colpire quante + macchine possibili, e nn di certo, attenzionerebbe la sua bravura nel colpire una macchina da 20-30 euro.. adibita al download o cmq, a compiti futili.. ke anche quando venissero interrotti, nn accadrebbe da parte dell'utente nessuna drastica perdita di dati.. e x lo + nn farebbe neanche tanto clamore: figuriamoci se una skermata blu x esempio.. su un pIII poteste destare a sospetti di un attacco di questo tipo.. in quanto potrebbe essere qualsiasi componente a generare quel tipo di errore, comunissimo ma nn insolito in macchine con i loro 8-10 anni di vita sulle spalle..

Stessa cosa vale x Amd.. Se oggi x oggi.. Intel detiene l'80% della fetta di mercato mondiale.. è + a rischio e vulnerabile di Amd ke ne detiene solo il 20%.. e ke cmq, prende acqua da tte le parti.

In ogni caso, staremo a vedere le dimostrazioni, ma cmq, x quanto mi riguarda.. nn c'è niente di banale o di strano e credo ke IL TUTTO sia fattibile o possibile.. e siamo ben lontani dal pensarlo come pensiero futuristico o fantascientifico. Bye.

la cosa che mi rende dubbioso e' che ha dichiarato che e' possibile violare la macchina con lo stesso attacco indipendentemente dal sistema operativo (che quindi hanno gestioni dei processi e della memoria completamente differenti).
Un buffer overflow quindi non avrebbe necessariamente lo stesso risultato su due OS diversi.
il buffer overflow è a livello dei registri, non della memoria gestita dall'OS.
è possibile invece eccome sfruttare una falla di questo tipo, a prescindere dagli OS. basta sapere quale registro caricare, che payload inserire e il gioco è abbastanza facile.. certo il proof of concept magari non avrà lo stesso sorgente per ogni OS, però il comportamento desiderato sarà lo stesso..

il buffer overflow è a livello dei registri, non della memoria gestita dall'OS.
è possibile invece eccome sfruttare una falla di questo tipo, a prescindere dagli OS. basta sapere quale registro caricare, che payload inserire e il gioco è abbastanza facile.. certo il proof of concept magari non avrà lo stesso sorgente per ogni OS, però il comportamento desiderato sarà lo stesso..
Luke, scusami, ma il buffer overflow non si genera "caricando" dei registri per poi svaccare una area di memoria ben definita (stack e/o heap) per eseguire del codice arbitrario (se modifico lo stack posso inserirgli un indirizzo di memoria di ritorno, che viene caricato nel registro EBP, e quindi fare eseguire il codice che voglio io...) ?

il buffer overflow è a livello dei registri, non della memoria gestita dall'OS.
è possibile invece eccome sfruttare una falla di questo tipo, a prescindere dagli OS. basta sapere quale registro caricare, che payload inserire e il gioco è abbastanza facile.. certo il proof of concept magari non avrà lo stesso sorgente per ogni OS, però il comportamento desiderato sarà lo stesso..
e' molto che non programmo in assembly, ma gli errata segnalati qui (http://download.intel.com/design/processor/specupdt/318733.pdf) includono anche scritture errate in memoria (valori o indirizzi)
resto invece d'accordo con te che una volta avuto accesso per l'esecuzione del payload il gioco e' fatto.

Attenderemo gli sviluppi.
Ad ogni modo, chissa' che questa dimostrazione serva ai produttori di CPU per costringersi a concentrarsi di piu' sulla qualita' ed affidabilita' dei propri prodotti piuttosto che sulle mere frequenze di esercizio.

Luke, scusami, ma il buffer overflow non si genera "caricando" dei registri per poi svaccare una area di memoria ben definita (stack e/o heap) per eseguire del codice arbitrario (se modifico lo stack posso inserirgli un indirizzo di memoria di ritorno, che viene caricato nel registro EBP, e quindi fare eseguire il codice che voglio io...) ?

si.

dipende dal bug.. :D
qualsiasi istruzione che provoca l'azzeramento o il controllo dei flag di segmento protetto,
può dare il controllo totale al programma.. :rolleyes:

Oramai anche le CPU dovrebbero avere una flash x l'upgrade del codice.. :rolleyes:

che qualcuno si riserva una porta di accesso remoto ? magari anche non documentata ? :asd:

veramente "l'upgrade del codice" è previsto sin dai tempi del pentium pro ;)

qui la faccenda è molto seria....se inizialmente questi virus colpiranno, come ha detto qualcuno ,le aziende,prima o poi arriveranno anche sulla grande fetta dei personal computer nel vero senso della parola....e allora che si farà?per esempio vorrei capire,la mia cpu è soggetta al bug e lo sarà per sempre giusto?per essere al sicuro dovrò comprare una cpu senza quel bug?una volta attaccata la cpu è da buttare giusto?che macello....stavo pensando ad un possibile firewall della cpu ma è alquanto impossibile dato che li parliamo di vere e proprio istruzioni macchina ed un'operazione è composta di quelle poche operazioni dell'assembly in sequenza...sarebbe irriconoscibile un'azione nociva

qui la faccenda è molto seria....se inizialmente questi virus colpiranno, come ha detto qualcuno ,le aziende,prima o poi arriveranno anche sulla grande fetta dei personal computer nel vero senso della parola....e allora che si farà?per esempio vorrei capire,la mia cpu è soggetta al bug e lo sarà per sempre giusto?per essere al sicuro dovrò comprare una cpu senza quel bug?una volta attaccata la cpu è da buttare giusto?che macello....stavo pensando ad un possibile firewall della cpu ma è alquanto impossibile dato che li parliamo di vere e proprio istruzioni macchina ed un'operazione è composta di quelle poche operazioni dell'assembly in sequenza...sarebbe irriconoscibile un'azione nociva

allora:
1) Intel rilascia periodicamente degli aggiornamenti per il microcode della CPU, basta caricarli ad ogni avvio (e la cosa si può fare solo con linux) per avere una CPU "senza" bug.
2) qualora si riuscissero a sfruttare i bug, la tua CPU non sarebbe da buttare!!!!! Qualcuno potrebbe solo prendere il controllo del tuo PC.
3) I firewall potrebbero adattarsi per prevenire questo tipo di attacco. Non un "firewall della cpu", un "firewall e basta". L'attacco, per quanto scritto nella news, consisterebbe in pacchetti TCP configurati ad hoc. Riconoscere e scartare i pacchetti è proprio quello che, per sommi capi, fa un firewall.

Prima di tutto grazie per lo sbruffone, però cerchiamo di capirci.
Non stò denigrando nessuno e non stò dicendo che non sia "bucabile" nessuno dei sistemi citati. Stò solo cercando di dire che per arrivare ed eseguire il microcodice bacato su una cpu partendo da uno script java c'è una pila di software molto lunga.
O tutto il software che c'è sopra al microcode bacato delle cpu è scritto IGNORANDO questi bachi oppure la vedo molto ma molto difficile.

Mi sembra che siamo in un paese libero e ognuno possa esprimere le proprie opinioni; non mi sembra di aver insultato nessuno.

:D

ti spiego..Innanzitutto quello di cui stai parlando tu è JAVA, un linguaggio pseudocompilato che ha bisogno della java virtual machine per funzionare..javascript è un linguaggio interpretato che necessita solo di un browser compatibile. Ti hanno detto che stai dicendo un mucchio di scemenze perché non serve che tutti i software da te citati siano buggati (questo senza nulla togliere al fatto che sicuramente lo sono perché nessun programma è immune dai bug)..se l'attacco consiste realmente in pacchetti configurati ad hoc in grado di sfruttare i bug della cpu, sarebbe indipendente dai software installati e dal sistema operativo; per portare avanti l'attacco sarebbe potenzialmente necessario solo un computer collegato ad internet con una CPU buggata.

La cosa comunque non mi sorprende affatto..

P.S.: si scrive sto, non stò :)

non ero a conoscenza degli hotfix della cpu!!dove posso trovarli?e come si installano?

Che i up siano buggati è noto da quando anno preso piede(anni 80 se non sbaglio) le architetture intel al posto delle altre (es Texas) per mentenere la compatibilità con le precedenti versioni già in mercato.è interessante vedere un pò di storia dell'ingegneria e delle grosse cavolate fatte.

Non si installano, si caricano ad ogni avvio, e lo puoi fare solo con linux
http://downloadcenter.intel.com/Detail_Desc.aspx?agr=N&ProductID=483&DwnldID=14303&strOSs=39&OSFullName=Linux*&lang=eng
questo è per i p4, se scorri la pagina ci sono i microcode anche per gli altri processori..devi copiarlo in /etc/firmware ed il kernel dev'essere configurato per caricarlo (c'è un opzione apposta)

grazie mille!!!mi puoi esporre rischi e procedura completa?!o mi dai qualche link...

veramente "l'upgrade del codice" è previsto sin dai tempi del pentium pro ;)
non mi sembra che la CPU abbia una memoria flash.. :mbe:

Raga.. la situazione può diventare alquanto seria.. e cmq.. un fondo di verità, credo ci sia.. eccome, se c'è! Certo, alla fine, nn credo ke queste persone ke hanno queste capacità, se la possono prendere con un pc desktop ke contenga qualche file.. o qualche immagine persona, ma a livello di business.. la cosa comincia a farsi molto ma molto + seria, specie nelle grandi reti di pc.. in posti dove, c'è un giro d'affari abbastanza elevato. Certamente, è anche lecito pensare al fatto ke, ki comincia, nn si butterà mai su una banca o farà danni ad un'azienda.. con il rischio d essere chiuso dentro dopo qualche mese..

L'attenzione maggiore, (a prescindere dal fatto ke.. questi attacchi siano praticabili o meno, da un numero piuttosto numerabile di gente..), va cmq a tutte queste cpu low cost con cache ridotta.. ke.. a mio avviso, oltre alla cache, x essere destinati al low cost, sicuramente in fase di progettazione è probabile ke x rientrare nella fascia, abbiano + bag di una cpu ke costa il doppio o il triplo.. e infatti NON A CASO.. QUESTE CPU.. NN INCLUDONO NE LA VT E NEPPURE LA TXT.. tecnologie, atte cmq, a limitare questo tipo di problemi con il criptaggio dei dati.. e con altri controlli ke invece sono racchiuse in quelle cpu dove queste tecnologie sono presenti e ke cmq, possono definirsi "di prima scelta".

X quanto riguarda i vecchi computer.. penso ke possiamo stare + tranquilli.. xché ki sviluppa questo tipo d'attacco, mira a colpire quante + macchine possibili, e nn di certo, attenzionerebbe la sua bravura nel colpire una macchina da 20-30 euro.. adibita al download o cmq, a compiti futili.. ke anche quando venissero interrotti, nn accadrebbe da parte dell'utente nessuna drastica perdita di dati.. e x lo + nn farebbe neanche tanto clamore: figuriamoci se una skermata blu x esempio.. su un pIII poteste destare a sospetti di un attacco di questo tipo.. in quanto potrebbe essere qualsiasi componente a generare quel tipo di errore, comunissimo ma nn insolito in macchine con i loro 8-10 anni di vita sulle spalle..

Stessa cosa vale x Amd.. Se oggi x oggi.. Intel detiene l'80% della fetta di mercato mondiale.. è + a rischio e vulnerabile di Amd ke ne detiene solo il 20%.. e ke cmq, prende acqua da tte le parti.

In ogni caso, staremo a vedere le dimostrazioni, ma cmq, x quanto mi riguarda.. nn c'è niente di banale o di strano e credo ke IL TUTTO sia fattibile o possibile.. e siamo ben lontani dal pensarlo come pensiero futuristico o fantascientifico. Bye.
TXT e VT non neutralizzano i bug software.. che sono comuni sia su Cpu Palladium che Cpu non Palladium

grazie mille!!!mi puoi esporre rischi e procedura completa?!o mi dai qualche link...

la procedura, per sommi capi, è quella che ti ho descritto:
1) scarichi il microcode
2) lo copi in /etc/firmware
3) basta!

ovviamente il kernel dev'essere predisposto per caricare il microcode..se non lo è dovresti ricompilarlo (se non l'hai mai fatto dovresti cercare una guida su google...basta scrivere ricompilazione del kernel e ti esce una pletoria di siti).
In particolare dovresti solo selezionare un opzione "microcode support on intel ecc. ecc." o qualcosa del genere..dovrebbe stare nella scheda di configurazione del processore (dove ti chiede di selezionare la famiglia di processori tanto per intenderci), non puoi sbagliare!

OVVIAMENTE, non si tratta di una memoria flash...è qualcosa di molto più complesso. Il microcode comprende delle istruzioni ad un livello più basso dell'assembly (devono appunto definire il comportamento delle istruzioni assembly) che vengono caricate in una memoria ad alta velocità integrata nel processore.
Infatti le istruzioni a basso livello, anche le più elementari, coinvolgono altre istruzioni, ancora più elementari.

Su http://en.wikipedia.org/wiki/Microcode viene riportato un esempio per capire meglio il funzionamento di queste operazioni.

"For example, a single typical microinstruction might specify the following operations:

* Connect Register 1 to the "A" side of the ALU
* Connect Register 7 to the "B" side of the ALU
* Set the ALU to perform two's-complement addition
* Set the ALU's carry input to zero
* Store the result value in Register 8
* Update the "condition codes" with the ALU status flags ("Negative", "Zero", "Overflow", and "Carry")
* Microjump to MicroPC nnn for the next microinstruction"

[...]quante + macchine possibili, e nn di certo, attenzionerebbe la sua bravura nel colpire una macchina da 20-30[...]
:D :D :D attenzionerebbe!!!!

la procedura, per sommi capi, è quella che ti ho descritto:
1) scarichi il microcode
2) lo copi in /etc/firmware
3) basta!

ovviamente il kernel dev'essere predisposto per caricare il microcode..se non lo è dovresti ricompilarlo (se non l'hai mai fatto dovresti cercare una guida su google...basta scrivere ricompilazione del kernel e ti esce una pletoria di siti).
In particolare dovresti solo selezionare un opzione "microcode support on intel ecc. ecc." o qualcosa del genere..dovrebbe stare nella scheda di configurazione del processore (dove ti chiede di selezionare la famiglia di processori tanto per intenderci), non puoi sbagliare!

OVVIAMENTE, non si tratta di una memoria flash...è qualcosa di molto più complesso. Il microcode comprende delle istruzioni ad un livello più basso dell'assembly (devono appunto definire il comportamento delle istruzioni assembly) che vengono caricate in una memoria ad alta velocità integrata nel processore.
Infatti le istruzioni a basso livello, anche le più elementari, coinvolgono altre istruzioni, ancora più elementari.

Su http://en.wikipedia.org/wiki/Microcode viene riportato un esempio per capire meglio il funzionamento di queste operazioni.

"For example, a single typical microinstruction might specify the following operations:

* Connect Register 1 to the "A" side of the ALU
* Connect Register 7 to the "B" side of the ALU
* Set the ALU to perform two's-complement addition
* Set the ALU's carry input to zero
* Store the result value in Register 8
* Update the "condition codes" with the ALU status flags ("Negative", "Zero", "Overflow", and "Carry")
* Microjump to MicroPC nnn for the next microinstruction"


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

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

<;23392930']http://en.wikipedia.org/wiki/Microcode
Si, questo era chiaro, ma non è riferito alla classe x86 :D

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

Guarda, copio direttamente un pezzo da http://en.wikipedia.org/wiki/Microcode :
Linux (on x86 PCs) has a patch program that fixes botched CPU microcode. Of all UNIX (and UNIX-like) operating systems on Intel (and Intel x86-compatible) PCs there has been an ongoing requirement to patch erroneous microcode since the FPU multiplier problem that was endemic to some Pentiums.

* Microsoft Windows also has similar patches, but does generally not label them as such since Windows XP.
* So far only x86 CPUs have microcode patches. This is unknown with RISC CPUs as well as general purpose DSPs.

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

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/core2duo/documentation.htm?iid=prod_core2duo+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.. :rolleyes:

<;23393802']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/core2duo/documentation.htm?iid=prod_core2duo+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.. :rolleyes:

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)

0x00000001, 0x00000013, 0x02062001, 0x00000683,
0x2f0da1b0, 0x00000001, 0x00000001, 0x00000000,
0x00000000, 0x00000000, 0x00000000, 0x00000000,
0xbf5ad468, 0xc79f5237, 0xbd53889e, 0x896bfd13,
0x7adc0c8f, 0x44e9e0bc, 0x1a331fc9, 0x00b0f479,
0x53e9ceb3, 0xb14131a4, 0x39fc8310, 0x6993ee0d,
0xdb0c59b4, 0x67f24fd0, 0x63e83516, 0x0a4d411d,
0xb86a4294, 0x72c2edc5, 0xc543c5df, 0x7f3dd290,

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!

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)

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

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

probabilmente volevi dire dec, jnz..

Esattamente :D

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!!
Quante sciocchezze dici ? :D
so benissimo cos'è il microcodice delle cpu CISC :asd:
probabilmente Intel si riserva la documentazione tecnica, e chissà,
magari modificando il microcode riescono pure ad attivare le TXT e il TPA.. :asd:

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

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)
Questo è interessante, bisognerebbe capire, se è direttamente eseguibile
oppure se si prevedono loader specifici...
http://www.uxc.it/?q=progetto_studente/view/475

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

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

Ah, io dico sciocchezze?
Mi rendo conto di non essere troppo ferrato in materia perché la cosa non mi tange in quanto ho un processore AMD Athlon XP, però conosco sufficientemente bene l'argomento di cui si parla.
Allora, riassumiamo per chiarezza quello che hai detto...
All'inizio credevi che la CPU non avesse una memoria flash, che è vero, ma hai implicitamente dichiarato la tua totale ignoranza in materia.
Poi hai parlato di CPU palladium, CHE NON ESISTONO, forse hai sentito questo nome qualche anno fa in internet, ma ti posso assicurare che non esistono e se te ne vuoi convincere guarda pure questo http://it.wikipedia.org/wiki/Next-Generation_Secure_Computing_Base.
In seguito hai affermato che l'upgrade del microcode non è previsto per la classe x86, una cosa palesemente ridicola perché in pratica si può dire, esagerando, che è previsto SOLO per la classe x86.
Successivamente hai tirato in ballo il sistema operativo ed il kernel, che non centrano assolutamente niente e hai espresso le tue perplessità in merito all'aggiornamento, sostenendo che probabilmente c'è un istruzione, o opcode che dir si voglia, in grado di portare a termine l'aggiornamento.
Di colpo sei diventato un esperto, probabilmente le cose, in un modo o nell'altro, ti erano sfuggite e hai detto che è il BIOS che provvede all'aggiornamento.

Io non ho voglia né di fare polemica né di mettermi a litigare, su un forum peraltro, con uno che non ha nemmeno l'umiltà di ammettere di non sapere neanche lontanamente di cosa si stia parlando, perciò o cambi tono o mi limiterò ad ignorarti. :)

Saluti,
Marco

P.S.: una cosa giusta l'hai detta, una cosa che era già stata detta da elliano e che probabilmente hai letto su quel sito che hai postato (il primo che esce fuori se si cerca "microcode" su google) cioè che l'update non è definitivo e dev'essere ricaricato ad ogni avvio :)

se volete posto tutto il microcode!

Ah, io dico sciocchezze?
Mi rendo conto di non essere troppo ferrato in materia perché la cosa non mi tange in quanto ho un processore AMD Athlon XP, però conosco sufficientemente bene l'argomento di cui si parla.
Allora, riassumiamo per chiarezza quello che hai detto...
All'inizio credevi che la CPU non avesse una memoria flash, che è vero, ma hai implicitamente dichiarato la tua totale ignoranza in materia.
e lo credo tuttora. poi l'ignoranza frà i due, non è certo mia.. :D

Poi hai parlato di CPU palladium, CHE NON ESISTONO, forse hai sentito questo nome qualche anno fa in internet, ma ti posso assicurare che non esistono e se te ne vuoi convincere guarda pure questo http://it.wikipedia.org/wiki/Next-Generation_Secure_Computing_Base
TXT = Trusted Execution Technology... non lo sapevi ? :nono:
http://it.wikipedia.org/wiki/Trusted_Execution_Technology

In seguito hai affermato che l'upgrade del microcode non è previsto per la classe x86, una cosa palesemente ridicola perché in pratica si può dire, esagerando, che è previsto SOLO per la classe x86
questo lo stai inventando tu, adesso,
Sò benissimo che ci sono cpu che implemetano la memoria R/W di microcode addirittura
come specifica di proggetto... io mi riferivo circa le modalità dell' x86 che oltrettutto
non sono neppure documentate.. ;)


Successivamente hai tirato in ballo il sistema operativo ed il kernel, che non centrano assolutamente niente e hai espresso le tue perplessità in merito all'aggiornamento, sostenendo che probabilmente c'è un istruzione, o opcode che dir si voglia, in grado di portare a termine l'aggiornamento.
Di colpo sei diventato un esperto, probabilmente le cose, in un modo o nell'altro, ti erano sfuggite e hai detto che è il BIOS che provvede all'aggiornamento.
Perchè è stata provata, in tempi non proprio recenti, anche la via della modifica
software, cioè del compilato, per non includere istruzioni potenzialmente buggate..
Non è che io di colpo sono diventato esperto, sono 20 anni che ci stò dentro,
e non sono uno che "tenta di disassemblare il microcodice", operazione abbastanza improbabile.. :D
Nel bios evidentemente c'è una serie di istruzioni, non documentata sui manuali ufficiali,
che predispone (ad ogni accensione del PC) la CPU a ricevere la stringa di microcode,
dal programma del bios.

Io non ho voglia né di fare polemica né di mettermi a litigare, su un forum peraltro, con uno che non ha nemmeno l'umiltà di ammettere di non sapere neanche lontanamente di cosa si stia parlando, perciò o cambi tono o mi limiterò ad ignorarti. :)

Saluti,
Marco
Calma !
l'unico che non sà "neanche lontanamente di cosa si stia parlando" frà i due, non sono io... :D
tu prima studia tutte le IA32 e 64, coprocessore matematico compreso,
poi passa alle istruzioni RISC delle CPU Sun Spark
che poi nè riparliamo.. :asd:

:) Non degnerò di risposta niente di quello che hai detto, mi rifiuto, rimani pure nelle tue convinzioni e continua ad usare paroloni per impressionare la gente (me no di certo), la cosa non mi tange affatto..
Ho passato diversi anni a programmare in ASM su Linux e su Windows, figurati se mi metto a discutere con uno come te. :)

PS 1: si scrive so, non sò
PS 2: si scrive fra, non frà
...e vantatene pure di essere più vecchio di me :)

:) Non degnerò di risposta niente di quello che hai detto, mi rifiuto, rimani pure nelle tue convinzioni e continua ad usare paroloni per impressionare la gente (me no di certo), la cosa non mi tange affatto..
Ho passato diversi anni a programmare in ASM su Linux e su Windows, figurati se mi metto a discutere con uno come te. :)
non voglio impressionare nessuno :D
Beh se sei dell' 89 posso credere che hai iniziato a programmare a 12 anni, diciamo che
l'assembler non prima dei 16.. quindi quindi, mettendo anche in conto la squola,
non penso che hai fatto più di 4/5 anni di programmazione seria.. :D
Eppoi oggi, all' uni non si studia neanche più il Prolog, che vi farebbe tanto bene.. :rolleyes:

PS 1: si scrive so, non sò
PS 2: si scrive fra, non frà
...e vantatene pure di essere più vecchio di me :)
non ti attaccare a queste semplici scuse :D

scommetto che tu programmi direttamente in linguaggio binario.....:stordita:

<;23403922']
Eppoi oggi, all' uni non si studia neanche più il Prolog, che vi farebbe tanto bene.. :rolleyes:


Magari nella tua, perchè nella mia si studia eccome. Nei corsi di Intelligenza Artificiale I e Intelligenza Artificiale II, nello specifico.

Magari nella tua, perchè nella mia si studia eccome. Nei corsi di Intelligenza Artificiale I e Intelligenza Artificiale II, nello specifico.

Ma figurati se sa minimamente quello di cui sta parlando!

<;23403922']non ti attaccare a queste semplici scuse :D
Non ho bisogno di attaccarmi a queste cose, uno che programma da 20 anni in assembly non scrive "Non credo che la CPU abbia una memoria flash"..
In ogni caso è grave..sono errori da prima elementare..non sai nemmeno scrivere nella tua lingua madre e pretendi di insegnarmi qualcosa? Spero almeno che "squola" sia una cosa voluta...

P.S.: fai come credi, io ho smesso di perdere tempo con te :)

Mi sembra che investiate in battibecchi almeno il triplo delle energie che ci vogliono a trovare una risposta (non definitiva, sia chiaro).
Spulciato il sorgente, in banale C, dell'utility che dovrebbe aggiornare il microcodice si scopre che apre due file, uno in lettura su disco, che contiene il microcodice in formato, diciamo, sorgente (niente di trascendentale, legge quattro numeri esadecimali di trentadue bit per ogni riga e li dispone consecutivamente in un buffer in memoria) e uno di dispositivo. Quale sarà mai questo dispositivo? guardiamo in cima al file:
#define MICROCODE_DEVICE_DEFAULT "/dev/cpu/microcode"
#define MICROCODE_FILE_DEFAULT "/etc/microcode.dat"

L'avete notato?
Ok, cambiamo destinazione e andiamo su The Linux Cross-reference (http://lxr.linux.no/)
Cerchiamo la parola "microcode" trovando una lunga lista di riferimenti, tra i quali però c'è qualcosa di interessante: arch/i386/kernel/microcode.c (ancora C! Siiiii! Il C vi perseguiterà in eterno, oh servi del RAD :ciapet: ).
Nel kernel 2.6.23 in esame (tale file nel 2.6.24 scompare, probabilmente hanno cambiato interfaccia, non sono un esperto) tale file contiene 851 righe (pensavo peggio) che scorse velocemente rivelano che la funzione che esegue l'upload del firmware (ma sarà un upload od un download? Da che lato si guarda?:D ) è:
static void apply_microcode(int cpu)

Leggendo i commenti :eek: alla linea 327 si scopre che:
/* write microcode via MSR 0x79 */
wrmsr(MSR_IA32_UCODE_WRITE,
(unsigned long) uci->mc->bits,
(unsigned long) uci->mc->bits >> 16 >> 16);
wrmsr(MSR_IA32_UCODE_REV, 0, 0);

Ora, io non provo neanche a cercare nella documentazione ufficiale Intel a cosa serva questo MSR 79 per due validissimi motivi:

Una volta ho provato a dare una scorsa ai tre volumoni e l'ho trovata motruosamente pallosa
L'ultima volta che ho programmato semi-seriamente in assembly ero su un C=64, quindi potrei non essere all'altezza

Comunque se qualcuno di voi si sente a suo agio con tale documentazione è pregato di offrire un servizio a noi tutti riportando le sue scoperte.
P.S. Purtroppo all'uni non si studia neanche più il C, va di moda il Java!
P.P.S. Il Vero Programmatore programma ESCLUSIVAMENTE in linguaggio macchina che immette direttamente in binario tramite il tastierino numerico
P.P.P.S. Mi sa che il più vecchio sono io :sofico:

Sì, c'è un riferimento nel Volume 3B.
A pagina 313 viene descritta nel dettaglio la procedura di aggiornamento del Microcode.
A pagina 471 inizia la descrizione di tutti gli MSR (per chi non lo sapesse vuol dire model specific register; sono dei registri comuni ad es. ad una famiglia di processori).
A pagina 474 descrive l'MSR 79H:
BIOS Update Trigger (R/W)
Executing a WRMSR instruction to this MSR causes a microcode update to be loaded into the processor. See Section 8.11.6, “Microcode Update Loader.” A processor may prevent writing to this MSR when loading guest states on VM entries or saving guest states on VM exits.
Ovvero:
BIOS Update Trigger (R/W)
Eseguire l'istruzione WRMSR a questo MSR carica l'aggiornamento del microcode nel processore. Vedi sezione 8.11.6, “Microcode Update Loader.” Un processore può impedire la scrittura di questo MSR mentre carica uno stato ospite all'avvio di una VM (Virtual machine suppongo) o salva uno stato ospite all'uscita di una VM.
La sezione 8.11.6 è riferita al manuale 3A (Pag. 435) e parla dei requisiti del BIOS, delle differenze tra famiglie di processori, della verifica dell'aggiornamento e, se ho capito bene, della possibilità di inserire un "loader" direttamente nel BIOS.

http://developer.intel.com/products/processor/manuals/index.htm (questa è la pagina da cui è possibile scaricare i manuali)

Sì, c'è un riferimento nel Volume 3B.
A pagina 313 viene descritta nel dettaglio la procedura di aggiornamento del Microcode.
A pagina 471 inizia la descrizione di tutti gli MSR (per chi non lo sapesse vuol dire model specific register; sono dei registri comuni ad es. ad una famiglia di processori).
A pagina 474 descrive l'MSR 79H:

Ovvero:

La sezione 8.11.6 è riferita al manuale 3A (Pag. 435) e parla dei requisiti del BIOS, delle differenze tra famiglie di processori, della verifica dell'aggiornamento e, se ho capito bene, della possibilità di inserire un "loader" direttamente nel BIOS.

http://developer.intel.com/products/processor/manuals/index.htm (questa è la pagina da cui è possibile scaricare i manuali)

Da quando è uscito il volume 3B, scusa? Io ho il volume 3 in un singolo libro.

Comunque se qualcuno di voi si sente a suo agio con tale documentazione è pregato di offrire un servizio a noi tutti riportando le sue scoperte.
P.S. Purtroppo all'uni non si studia neanche più il C, va di moda il Java!
P.P.S. Il Vero Programmatore programma ESCLUSIVAMENTE in linguaggio macchina che immette direttamente in binario tramite il tastierino numerico
P.P.P.S. Mi sa che il più vecchio sono io :sofico:

nella mia università si studia c in laboratorio di programmazione II...non so che università conosci tu...

Sì, c'è un riferimento nel Volume 3B.
A pagina 313 viene descritta nel dettaglio la procedura di aggiornamento del Microcode.
A pagina 471 inizia la descrizione di tutti gli MSR (per chi non lo sapesse vuol dire model specific register; sono dei registri comuni ad es. ad una famiglia di processori).
A pagina 474 descrive l'MSR 79H:

Ovvero:

La sezione 8.11.6 è riferita al manuale 3A (Pag. 435) e parla dei requisiti del BIOS, delle differenze tra famiglie di processori, della verifica dell'aggiornamento e, se ho capito bene, della possibilità di inserire un "loader" direttamente nel BIOS.

http://developer.intel.com/products/processor/manuals/index.htm (questa è la pagina da cui è possibile scaricare i manuali)
CVD ! Bravo ! era proprio questo quello che cercavo.. :D

in effetti la CPU carica la stringa in memoria ad ogni accensione.. :rolleyes:

Probabilmente anche l' Athlon ha lo stesso meccanismo di update,
benchè il microcodice potrebbe essere molto diverso da quello Intel.

IA32 Vol 3B:
http://download.intel.com/design/processor/manuals/253669.pdf

nella mia università si studia c in laboratorio di programmazione II...non so che università conosci tu...

E aggiungerei anche laboratorio di sistemi operativi ;)

ancora non ci arrivo :D :D

Magari nella tua, perchè nella mia si studia eccome. Nei corsi di Intelligenza Artificiale I e Intelligenza Artificiale II, nello specifico.
in effetti io ho anche scritto compilatori Prolog, con l'implementazione delle variabili ricorsive,
come l'originale di marsiglia.. no, non il sapone.. :D

nella mia università si studia c in laboratorio di programmazione II...non so che università conosci tu...

Ammetto di non essermi aggiornato sui corsi degli ultimi tre o quattro anni ma, all'uni di Salerno, corso di laurea in Informatica c'è un solo esame sul C (Linguaggi di programmazione I); è il primo che ho dato all'epoca (e ho beccato anche un 18 :mad: )

laboratorio di prog I a l'aquila è su java...

Ed inoltre aggiungo che, siccome il core step varia anche nella stessa famiglia,
allora è necessario selezionare il microcodice specifico, eseguendo prima l'istruzione
di CPU ID che ridà il valore della versione.
Questo xchè il bios della MoBo contiene molti tipi di microcode, uno per ogni tipo
di CPU certificato per la scheda stessa. :rolleyes:

Naturalmente è già tanto che la Factory dichiara le istruzioni di loader,
mentre rimane invece top secret ciò che và a modificare il microcodice.. :rolleyes:

da questo punto di vista mi piacerebbe d+ una CPU open source.. :rolleyes:

<;23434687']
da questo punto di vista mi piacerebbe d+ una CPU open source.. :rolleyes:

Magari sotto GPL, cosi come la montiamo sulla scheda madre dobbiamo rilasciare pure i progetti della scheda madre e di qualsiasi componente ci si attacca. :asd:

Magari sotto GPL, cosi come la montiamo sulla scheda madre dobbiamo rilasciare pure i progetti della scheda madre e di qualsiasi componente ci si attacca. :asd:
In un certo senso c'e':

http://www.opensparc.net/

anche se non si tratta di CPU x86 (o x86-64) ;)

http://www.opensparc.net/images/stories/t2/ultrasparc-t2-layout_thumb.png (http://www.opensparc.net/images/stories/t2/ultrasparc-t2-layout.png)

E' interessante vedere come parecchi dei commenti che vedo abbiano la pretesa di saperne più di kaspersky semplicemente il miglior team di difesa antivirus dal 1998 in poi...Evviva l'umiltè.