Un bug hardware affligge la memoria virtuale delle CPU Intel

[maxsin72]

Originariamente inviato da s-y

se davvero hanno smesso di rendere disponibili 'separatamente' i microcode non mi pare una gran mossa, anche se ormai l'hype si è affievolito e non frega più niente a nessuno

Nuovi microcode ufficiali https://support.microsoft.com/en-au/...rocode-updates disponibili sia via software su windows 10 che da scaricare seguendo le istruziondi intel qui https://downloadmirror.intel.com/287...ode_readme.txt oppure direttamente da qui https://github.com/intel/Intel-Linux...0190312.tar.gz

[s-y]

anche su pinguino, almeno sulla arch è (era, a fine marzo) stato aggiornato il package
https://www.archlinux.org/packages/e...y/intel-ucode/

[maxsin72]

Qualche test sulle VM https://www.ict-r.com/the-impact-of-...h-environment/

[xxxyyy]

Originariamente inviato da maxsin72

Nuovi microcode ufficiali https://support.microsoft.com/en-au/...rocode-updates disponibili sia via software su windows 10 che da scaricare seguendo le istruziondi intel qui https://downloadmirror.intel.com/287...ode_readme.txt oppure direttamente da qui https://github.com/intel/Intel-Linux...0190312.tar.gz

Ma Intel e' ferma all'8 Agosto dell'anno scorso con la revision guidance... oppure sono io che non trovo quella piu' recente?

[maxsin72]

Originariamente inviato da xxxyyy

Ma Intel e' ferma all'8 Agosto dell'anno scorso con la revision guidance... oppure sono io che non trovo quella piu' recente?

Per revision guidance intendi quella che segue? https://downloadcenter.intel.com/it/...sore-di-Linux-

Pacchetto di microcodice del processore Intel per Linux *

Il microcodice della CPU è un meccanismo per correggere alcuni errata nei sistemi esistenti.
Il metodo preferito normale per applicare gli aggiornamenti del microcodice è utilizzare il sistema
BIOS, ma per un sottoinsieme di Processori Intel questo può essere fatto in fase di esecuzione
utilizzando il sistema operativo. Questo pacchetto contiene i Processori che
Supporto Caricamento del sistema operativo degli aggiornamenti del microcodice.

Gli utenti di destinazione per questo pacchetto sono fornitori di sistemi operativi come le distribuzioni Linux
per l'inclusione nelle loro versioni del sistema operativo. Intel consiglia di ottenere il microcodice
utilizzando il meccanismo di aggiornamento del fornitore del sistema operativo. Gli utenti esperti possono naturalmente aggiornare i loro
microcodice direttamente al di fuori del meccanismo del fornitore del sistema operativo. Questo metodo è complesso e
quindi potrebbe essere soggetto a errori.

Il microcodice è meglio caricato dal BIOS. Alcuni microcodici devono essere applicati solo
dal BIOS. Tali aggiornamenti del microcodice del processore non sono mai confezionati in questo
Poiché non sono appropriati per la distribuzione del sistema operativo. Un OEM può ricevere
pacchetti di microcodici che potrebbero essere un superset di ciò che è contenuto in questo
Pacchetto.

I fornitori di sistemi operativi possono scegliere di aggiornare anche il microcodice che il kernel può consumare per primi
Caricamento. Ad esempio, Linux può aggiornare il microcodice del processore molto presto nel kernel
sequenza di avvio. In situazioni in cui l'aggiornamento del BIOS non è disponibile, il caricamento anticipato
è la prossima migliore alternativa all'aggiornamento del microcodice del processore. Stati del microcodice
vengono resettati su un reset di potenza; Pertanto, è necessario aggiornare ogni volta
processo di avvio.

È consigliabile caricare il microcodice utilizzando il metodo initrd in modo che il microcodice
viene caricata al più presto per una migliore copertura. Sistemi che non tollerano
può utilizzare il metodo di ricarica tardiva per aggiornare un sistema in esecuzione senza
Riavviare.

= = Informazioni su firma del processore, famiglia, modello, passo e ID piattaforma = =
La firma del processore è un numero che identifica il modello e la versione di un
Processore Intel. Può essere ottenuta utilizzando l'istruzione CPUID e può
anche essere ottenuta tramite il comando lscpu o dal contenuto di/proc/cpuinfo.
Di solito è presentato come 3 campi: famiglia, modello e stepping
(Nella tabella degli aggiornamenti di seguito, sono abbreviati come F, MO e S).

La larghezza della famiglia/modello/stepping è di 12/8/4 bit, ma quando
i dati grezzi della firma del processore a 32 bit sono come 0FFM0FMS, esadecimale.
ad esempio, se una firma del processore è 0x000906eb, significa
Famiglia = 0x006, modello = 0x9E e stepping = 0xb

Un prodotto del processore può essere implementato per più tipi di piattaforme,
quindi in MSR (17H), i Processori Intel hanno un campo ID piattaforma a 3 bit
che può specificare un tipo di piattaforma da un massimo di 8 tipi.
Un file di microcodice per un modello di processore specificato può Supporto più
piattaforme, quindi l'ID piattaforma di un microcodice (abbreviare come PI nella tabella)
è una maschera a 8 bit, ogni bit impostato indica un tipo di piattaforma supportato.
Si può trovare l'ID della piattaforma su Linux utilizzando RDMSR da MSR-Tools.

= = Istruzioni per l'aggiornamento del microcodice = =
--Intel-ucode/--
la directory Intel-ucode contiene file di microcodice binari denominati in
modello di passo della famiglia. Il file è supportato nella maggior parte dei moderni sistemi Linux
Distribuzioni. Si trova generalmente nella directory/lib/firmware,
e può essere aggiornato tramite l'interfaccia di ricarica microcodice.

Per aggiornare initrd di caricamento anticipato, consulta la tua distribuzione su come confezionare
file di microcodice per il caricamento anticipato. Alcune distribuzioni utilizzano update-initramfs o Dracut.
Come raccomandato sopra, si prega di utilizzare i fornitori del sistema operativo sono raccomandati metodo per garantire
il file di microcodice viene aggiornato per il caricamento anticipato prima di tentare il caricamento tardivo
procedura riportata di seguito.

Per aggiornare il pacchetto Intel-ucode al sistema, è necessario:
1. verificare l'esistenza di/sys/devices/System/CPU/microcode/reload
2. copiare la directory Intel-ucode in/lib/firmware, sovrascrivere i file
/lib/firmware/Intel-ucode/
3. scrivere l'interfaccia reload su 1 per ricaricare i file di microcodice, ad esempio,
echo 1 >/sys/devices/System/CPU/microcode/reload

Se si utilizza il metodo del fornitore del sistema operativo per aggiornare il microcodice, i passaggi precedenti potrebbero
sono state eseguite automaticamente durante il processo di aggiornamento.

--Intel-ucode-con-caveats/--
Questa directory contiene il microcodice che potrebbe essere necessario un trattamento speciale.
Il microcodice BDX-ML è fornito in directory, perché necessita di commit speciali
il kernel Linux, in caso contrario, l'aggiornamento potrebbe comportare un sistema imprevisto
Comportamento.
I fornitori di sistemi operativi devono assicurarsi che le patch del caricatore
Linux-kernel-patches \) sono inclusi nella distribuzione prima di confezionare il
Microcodice BDX-ML per il caricamento tardivo.

= = 20190312 rilascio = =
--Aggiornamenti su 20180807 Release--
Versione identificatore del processore prodotti
Modello stepping F-MO-S/PI vecchio-> nuovo
----nuove piattaforme----------------------------------------
AML-Y22 H0 6-8e-9/10 0000009e nucleo Gen8 mobile
WHL-U W0 6-8E-b/D0 000000a4 Core Gen8 mobile
WHL-U V0 6-8E-d/94 000000b2 Core Gen8 mobile
CFL-S P0 6-9E-c/22 000000a2 Core Gen9 desktop
CFL-H r0 6-9E-d/22 000000B0 nucleo Gen9 mobile
----piattaforme aggiornate------------------------------------
HSX-E/EP CX/M1 6-3F-2/6F 0000003d-> 00000041 Core Gen4 X serie; Xeon E5 V3
HSX-EX E0 6-3F-4/80 00000012-> 00000013 Xeon E7 V3
SKX-SP H0/M0/U0 6-55-4/B7 0200004d-> 0000005a Xeon scalabile
SKX-D M1 6-55-4/B7 0200004d-> 0000005a Xeon D-21xx
BDX-DE V1 6-56-2/10 00000017-> 00000019 Xeon D-1520/40
BDX-DE V2/3 6-56-3/10 07000013-> 07000016 Xeon D-1518/19/21/27/28/31/33/37/41/48, Pentium D1507/08/09/17/19
BDX-DE y0 6-56-4/10 0f000012-> 0f000014 Xeon D-1557/59/67/71/77/81/87
BDX-NS a0 6-56-5/10 0e00000a-> 0e00000c Xeon D-1513N/23/33/43/53
APL D0 6-5C-9/03 00000032-> 00000036 Pentium N/J4xxx, Celeron N/J3xxx, Atom X5/7-E39xx
APL E0 6-5C-a/03 0000000c-> 00000010 Atom X5/7-E39xx
GLK B0 6-7a-1/01 00000028-> 0000002c Pentium argento N/J5xxx, Celeron N/J4xxx
KBL-U/Y H0 6-8e-9/C0 0000008E-> 0000009a nucleo GEN7 mobile
CFL-U43e D0 6-8E-a/C0 00000096-> 0000009e nucleo Gen8 mobile
KBL-H/S/E3 B0 6-9E-9/2a 0000008E-> 0000009a nucleo Gen7; Xeon E3 V6
CFL-H/S/E3 U0 6-9E-a/22 00000096-> 000000AA Core Gen8 desktop, mobile, Xeon E
CFL-S B0 6-9E-b/02 0000008E-> 000000AA Core Gen8

In ogni caso mi sono accorto che la versione del microcode del mio 4790k è sempre la stessa dello scorso anno e in realtà non è stata aggiornata.

[Nui_Mg]

Altro "ma chi..., ma come..., ma chi cazzo..." per Intel.

Sìori e sìore, ZombieLoad...

Proci by amd sembrerebbero immuni.

[s-y]

in pratica il fix è disabilitare l'ht
mi torna sempre in mente quel post di qualche mese fa dal team di openbsd (o altra bsd), che dichiarava che per scarsità di mezzi preferivano seccare l'ht direttamente da kernel

chissà se alla fine del guado si avrà un conto totale del costo sulle prestazioni delle varie 'pandore'

[maxsin72]

Originariamente inviato da Nui_Mg

Altro "ma chi..., ma come..., ma chi cazzo..." per Intel.

Sìori e sìore, ZombieLoad...

Proci by amd sembrerebbero immuni.

Pare che AMD abbia confermato di essere immune a Zombieload https://tech.everyeye.it/notizie/amd...ad-377892.html

E già mi viene in mente un simpatico utente che parlava di 3 lustri di domino intel in un altro thread...

[Varg87]

Manca poco.

[maxsin72]

E forse si spiega anche perchè sulla nona generazione desktop intel abbia segato via l'HT con l'eccezione del 9900k e del 9900.

[maxsin72]

Originariamente inviato da maxsin72

E forse si spiega anche perchè sulla nona generazione desktop intel abbia segato via l'HT con l'eccezione del 9900k e del 9900.

Mi autoquoto e mi correggo: pare che intel abbia già implementato i fix hardware nelle cpu di nona generazione. Comunque è davvero un bel macello

[cdimauro]

Originariamente inviato da Nui_Mg

Altro "ma chi..., ma come..., ma chi cazzo..." per Intel.

Sìori e sìore, ZombieLoad...

"The safest workaround to prevent this extremely powerful attack is running trusted and untrusted applications on different physical machines"

Che ripeto da quando sono venute fuori queste falle di sicurezza.

Proci by amd sembrerebbero immuni.

Anche ARM, a quanto pare. Ma di ARM ce sono parecchie varianti: bisognerebbe testarli tutti.

Originariamente inviato da s-y

in pratica il fix è disabilitare l'ht
mi torna sempre in mente quel post di qualche mese fa dal team di openbsd (o altra bsd), che dichiarava che per scarsità di mezzi preferivano seccare l'ht direttamente da kernel

Non serve disabilitare l'HT, perché la vulnerabilità rimarrebbe ugualmente, anche se sarebbe molto mitigata.

chissà se alla fine del guado si avrà un conto totale del costo sulle prestazioni delle varie 'pandore'

Servono i test per questo. Ma con applicazioni reali, e non benchmark sintetici.

Originariamente inviato da maxsin72

Pare che AMD abbia confermato di essere immune a Zombieload https://tech.everyeye.it/notizie/amd...ad-377892.html

E già mi viene in mente un simpatico utente che parlava di 3 lustri di domino intel in un altro thread...

Ti viene in mente a sproposito. Come al solito.

Originariamente inviato da maxsin72

E forse si spiega anche perchè sulla nona generazione desktop intel abbia segato via l'HT con l'eccezione del 9900k e del 9900.

Intel non ha segato affatto l'HT, che rimane in parecchi suoi processori.

Originariamente inviato da maxsin72

Mi autoquoto e mi correggo: pare che intel abbia già implementato i fix hardware nelle cpu di nona generazione. Comunque è davvero un bel macello

O che peccato, ma quanto ti dispiace non poter continuare a infangare Intel, vero?

Almeno Intel ha presentato processori con mitigazioni hardware. E sta pure investendo sulla ricerca di falle di sicurezza (quest'ultima è stata individuata indipendentemente anche dal suo staff).

Altri produttori di processori non mi sembra che abbiano fatto lo stesso, sebbene sia ormai passato parecchio da quando sono saltati fuori Meltdown e Spectre...

[maxsin72]

Originariamente inviato da cdimauro

Ti viene in mente a sproposito. Come al solito.

Intel non ha segato affatto l'HT, che rimane in parecchi suoi processori.

O che peccato, ma quanto ti dispiace non poter continuare a infangare Intel, vero?

Infangare intel ma no mai, è perfetta, ha dominato per 3 lustri
E poi certo sugli I7 l'HT era su tutte le cpu mentre sugli I9 solo sui 9900, no ma non lo ha segato... e no e intel brava bella buona

Originariamente inviato da cdimauro

Almeno Intel ha presentato processori con mitigazioni hardware. E sta pure investendo sulla ricerca di falle di sicurezza (quest'ultima è stata individuata indipendentemente anche dal suo staff).

Altri produttori di processori non mi sembra che abbiano fatto lo stesso, sebbene sia ormai passato parecchio da quando sono saltati fuori Meltdown e Spectre...

AMD ha fatto di meglio: ha progettato cpu immuni a meltdown, ad alcune varianti di spectre e a zombieload a monte, cosa che mi fa pensare che la tua cara intelluccia che domina da 3 lustri non si sia fatta molti problemi sulla sicurezza pur di spingere sulle performance, ora, tardivamente, si stanno muovendo e la scelta fatta su Keller mi sembra quantomai significativa. Pare poi che le mitigazioni hardware di intel su meltdown rendano addirittura più vulnerabili le nuove cpu alle nuove criticità rispetto alle vecchie ccpu intel, siamo al tragicomico

Riporto dal thread su zombieload

Originariamente inviato da mik91

Our attacks affect all modern Intel CPUs in servers, desktops and laptops. This includes the latest 9th-generation processors, despite their in-silicon mitigations for Meltdown. Ironically, 9th-generation CPUs are more vulnerable to some of our attacks compared to older generation hardware.

Stando ai ricercatori che hanno scoperto la falla sono vulnerabili anche le ultime architetture.

Originariamente inviato da mik91

https://mdsattacks.com/

[Varg87]

Originariamente inviato da cdimauro

[i][indent]
Almeno Intel ha presentato processori con mitigazioni hardware. E sta pure investendo sulla ricerca di falle di sicurezza (quest'ultima è stata individuata indipendentemente anche dal suo staff).

Altri produttori di processori non mi sembra che abbiano fatto lo stesso, sebbene sia ormai passato parecchio da quando sono saltati fuori Meltdown e Spectre...

O forse lo stanno facendo ma non trovano niente.

https://www.youtube.com/watch?v=GwD3drkSU6U

[cdimauro]

Originariamente inviato da maxsin72

Infangare intel ma no mai, è perfetta,

Mai detto questo: stai mistificando. Come tuo solito, quando non sai sostenere una discussione.

ha dominato per 3 lustri

Già. Ma ti ho già risposto nell'altro thread.

E poi certo sugli I7 l'HT era su tutte le cpu mentre sugli I9 solo sui 9900, no ma non lo ha segato...

https://en.wikipedia.org/wiki/List_o..._Lake-S_(14_nm)
https://en.wikipedia.org/wiki/List_o..._Lake-H_(14_nm)

e no e intel brava bella buona

Mai detto questo, e continui a mistificare. D'altra parte non ti rimane altro.

AMD ha fatto di meglio: ha progettato cpu immuni a meltdown, ad alcune varianti di spectre e a zombieload a monte,

Falso, visto che queste vulnerabilità non erano affatto note quando Zen è stato progettato.

cosa che mi fa pensare che la tua cara intelluccia che domina da 3 lustri non si sia fatta molti problemi sulla sicurezza pur di spingere sulle performance,

Argomento già trattato qui, e pure il link dei ricercatori (che TU STESSO hai riportato) ti smentisce.

Ma sappiamo che hai la memoria molto corta.

ora, tardivamente, si stanno muovendo

Veramente Intel è l'UNICA a muoversi: gli produttori di processori, AMD inclusa, non hanno ancora fornito nessuna mitigazione hardware, nemmeno dopo tutto questo tempo.

e la scelta fatta su Keller mi sembra quantomai significativa.

Che non c'entra nulla.

Pare poi che le mitigazioni hardware di intel su meltdown rendano addirittura più vulnerabili le nuove cpu alle nuove criticità rispetto alle vecchie ccpu intel, siamo al tragicomico

Riporto dal thread su zombieload

Hai dimenticato di riportare anche questo:

"Io ho letto (non ricordo più dove) che quelli vulnerabili sono le cpu dal 2011 in avanti, incluso anche il 9900K che non ha il fix in hardware perché facente parte del più "vecchio" step 12 (Intel64 Family 6 Model 158 Stepping 12), mentre ce l'hanno i proci di nona generazione con stepping 13, di più nin zo "

[cdimauro]

Originariamente inviato da Varg87

O forse lo stanno facendo ma non trovano niente.

Nessun produttore di processore è esente da falle di sicurezza.

Quindi, sì: non stanno facendo niente per fissarle.

Intel è l'unica che finora s'è mossa.

[maxsin72]

Originariamente inviato da cdimauro

Mai detto questo: stai mistificando. Come tuo solito, quando non sai sostenere una discussione.

Già. Ma ti ho già risposto nell'altro thread.

https://en.wikipedia.org/wiki/List_o..._Lake-S_(14_nm)
https://en.wikipedia.org/wiki/List_o..._Lake-H_(14_nm)

Anche io ti ho risposto nell'altro thread e hai sbagliato, poi per gli I7 come per gli I9 è ovvio che mi riferissi alle cpu desktop mainstream ma ovviamente fai finta di non capire come tuo solito

Originariamente inviato da cdimauro

Mai detto questo, e continui a mistificare. D'altra parte non ti rimane altro.

Non serve che tu lo dica esplicitamente, emerge di continuo dal tuo atteggiamento

Originariamente inviato da cdimauro

Falso, visto che queste vulnerabilità non erano affatto note quando Zen è stato progettato.

Argomento già trattato qui, e pure il link dei ricercatori (che TU STESSO hai riportato) ti smentisce.

Ma sappiamo che hai la memoria molto corta.

Addirittura ti riferisci a te stesso usando il noi, non sarai mica un po' megalomane E una volta di più fai finta di non capire: appunto perchè Zen è stato progettato quando tutte queste vulnerabilità non erano conosciute e, nonostante questo, è immune alla maggior parte di esse vuol dire che Keller ha fatto un lavoro migliore della controparte intel che adesso se lo è acchiappato.

Originariamente inviato da cdimauro

Veramente Intel è l'UNICA a muoversi: gli produttori di processori, AMD inclusa, non hanno ancora fornito nessuna mitigazione hardware, nemmeno dopo tutto questo tempo.

Che non c'entra nulla.

Non mi pare che la situzione di AMD sia più critica di quella di intel, semmai il contrario

Originariamente inviato da cdimauro

Hai dimenticato di riportare anche questo:

"Io ho letto (non ricordo più dove) che quelli vulnerabili sono le cpu dal 2011 in avanti, incluso anche il 9900K che non ha il fix in hardware perché facente parte del più "vecchio" step 12 (Intel64 Family 6 Model 158 Stepping 12), mentre ce l'hanno i proci di nona generazione con stepping 13, di più nin zo "

Cosa faccio, riporto una notizia dove l'utente non si ricorda dove l'ha letta oppure una notizia con il link al sito ufficiale di chi ha verificato le vulnerabilità? Scommetto che tu non hai dubbi: si riporta sempre la notizia favorevole a intel indipendentemente dalla fonte, ovvio no?

[cdimauro]

Originariamente inviato da maxsin72

Anche io ti ho risposto nell'altro thread e hai sbagliato, poi per gli I7 come per gli I9 è ovvio che mi riferissi alle cpu desktop mainstream ma ovviamente fai finta di non capire come tuo solito

E' ovvio per te, ma se Intel non starebbe puntando più sull'HT, perché continuerebbe sfornare diversi processori che lo usano?

Non serve che tu lo dica esplicitamente, emerge di continuo dal tuo atteggiamento

Detto da te che hai problemi di logica e di memoria...

Addirittura ti riferisci a te stesso usando il noi, non sarai mica un po' megalomane

Dalla treccani: Megalomane

A quanto pare difetti anche nella lingua italiana. Come dicevo, non ti fai mancare proprio nulla.

E una volta di più fai finta di non capire: appunto perchè Zen è stato progettato quando tutte queste vulnerabilità non erano conosciute e, nonostante questo, è immune alla maggior parte di esse vuol dire che Keller ha fatto un lavoro migliore della controparte intel

Peccato che anche Zen è, per l'appunto, affetto da certe vulnerabilità.

E non è questione di fare un lavoro migliore o peggiore: quando si sono realizzati questi processori TUTTI i produttori di processori prendevano a piene mani dalla letteratura in merito.

Mica si sapeva che avrebbero potuto genere queste problematiche.

Dunque questi confronti che fai sono, ancora una volta, totalmente insensati.

Ma di questo ne abbiamo già ampiamente parlato proprio qui.

che adesso se lo è acchiappato.

Keller NON è un esperto di sicurezza dei processori, quindi Intel non se l'è preso per questo, ma per le sue competenze micro-architetturali.

Non mi pare che la situzione di AMD sia più critica di quella di intel, semmai il contrario

Che non c'entra nulla con quello che avevo detto.

Infatti non hai nemmeno risposto.

Cosa faccio, riporto una notizia dove l'utente non si ricorda dove l'ha letta oppure una notizia con il link al sito ufficiale di chi ha verificato le vulnerabilità? Scommetto che tu non hai dubbi: si riporta sempre la notizia favorevole a intel indipendentemente dalla fonte, ovvio no?

Se avessi letto per bene l'articolo riportato (cosa che a te NON interessa, perché l'unico motivo per cui scrivi è polemizzare), avresti trovato delle informazioni in merito.

Non lo stepping del processore (che non so dove l'abbia preso Nui_Mg), ma l'informazione c'è.

Adesso vediamo se riesci a fare qualcosa di buono e utile al thread, e recuperi ciò a cui mi riferisco.

[s-y]

Originariamente inviato da cdimauro

Non serve disabilitare l'HT, perché la vulnerabilità rimarrebbe ugualmente, anche se sarebbe molto mitigata.

uhm, ok

[maxsin72]

Originariamente inviato da cdimauro

E' ovvio per te, ma se Intel non starebbe puntando più sull'HT, perché continuerebbe sfornare diversi processori che lo usano?

Quindi il 9900k con HT va uguale al 9700K senza HT? E quindi toglieranno l'HT anche dagli Xeon, solo questi sprovveduti di AMD continuaranno ad avere l'SMT Inventane un'altra cortesemente

Originariamente inviato da cdimauro

Detto da te che hai problemi di logica e di memoria...

Io, eh? ma i lustri che avevi scrittto erano 3 o 5? Ti rispondo io: erano 3 e avevo ragione io e torto tu,

Originariamente inviato da cdimauro

Dalla treccani: Megalomane

A quanto pare difetti anche nella lingua italiana. Come dicevo, non ti fai mancare proprio nulla.

Grazie per avermelo confermato ma sapevo già di aver utilizzato il termine giusto con "voi" (uso il plurale come hai fatto per primo tu riferendoti a te stesso)

Originariamente inviato da cdimauro

Peccato che anche Zen è, per l'appunto, affetto da certe vulnerabilità.

E non è questione di fare un lavoro migliore o peggiore: quando si sono realizzati questi processori TUTTI i produttori di processori prendevano a piene mani dalla letteratura in merito.

Mica si sapeva che avrebbero potuto genere queste problematiche.

Dunque questi confronti che fai sono, ancora una volta, totalmente insensati.

Ma di questo ne abbiamo già ampiamente parlato proprio qui.

Zen ha delle falle mentre intel è un colabrodo basta vedere il numero di criticità che riguardano ciascuno, ergo la scelta più "sicura" ad oggi è AMD

Originariamente inviato da cdimauro

Keller NON è un esperto di sicurezza dei processori, quindi Intel non se l'è preso per questo, ma per le sue competenze micro-architetturali.

Può essere, ma il dato di fatto è che Zen progettato da Keller ha molte meno criticità della controparte intel

Originariamente inviato da cdimauro

Che non c'entra nulla con quello che avevo detto.

Infatti non hai nemmeno risposto.

Se avessi letto per bene l'articolo riportato (cosa che a te NON interessa, perché l'unico motivo per cui scrivi è polemizzare), avresti trovato delle informazioni in merito.

Ho perso il conto delle cose a cui non hai risposto

Originariamente inviato da cdimauro

Non lo stepping del processore (che non so dove l'abbia preso Nui_Mg), ma l'informazione c'è.

Adesso vediamo se riesci a fare qualcosa di buono e utile al thread, e recuperi ciò a cui mi riferisco.

Quando scrivo qualcosa specifico sempre i miei riferimenti, per i riferimenti di quello che scrivi tu ti chiedo cortesemente di provvedere tu stesso.