Intel e AMD tagliate fuori dal governo russo: Putin si affida alla tecnologia nazionale

[Emin001]

Originariamente inviato da blindwrite

http://www.mikron.sitronics.com/about/

Grazie per il link, non la conoscevo. Mi stai dicendo che i 28nm sono irrealizzabili dentro i confini russi e che di strada ne hanno da fare visto che sono passati ai 90nm solo nel 2012 (questa azienda dovrebbe essere la più grande del paese)


Comunque per 28nm mi sono dato una spiegazione, probabilmente la prima testata giornalistica che ha dato notizia, ha dato per buono i 28 nm del processore amd che è basato sulla medesima architettura e struttura.

[cdimauro]

Originariamente inviato da !fazz

cmq strana veramente come scelta, come se fosse possibile implementare un sistema di controllo completo nel solo processore, bastava un sistema operativo proprietario per le questioni di sicurezza il resto è solo puro e semplice protezionismo economico

Assolutamente d'accordo. Se il problema è la sicurezza, non ha senso costruirsi un processore tutto loro.

Originariamente inviato da Emin001

Grazie per il link, non la conoscevo. Mi stai dicendo che i 28nm sono irrealizzabili dentro i confini russi e che di strada ne hanno da fare visto che sono passati ai 90nm solo nel 2012 (questa azienda dovrebbe essere la più grande del paese)

Esattamente. Sembrano all'età della pietra.

[zappy]

Originariamente inviato da calabar

Peccato, per un attimo ho pensato: vuoi vedere che tirano fuori un'alternativa x86 con le palle sostenuta dall'intero mercato russo?
Poi sono tornato alla realtà e mi sono ricordato che la licenza x86 non è propriamente di libero utilizzo...

visto il punto a cui sono potrebbero anche fregarsene delle licenze... cos'è, intel gli fa causa in un tribunale russo?

[goriath]

Originariamente inviato da zappy

visto il punto a cui sono potrebbero anche fregarsene delle licenze... cos'è, intel gli fa causa in un tribunale russo?

Potrebbero invadere la California

[LMCH]

Originariamente inviato da cdimauro

Assolutamente d'accordo. Se il problema è la sicurezza, non ha senso costruirsi un processore tutto loro.

Lo ha eccome, se si considera che Intel ha dichiarato pubblicamente che è disponibile a fornire cpu con set d'istruzioni "con estensioni custom" anche a clienti "normali" (basta che ne ordino tante o che il prezzo sia sufficientemente alto) e che all'avvio gli x86 possono caricare degli aggiornamenti del microcode con cui eseguono le istruzioni più complesse (alterando quindi la loro implementazione).

Significa che gli x86 sono di fatto delle "scatole nere" in cui in ultima analisi
(a meno di controllarle una ad una a livello circuitale e poi cercando di fare il reverse engineering degli aggiornamenti del microcode) solo Intel sa cosa c'è e cosa non c'è realmente.

Invece nel caso degli ARM uno può acquistare le IP e le licenze per farsi produrre le cpu e verificare che quello che viene prodotto sia esattamente quello che era nelle specifiche.

Anche un S.O. "supersicuro" non ha difese quando la cpu su cui gira ha delle feature "non note a tutti" che possono essere usate per scassinarlo a piacere con quelle che sembrano istruzioni innocque ma che in una particolare sequenza attivano una qualche supercazzola nascosta.

[Vash_85]

Tempo fa lessi qualche news interessante...

http://news.softpedia.com/news/Secre...e-385194.shtml

http://www.popularresistance.org/new...ntly-hackable/

Vai a sapere se è vero... nel dubbio forse non sbagliano

[devilred]

Originariamente inviato da carlottoIIx6

sta andando verso la guerra fredda! tutto perché, questo grande statista, ha di fatot invaso l'ucraina invitando i separatisti a fare la guerra nella speranza del suo intervento. ora vede al mondo con sospetto e noi a lui. questo grande statista poteva causare un'altra guerra mondiale!

quel grande statista ha dimostrato di avere le palle e di salvaguardare gli interessi della russia, non come gli italiani che si svendono per un bicchiere di coca cola. la russia ha i suoi investimenti e interessi in ukraina e non la mollera' mai, il giorno che l'ukraina insistera' per entrare nella comunita' europea sara' guerra, poi voglio proprio vede' chi si mettera' contro la russia. nessuno logicamente, soprattutto europei che dipendono dalla russia stessa per i rifornimenti di gas.
la loro indipendenza informatica e' incominciata il giorno in cui hanno acquistato mandriva, tra non molto la russia sara' indipendente al 100% dal resto del mondo nel settore, e fanno bene. e' meglio combatterlo il sistema che diventarne schiavo.

[LMCH]

Originariamente inviato da devilred

quel grande statista ha dimostrato di avere le palle e di salvaguardare gli interessi della russia, non come gli italiani che si svendono per un bicchiere di coca cola. la russia ha i suoi investimenti e interessi in ukraina e non la mollera' mai, il giorno che l'ukraina insistera' per entrare nella comunita' europea sara' guerra, poi voglio proprio vede' chi si mettera' contro la russia. nessuno logicamente, soprattutto europei che dipendono dalla russia stessa per i rifornimenti di gas.
la loro indipendenza informatica e' incominciata il giorno in cui hanno acquistato mandriva, tra non molto la russia sara' indipendente al 100% dal resto del mondo nel settore, e fanno bene. e' meglio combatterlo il sistema che diventarne schiavo.

No.

L'Europa non è così vulnerabile visto che la Russia non può permettersi di non vendere gas e petrolio per stare in piedi e tutti i suoi maggiori clienti sono europei.

Solo ora stanno pensando di costruire gasdotti ed oleodotti per vendere in modo più agevole alla Cina, ma ci vorranno ancora anni ed anche con la Cina non sono esattamente rose e fiori, visto che le zone più a sud della Siberia sono troppo sottopopolate e troppo ricche di risorse perchè un vicino molto popoloso non ci faccia un pensierino (specialmente se si considera come si sta comportando quel vicino con le acque territoriali).

Anche a livello militare le cose non sono come alcuni pensano, la Russia sotto vari aspetti militarmente è messa peggio dei paesi europei nel loro insieme e non ha la logistica per spingersi più in la di tanto.
Riprendersi la Crimea le è stato relativamente facile, ma "si è fatta invitare" ed aveva contro uno stato in preda al caos e con le forze armate quasi allo sbando.
Infatti ora per altre aree confinanti dell'Ucraina ci va con i piedi di piombo.

[cdimauro]

Originariamente inviato da LMCH

Lo ha eccome, se si considera che Intel ha dichiarato pubblicamente che è disponibile a fornire cpu con set d'istruzioni "con estensioni custom" anche a clienti "normali" (basta che ne ordino tante o che il prezzo sia sufficientemente alto) e che all'avvio gli x86 possono caricare degli aggiornamenti del microcode con cui eseguono le istruzioni più complesse (alterando quindi la loro implementazione).

Hai detto bene: quelle più complesse. Che "casualmente" sono o poco utilizzate o proprio non utilizzate.

La stragrandissima maggioranza delle istruzioni viene eseguita senza microcodice. Lo puoi vedere andando a disassemblare il codice x86.

In tempi non sospetti ho scritto una serie di articoli sull'aspetto legacy e sulle statistiche delle istruzioni di queste architetture, a conferma di tutto ciò.

Per cui non dico che non sia sfruttabile il microcodice, ma risulta particolarmente difficile. Anche perché l'area per il microcodice è limitata, e proprio perché si tratta di aspetti minori / marginali / meno frequenti dell'architettura. Considera che per implementare ciò che hai ipotizzato non è che sia una passeggiata, e richiederebbe l'esecuzione di parecchio microcodice.
Dunque:
- spazio limitato a disposizione;
- prestazioni di quelle istruzioni molto più lente.

A tal proposito, visto che verrebbe alterata la normale esecuzione di quelle istruzioni, sarebbe possibile profilarle e notare l'eccessivo tempo richiesto. Ciò potrebbe far scattare la molla e fare quanto meno insospettire.

Significa che gli x86 sono di fatto delle "scatole nere" in cui in ultima analisi
(a meno di controllarle una ad una a livello circuitale e poi cercando di fare il reverse engineering degli aggiornamenti del microcode) solo Intel sa cosa c'è e cosa non c'è realmente.

Probabilmente si tratta di qualche trade secret, ma rimane quanto detto sopra. Lo scenario è tutt'altro che semplice da realizzare.

Invece nel caso degli ARM uno può acquistare le IP e le licenze per farsi produrre le cpu e verificare che quello che viene prodotto sia esattamente quello che era nelle specifiche.

Verissimo, nulla da dire. Ma esistono anche delle verifiche indirette per i processori di cui non si ha a disposizione tutto. Vedi sopra.

Anche un S.O. "supersicuro" non ha difese quando la cpu su cui gira ha delle feature "non note a tutti" che possono essere usate per scassinarlo a piacere con quelle che sembrano istruzioni innocque ma che in una particolare sequenza attivano una qualche supercazzola nascosta.

E qui capisci bene che la situazione si complicherebbe ancora di più, visto che le modalità con cui un compilatore emette una sequenza di istruzioni non sono sotto il diretto e totale controllo di Intel.

Anche nel caso in cui si utilizzasse un compilatore di Intel, il codice generato sarebbe in ogni caso pubblico e... disassemblabile. Dunque si potrebbero analizzare sequenze di istruzioni strane (che fanno uso di opcode complessi, quando ormai sono praticamente inutilizzati), e far scattare l'allarme.

Fermo restando quanto già detto sopra.

Originariamente inviato da Vash_85

Tempo fa lessi qualche news interessante...

http://news.softpedia.com/news/Secre...e-385194.shtml

http://www.popularresistance.org/new...ntly-hackable/

Vai a sapere se è vero... nel dubbio forse non sbagliano

Non ho mai letto tante fesserie messe insieme.

Un paio di cose macroscopiche:
- il circuito che funziona con la corrente staccata;
- addirittura l'impiego di un core ARM all'intero di uno... Intel!

[goriath]

Originariamente inviato da Vash_85

Tempo fa lessi qualche news interessante...

http://news.softpedia.com/news/Secre...e-385194.shtml

http://www.popularresistance.org/new...ntly-hackable/


Vai a sapere se è vero... nel dubbio forse non sbagliano

Fuffa.

Originariamente inviato da devilred

quel grande statista ha dimostrato di avere le palle e di salvaguardare gli interessi della russia, non come gli italiani che si svendono per un bicchiere di coca cola.

È un bel modo di vederla, ma anche no

[Vash_85]

Originariamente inviato da cdimauro

Non ho mai letto tante fesserie messe insieme.

Un paio di cose macroscopiche:
- il circuito che funziona con la corrente staccata;
- addirittura l'impiego di un core ARM all'intero di uno... Intel!

Mi sembrava effettivamente troppo esagerato....

Però avendo tastato la st******à degli ammerigani con mano mai dire mai...

[LMCH]

Originariamente inviato da cdimauro

Per cui non dico che non sia sfruttabile il microcodice, ma risulta particolarmente difficile.

Difficile se non sei Intel.

Basta solo che ci sia una falla sfruttabile (in questo caso inserita deliberatamente nel microcodice), non serve implementare chissà cosa.
E la sequenza di "attivazione" della falla anche se fa uso di istruzioni complesse non richiede che esse siano immediatamente consecutive (es: attivazione in due stadi) quindi sarebbe estremamente difficile da identificare come potenziale fonte di problemi.

[cdimauro]

Originariamente inviato da Vash_85

Mi sembrava effettivamente troppo esagerato....

Però avendo tastato la st******à degli ammerigani con mano mai dire mai...

Io sono americano, quindi... sta attento.

A parte gli scherzi, è un cumulo di fesserie che non hanno alcun fondamento. Roba da vecchia fantascienza.

Originariamente inviato da M47AMP

Originariamente inviato da cdimauro:
"Probabilmente si tratta di qualche trade secret, ma rimane quanto detto sopra. Lo scenario è tutt'altro che semplice da realizzare"

Ma anche no: mi ricordo di aver sostituito un vecchio Pentium 4 di una workstation entry level con uno più recente e più performante, ottenendone in cambio un messaggio di errore del BIOS al boot.
Il vendor mi fornì una patch di microcodice: evidentemente la mobo non supportava (forse il chipset) le nuove istruzioni del Pentium più recente, probabilmente il microcodice serviva per noperizzarle o comunque per fornire un workaround.

In genere il microcodice da aggiornare serve per fixare dei bug; questo è il motivo principale per cui ormai lo si può caricare all'avvio. In questo modo non serve far ritornare la CPU al venditore, e quest'ultimo non è costretto a rimettere le mani al progetto per fixare il bug, e attendere qualche altro mese per il tape-out della nuova revisione del processore.

Per bucare le sicurezze non credo occorrano più skill di quelli messi in campo dal vendor, a meno che a loro volta non si siano rivolti ad Intel per risolvere il problema.

Le skill non sono di proprietà esclusiva di Intel, anche se è chiaro che un ingegnere che lavora giornalmente sul microcodice è la persona più titolata a svolgere un lavoro di modifica in tempi rapidi.

Ma ciò non vuol dire che un'altra persona abbastanza skillata, seppur non a conoscenza di quei dettagli, non riesca a fare lo stesso (o a scoprire la natura di eventuali modifiche "maligne"), ovviamente impiegando molto più tempo.

Comunque sia, vista la prontezza della risposta giusto uguale ai tempi tecnici per evadere la domanda o di farina del loro sacco oppure per avermi girato la risposta di Intel,

Scusami, non ho capito: ti stai rivolgendo a me? Perché è bene che precisi che parlo esclusivamente a titolo personale.

certe cose le si prevede a mio avviso di default: il cliente può sempre avere la necessità di aggiornare il sistema, anche al di là delle compatibilità previste oppure (non) certificate.

Senz'altro, ed è per questo che è utile poter caricare il microcodice all'avvio, in modo da poterne utilizzare uno aggiornato. Ma per le motivazioni di cui sopra.

Allo stesso modo penso si possano bucare le sicurezze da parte di chi lo fa per mestiere e ha accesso a documentazioni non disponibili per tutti.

Che poi sia difficile farlo per l'ultimo degli sprovveduti che di un microcodice hanno solo la vaga idea di che cosa sia (io che scrivo ad esempio) non ho alcun dubbio in proposito.

Esatto, ma bisogna vedere se ha senso farlo e cosa si possa realisticamente realizzare.

Qualche cosa in assembler l'avevo ai tempi del Dos scritto anch'io, ma questo non faceva certo di me un esperto delle questioni trattate in questo thread, men che meno ho avuto mai bisogno di ricorrere a tali espedienti che nel dos era frequente la necessità di dover usare, ad esempio su quale porta dover indirizzare una stampante.
Oggi come oggi manco più mi ricordo né gli indirizzi delle porte e neppure quel poco che giocoforza avevo dovuto imparare dell'assembler, ma mi resta l'idea che forse tu la metti sul difficile, mentre per chi lo spionaggio elettronico lo fa per mestiere la cosa è senz'altro fattibile senza troppi sbattimenti: pure i chip tpm mi sembra abbiano bucato.

Questo non ricordo di averlo letto.

Comunque chi fa spionaggio per mestiere potrebbe anche essere un agente del neo-KGB che vuol verificare l'eventuale presenza di microcodice "malevolo", no?

Per il resto ne parlo ancora meglio dopo.

Originariamente inviato da LMCH

Difficile se non sei Intel.

Senz'altro è più facile per chi ci lavora, come dicevo prima, ma anche chi fa il reverse engineer di professione può riuscire a comprendere la struttura del microcodice (che in genere è molto più semplice rispetto alle normali istruzioni: siamo a un livello di astrazione più basso, e dobbiamo eseguire operazioni molto più basilari) e, dunque, accorgersi se quello caricato possa essere malevolo.

Basta solo che ci sia una falla sfruttabile (in questo caso inserita deliberatamente nel microcodice), non serve implementare chissà cosa.
E la sequenza di "attivazione" della falla anche se fa uso di istruzioni complesse non richiede che esse siano immediatamente consecutive (es: attivazione in due stadi) quindi sarebbe estremamente difficile da identificare come potenziale fonte di problemi.

Non per chi ne ha le capacità. Comunque ci sono alcune cose di cui non hai tenuto conto.

La prima è che fra un'istruzione che attiva un qualcosa prima, e un'altra che attiva qualcos'altro dopo, può benissimo verificarsi un context switch del processo correntemente eseguito, e dunque devi riuscire a preservare le informazioni "malevole" in qualche modo. Dovresti cercare qualche "buco" all'interno del context attuale che sia utilizzabile allo scopo senza sporcare il resto delle informazioni del processo corrente, oppure potrebbe servirti qualcosa di più generale e che "sopravviva" a qualunque cambio di thread. In entrambi i casi non è cosa facile.

Seconda cosa, dovresti organizzare le sequenze di istruzioni in modo che, eseguendo quelle cariche di microcodice malevolo, non facciano disastri se invocate in un ordine diverso, compromettendo il tutto e magari mettendo in luce l'esistenza di tale manipolazione.

Terza, come ho già detto prima, non hai il controllo assoluto di tutte le istruzioni che vengono eseguite. Se ti affidi a un compilatore non Intel potresti non generare mai le istruzioni malevole e/o non generarle mai nella correttezza sequenza.

Quarto e più importante, ma anche questo l'avevo scritto in precedenza, bisogna vedere se effettivamente hai a disposizione abbastanza spazio da poter infilare il microcodice malevolo all'interno di quello esistente (e che comunque non può essere compromesso, perché verrebbe meno il corretto funzionamento del processore, e la magagna salterebbe fuori).
I virus/trojan che fanno qualcosa di "utile" (utile a qualche losco figuro, intendo: trasmettere informazioni di qualche natura, ad esempio) non sono software banali che stanno in una manciata di byte; tutt'altro. Il micro-codice, tra l'altro, per sua natura dovrebbe essere molto più "cicciottello" di una normale istruzione, perché immagino che debba avere una dimensione fissa (altrimenti gestirlo non sarebbe affatto facile) e contenente una serie di indicazioni sulle operazioni basilari da eseguire e i vari segnali da gestire; questa è l'idea che mi sono fatto, ma non sono esperto in materia. Poiché il microcodice esegue piccole operazioni basilari, va da sé che realizzare qualcosa di malevolo richieda di gran lunga più spazio rispetto a quello che serve a un virus che esegue normali istruzioni. Siccome immagino che lo spazio per contenere il microcodice all'interno del processore sia ridotto, dove la metti tutta questa roba malevola?

Ultima cosa, non credo che Intel s'impelaghi in operazioni del genere. Se fosse scoperta l'impatto mediatico sarebbe tremendo, e potrebbe anche chiudere i battenti.

Per cui, e concludo, personalmente ritengo che sia estremamente improbabile che si possa sfruttare il microcodice per scopi malevoli.

[massimo79m]

Originariamente inviato da M47AMP

Che poi i server linux non abbiano lo stesso indotto dei server Microsoft è fuori discussione: Windows Server ha intorno a se un ecosisistema che gli altri solo si sognano di poter avvicinare.

ah, si? beh, parlami di questo "ecosistema" che windows ha e unix no.
sono tutt'orecchi, visto che windows e' PC, mentre linux/unix viaggiano su TUTTO, dai tablet al mainframe, in tutti i campi.

Originariamente inviato da M47AMP

Ma per certe necessità, per così dire basiche, Linux e Unix vanno alla grande, pur se perfino IBM in questo tipo di mercato è venuta a trovarsi in ristrettezze.

basiche come mainframe, server web,mail, sql, cloud, application (e continuiamo pure con la lista), supercomputer?

mi sa che non hai idea di cosa sia linux, e siamo nel 2014, non e' proprio una novita'.

[cdimauro]

Originariamente inviato da M47AMP

http://www.hwupgrade.it/forum/showthread.php?t=2142962

Quando vai a effettuare reverse engineering andando a guardare a livello dei transistor, c'è ben poco da fare...

Originariamente inviato da M47AMP

Inoltre esiste un contenzioso fra Cina ed Usa (oppure è esistito) nel quale gli USA accusano oppure accusavano Huawei di fornire router col buco.
Penso che la Cina dirà o ha già detto la stessa cosa di Cisco.

E possibile. Comunque a questi livelli è più semplice: un bel po' di spazio per codice maligno dentro un firmware lo si trova il modo d'infilarlo, oltre a pensare come mimetizzarlo.

[DukeIT]

Splendida notizia, fuori X86 e fuori Windows, chissà che da cosa nasca cosa e si cominci a vedere qualcosa di diverso.

[LMCH]

Originariamente inviato da cdimauro

Quando vai a effettuare reverse engineering andando a guardare a livello dei transistor, c'è ben poco da fare...

Questo se ipotizzi solo una modifica hardware, mentre nel caso degli x86 il vettore ideale è microcodice "con qualche bug utile" (sfruttabile in seguito da software che potrebbe essere eseguito su quel dispositivo).

Inoltre esistono tecniche per contrastare il reverse engineering a livello di transistor basate sulla presenza di circuiti ridondanti ... che non sono ridondanti, oppure anche mascherando come chip art qualcosa che in modo molto inefficiente fa anche dell'altro.

Per questo se uno vuole essere sicuro di quello che ha, deve avere il controllo sul layout (nel senso di produrre da se o farselo produrre secondo un progetto specifico verificabile), altrimenti bisognerebbe fare continui reverse engineering per evitare che qualche revisione delle maschere includa anche qualche sorpresa indesiderata.

[cdimauro]

OK per l'hardware, ma per il microcodice mi sono già ampiamente espresso: il fatto di poterlo modificare non vuol dire che lo si possa realmente sfruttare per introdurre codice malevolo.

[Cybermanu]

Neanche Berlusconi avrebbe potuto fare di peggio...

[randorama]

speriamo non ci colleghino i sistemi di lancio delle testate nucleari...