le discordanze tra i 2 test sono esigue e sicuramente non determinate dal microcode

Sí, probabile. Di certo non migliora le prestazioni.

Ho visto qualche ora fa che è uscito un nuovo microcode per il mio 3570K datato 13 febbraio 2019. L'ho implementato nel BIOS ma non sembra essere cambiato niente, anzi, sembra peggiorare anche se di poco (ho eseguito solo un giro di test con entrambi i microcode quindi ci potrebbe essere un errore di misurazione, anche se effettuato a parità di condizioni e con sistema in idle).

Con il microcode rev.20 (10/04/2018):

https://i.postimg.cc/Kk4DVqYZ/Crystal-pre.png (https://postimg.cc/Kk4DVqYZ) https://i.postimg.cc/3kKpVSLP/samsung-pre.png (https://postimg.cc/3kKpVSLP)

Con il microcode rev.21 (13/02/2019):

https://i.postimg.cc/w3phDjXq/Crystal-post.png (https://postimg.cc/w3phDjXq) https://i.postimg.cc/xkmzbwqN/samsung-post.png (https://postimg.cc/xkmzbwqN)

Non ho trovato traccia di changelog.

PS Non è l'unico ad aver ricevuto aggiornamenti. Anche per l'i3 6100 c'è un nuovo microcode datato febbraio 2019.

Ciao, hai il link per il download dei microcode? Sul sito ufficiale intel c'è ancora il file di luglio 2018. Ti ringrazio :)

Lo ha trovato UBU. Infatti è strano che non ce ne sia traccia.

Lo ha trovato UBU. Infatti è strano che non ce ne sia traccia.

In questi casi, anche se UBU credo sia affidabile, credo sia meglio attendere il rilascio ufficiale di intel.

C'hai anche ragione. Trovo strano pure che siano spariti tutti i changelog da Winraid riguardanti UBU. Fino a poco tempo fa venivano inseriti anche eventuali microcode, ora non c'è più nulla. :stordita:
EDIT In realtà sembra siano stati spostati per mantenere pulita la pagina.
Trovato ma non c'è traccia del microcode. Boh.

per quel che vale idem su pinguino (manjaro, arch based quindi aggiornata)


extra/intel-ucode 20180807.a-1 (1.3 MiB 1.7 MiB)
Microcode update files for Intel CPUs

c'è qualcosa in aur (il repo diciamo non strettamente ufficiale) ma non ho indagato cosa/come, anche perchè non sono più su intel

btw quello amd è più avanti:


core/amd-ucode 20190313.efd2c1c-1 (23.2 KiB 59.0 KiB) (Installed)
Microcode update files for AMD CPUs

ps: ci faccio caso ora, curioso il fatto che siano su due repo diversi (dai nomi abbastanza indicativi)

Comunque sia

https://i.postimg.cc/gx3Mqdd9/Cattura.png (https://postimg.cc/gx3Mqdd9) https://i.postimg.cc/8sPP2PnH/Cattura2.png (https://postimg.cc/8sPP2PnH)

Questo è quello che trova per l'i3 6100, che non ho aggiornato:

https://i.postimg.cc/Mc2ns75q/Cattura.png (https://postimg.cc/Mc2ns75q) https://i.postimg.cc/HVrjdZPT/Cattura2.png (https://postimg.cc/HVrjdZPT)

https://www.askwoody.com/2019/more-intel-microcode-updates-released-through-the-update-catalog/

NB Ultimo commento.

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

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/help/4465065/kb4465065-intel-microcode-updates disponibili sia via software su windows 10 che da scaricare seguendo le istruziondi intel qui https://downloadmirror.intel.com/28727/eng/Intel-Linux_Processor_Microcode_readme.txt oppure direttamente da qui https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/archive/microcode-20190312.tar.gz

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

Qualche test sulle VM https://www.ict-r.com/the-impact-of-spectre-meltdown-and-l1tf-in-a-virtualized-rdsh-environment/

Nuovi microcode ufficiali https://support.microsoft.com/en-au/help/4465065/kb4465065-intel-microcode-updates disponibili sia via software su windows 10 che da scaricare seguendo le istruziondi intel qui https://downloadmirror.intel.com/28727/eng/Intel-Linux_Processor_Microcode_readme.txt oppure direttamente da qui https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/archive/microcode-20190312.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?

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/download/28727/File-di-dati-del-microcodice-del-processore-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.

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

Sìori e sìore, ZombieLoad (https://www.bankinfosecurity.com/intels-zombieload-fix-may-slow-processors-by-19-percent-a-12484)...

Proci by amd sembrerebbero immuni.

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'

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

Sìori e sìore, ZombieLoad (https://www.bankinfosecurity.com/intels-zombieload-fix-may-slow-processors-by-19-percent-a-12484)...

Proci by amd sembrerebbero immuni.

Pare che AMD abbia confermato di essere immune a Zombieload https://tech.everyeye.it/notizie/amd-rassicura-utenti-i-prodotti-sicuro-zombieload-377892.html

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

Manca poco. :O

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

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 :mad:

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

Sìori e sìore, ZombieLoad (https://www.bankinfosecurity.com/intels-zombieload-fix-may-slow-processors-by-19-percent-a-12484)...
"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.
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.
Pare che AMD abbia confermato di essere immune a Zombieload https://tech.everyeye.it/notizie/amd-rassicura-utenti-i-prodotti-sicuro-zombieload-377892.html

E già mi viene in mente un simpatico utente che parlava di 3 lustri di domino intel in un altro thread...:asd:
Ti viene in mente a sproposito. Come al solito.
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.
Mi autoquoto e mi correggo: pare che intel abbia già implementato i fix hardware nelle cpu di nona generazione. Comunque è davvero un bel macello :mad:
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...

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 :asd:
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 :asd:


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 :asd:

Riporto dal thread su zombieload


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.

https://mdsattacks.com/
:read:

[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. :ciapet:

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

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 :asd:
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_of_Intel_Core_i9_microprocessors#Coffee_Lake-S_(14_nm)
https://en.wikipedia.org/wiki/List_of_Intel_Core_i9_microprocessors#Coffee_Lake-H_(14_nm)
e no e intel brava bella buona :asd:
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 :asd:

Riporto dal thread su zombieload

:read:
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 "

O forse lo stanno facendo ma non trovano niente. :ciapet:
Nessun produttore di processore è esente da falle di sicurezza.

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

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

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_of_Intel_Core_i9_microprocessors#Coffee_Lake-S_(14_nm)
https://en.wikipedia.org/wiki/List_of_Intel_Core_i9_microprocessors#Coffee_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


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

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


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


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? :asd:

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... :rotfl:
Addirittura ti riferisci a te stesso usando il noi, non sarai mica un po' megalomane :asd: :asd: :asd:
Dalla treccani: Megalomane (http://treccani.it/vocabolario/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? :asd:
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.

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


uhm, ok

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 :asd: Inventane un'altra cortesemente


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

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


Dalla treccani: Megalomane (http://treccani.it/vocabolario/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" :asd: (uso il plurale come hai fatto per primo tu riferendoti a te stesso)


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


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


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


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.

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 :asd: Inventane un'altra cortesemente
Ma chi ha detto Intel toglierà l'HT?!? Hai completamente ribaltato il discorso!
Io, eh? ma i lustri che avevi scrittto erano 3 o 5? Ti rispondo io: erano 3 e avevo ragione io e torto tu, :asd:
https://www.hwupgrade.it/forum/showpost.php?p=46216560&postcount=27
"è da circa 3 lustri che i sorci rossi li vede AMD con le micro-architetture che ha sviluppato Dadi "

Il 5 m'è scappato DOPO, nel commento che ho scritto PRIMA di andare a letto, ed era soltanto un refuso.

Ma vedo che continui ad aggrapparti a questa sciocchezza con le unghie e i denti: si vede che non ti rimane altro.
Grazie per avermelo confermato ma sapevo già di aver utilizzato il termine giusto con "voi" :asd: (uso il plurale come hai fatto per primo tu riferendoti a te stesso)
Vabbé, che tu non sappia leggere è cosa conclamata ormai...
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
E di nuovo hai totalmente cambiato discorso, con una cosa che non c'entra nulla su quello che avevo scritto. Tanto per cambiare...
Può essere, ma il dato di fatto è che Zen progettato da Keller ha molte meno criticità della controparte intel
Idem come sopra: un'altra cosa che non c'entra nulla.

E sì che era scritto a chiare lettere nell'articolo che TU STESSO avevi riportato (in QUESTO thread!), in cui parlavano degli esperti di sicurezza.

Cosa che ovviamente non ricordi più, causa tuoi cronici problemi di memoria.
Ho perso il conto delle cose a cui non hai risposto
Si vede proprio sai: io non taglio NIENTE nei miei commenti. Sono messi lì a bella posta, e chiunque può controllare.

Quello che taglia e cambia discorso sei tu, perché sei un povero disperato che non sa come uscirsene dal fosso in cui s'è infilato.
Quando scrivo qualcosa specifico sempre i miei riferimenti, per i riferimenti di quello che scrivi tu ti chiedo cortesemente di provvedere tu stesso.
E che ci vuole: c'ho messo 3 secondi a trovare quella parte. Ecco qui:
""Some current processors and future processors will have microarchitectural data sampling methods mitigated in the hardware," Intel says. "For processors that are affected, the mitigation for microarchitectural data sampling issues includes overwriting store buffers, fill buffers, and load ports before transitioning to possibly less-privileged code.""
La prossima volta, però, leggili gli articoli. E non una volta sola, visto che o non li capisci, o non ti ricordi poi niente.

passo di tanto in tanto in questo 3d
e vedo che volano sempre stracci :D

un break ragazzi così vi chiedo del perché di questo errore

https://i.postimg.cc/nhJHBrKK/reptoline.png

visto che Win 10 si è aggiornato all'ultima KB che abilita Retpoline
ho presola palla al balzo per aggiornare anche il bios del mio NUC che dal changelog di marzo annuncia un nuovo microcode

volevo verificare che tutto fosse ok e abilitato
ma ci fosse una volta che sti script di powershell partano al primo colpo :D

c'è qualche permesso da dare come succedeva per quello di spectre/meltdown?

Come amministratore:

Install-Module SpeculationControl
$SaveExecutionPolicy = Get-ExecutionPolicy *
Set-ExecutionPolicy RemoteSigned -Scope Currentuser
Import-Module SpeculationControl
Get-SpeculationControlSettings

Lo script aggiornato lo trovi qui (https://www.powershellgallery.com/packages/SpeculationControl/1.0.14).

*sempre che non sia stato modificato precedentemente (alcuni tool per la verifica non ripristinavano lo stato precedente). Io lancio sempre

Set-ExecutionPolicy Restricted -Scope CurrentUser

alla fine.

Per verificare i permessi:

Get-ExecutionPolicy -list

PS Con l'ultima versione dovresti trovarti questo output:

https://i.postimg.cc/ctKhBgqg/Cattura.png (https://postimg.cc/ctKhBgqg)

Ma chi ha detto Intel toglierà l'HT?!? Hai completamente ribaltato il discorso!

Ti faccio rispondere da te stesso:

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


Ai lettori l'ardua sentenza :asd:


https://www.hwupgrade.it/forum/showpost.php?p=46216560&postcount=27
"è da circa 3 lustri che i sorci rossi li vede AMD con le micro-architetture che ha sviluppato Dadi "

Il 5 m'è scappato DOPO, nel commento che ho scritto PRIMA di andare a letto, ed era soltanto un refuso.

Ma vedo che continui ad aggrapparti a questa sciocchezza con le unghie e i denti: si vede che non ti rimane altro.

Ripeto: dormi di più che ti fa bene :asd:


Vabbé, che tu non sappia leggere è cosa conclamata ormai...

E di nuovo hai totalmente cambiato discorso, con una cosa che non c'entra nulla su quello che avevo scritto. Tanto per cambiare...

Idem come sopra: un'altra cosa che non c'entra nulla.

E sì che era scritto a chiare lettere nell'articolo che TU STESSO avevi riportato (in QUESTO thread!), in cui parlavano degli esperti di sicurezza.

Cosa che ovviamente non ricordi più, causa tuoi cronici problemi di memoria.

E vai di insulti, vedo che hai sempre argomenti forti :asd:


Si vede proprio sai: io non taglio NIENTE nei miei commenti. Sono messi lì a bella posta, e chiunque può controllare.

Mai scritto che taglii commenti, ho scritto che non rispondi a tutte le domande, è ben diverso


Quello che taglia e cambia discorso sei tu, perché sei un povero disperato che non sa come uscirsene dal fosso in cui s'è infilato.

Non mi sembra proprio se sono ancora qui a replicarti :doh:


E che ci vuole: c'ho messo 3 secondi a trovare quella parte. Ecco qui:
""Some current processors and future processors will have microarchitectural data sampling methods mitigated in the hardware," Intel says. "For processors that are affected, the mitigation for microarchitectural data sampling issues includes overwriting store buffers, fill buffers, and load ports before transitioning to possibly less-privileged code.""
La prossima volta, però, leggili gli articoli. E non una volta sola, visto che o non li capisci, o non ti ricordi poi niente.

E se ci hai messo 3 secondi cosa volevi dalla mia vita? :asd: Lo facevi fin da subito da solo e fine del cinema. In ogni caso non hai messo il link della fonte cosa poco seria che non è da te :asd:

Ti faccio rispondere da te stesso:

Ai lettori l'ardua sentenza :asd:
E ai professori di italiano una stoccata per me a causa del grossolano errore grammaticale nella mia frase (ma ero morto di sonno, come già detto), e una gran lavata di testa per te che non conosci il significato di periodo ipotetico (http://www.treccani.it/enciclopedia/periodo-ipotetico_(La-grammatica-italiana)/).

Poi se avessi letto un mio precedente commento, m'ero già espresso sull'HT. Ma che tu non fossi messo bene con la memoria non sarebbe certo una novità...
Ripeto: dormi di più che ti fa bene :asd:
L'avrei fatto volentieri se non avessi avuto a che fare con te.
E vai di insulti, vedo che hai sempre argomenti forti :asd:
Come direbbe Burioni, non sono insulti, ma una constatazione di fatto.

Non sai leggere o non capisci quello che scrivono gli altri, e hai sistematici problemi di memoria.
Mai scritto che taglii commenti, ho scritto che non rispondi a tutte le domande, è ben diverso
Ho risposto sempre a tutto, ma sei sempre libero di quotarmi e farmi vedere dov'è che non l'avrei fatto. :read:

Poi se hai problemi di comprensione (vedi sopra) e non riesci a capire le risposte, sono esclusivamente problemi tuoi.
Non mi sembra proprio se sono ancora qui a replicarti :doh:
Guarda che quando la finirai farai un favore anche a me.
E se ci hai messo 3 secondi cosa volevi dalla mia vita? :asd: Lo facevi fin da subito da solo e fine del cinema.
Avresti già dovuto leggerlo tu stesso, visto che era stato postato proprio in questo thread.

Ma siccome non te ne frega niente, a parte infangare Intel...
In ogni caso non hai messo il link della fonte cosa poco seria che non è da te :asd:
E niente, se non dimostri per l'n-esima volta che hai i problemi di cui sopra, non sei contento.

Ecco da dove arriva il link. (https://www.hwupgrade.it/forum/showpost.php?p=46217735&postcount=2302)
A cui peraltro hai replicato subito dopo, tirandomi in ballo (https://www.hwupgrade.it/forum/showpost.php?p=46217888&postcount=2304) (da cui la mia risposta. Insomma, te la sei cercata).
Poi ho replicato con questo (https://www.hwupgrade.it/forum/showpost.php?p=46218183&postcount=2311), dove ho riportato un commento dello stesso utente (Nui_Mg), ma che aveva scritto in un altro thread (a cui anche tu hai partecipato. E in cui stiamo discutendo; sì, pure lì.).

La fonte, insomma, era sempre la stessa, e l'hai avuta sotto il naso. Ma non l'hai letta nemmeno di striscio...

Come amministratore:

Install-Module SpeculationControl
$SaveExecutionPolicy = Get-ExecutionPolicy *
Set-ExecutionPolicy RemoteSigned -Scope Currentuser
Import-Module SpeculationControl
Get-SpeculationControlSettings... CUT

grazie Varg
ah ,quindi è sempre lo stesso script dell'altra volta ma aggiornato

allora mi sa che devo dare prima il comando di uninstall e fargli mettere il nuovo
poi proseguo con le command che mi hai suggerito

ma l'altra volta non bastava dare Set-ExecutionPolicy -ExecutionPolicy Bypass per scavalcare momentaneamente i permessi e alla fine di tutto
Set-ExecutionPolicy Restricted per rimettere tutto a posto?

comunque è andata
il comando ora lo prende

le KB4494441 sono state installate regolarmente 2 volte
aggiornato il bios

ma Retpoline è disabilitato (il resto è ok?) :what:

https://i.postimg.cc/Fh8bhbxk/reptoline2.png

Nel thread di 10 è stata segnalata la stessa cosa. Io me lo son trovato abilitato automaticamente, anche perché quando è stato aggiunto Retpoline tempo fa eradisabilitsto di default. L'avevo abilitato manualmente per fare dei test ma lo avevo ridisabilitato perché sul mio PC era pure meno performante rispetto al microcode Intel.
Se cerchi in questo thread (non tanto piú indietro) avevo scritto come abilitarlo/disabilitarlo manualmente.

E ai professori di italiano una stoccata per me a causa del grossolano errore grammaticale nella mia frase (ma ero morto di sonno, come già detto), e una gran lavata di testa per te che non conosci il significato di periodo ipotetico (http://www.treccani.it/enciclopedia/periodo-ipotetico_(La-grammatica-italiana)/).

Poi se avessi letto un mio precedente commento, m'ero già espresso sull'HT. Ma che tu non fossi messo bene con la memoria non sarebbe certo una novità...

L'avrei fatto volentieri se non avessi avuto a che fare con te.

Come direbbe Burioni, non sono insulti, ma una constatazione di fatto.

Non sai leggere o non capisci quello che scrivono gli altri, e hai sistematici problemi di memoria.

Ho risposto sempre a tutto, ma sei sempre libero di quotarmi e farmi vedere dov'è che non l'avrei fatto. :read:

Poi se hai problemi di comprensione (vedi sopra) e non riesci a capire le risposte, sono esclusivamente problemi tuoi.

Guarda che quando la finirai farai un favore anche a me.

Avresti già dovuto leggerlo tu stesso, visto che era stato postato proprio in questo thread.

Ma siccome non te ne frega niente, a parte infangare Intel...

E niente, se non dimostri per l'n-esima volta che hai i problemi di cui sopra, non sei contento.

Ecco da dove arriva il link. (https://www.hwupgrade.it/forum/showpost.php?p=46217735&postcount=2302)
A cui peraltro hai replicato subito dopo, tirandomi in ballo (https://www.hwupgrade.it/forum/showpost.php?p=46217888&postcount=2304) (da cui la mia risposta. Insomma, te la sei cercata).
Poi ho replicato con questo (https://www.hwupgrade.it/forum/showpost.php?p=46218183&postcount=2311), dove ho riportato un commento dello stesso utente (Nui_Mg), ma che aveva scritto in un altro thread (a cui anche tu hai partecipato. E in cui stiamo discutendo; sì, pure lì.).

La fonte, insomma, era sempre la stessa, e l'hai avuta sotto il naso. Ma non l'hai letta nemmeno di striscio...

Vedo che stiamo diventando sempre più mattinieri eh :asd:
E vedo che la tua megalomania è senza limiti tanto che adesso ti elevi al ruolo di Burioni :asd: Fly Down bello che quando hanno distribuito la modestia tu non c'eri :asd: e comunque vai che incasso questa nuova raffica di insulti gratuiti.
Sulla questione dell'HT torniamo al principio: intel sulla serie 9 desktop non lo ha messo su nessuna cpu tranne le 9900, fatto strano perché prima c'era sempre su tutti gli I7 che sono di fascia inferiore. Poi ti ripeto che se tiri in ballo un link lo posti, si chiama correttezza e io i miei riferimenti li posto sempre tutti, non faccio affermazioni chiedendo agli altri di documentarmele. Sul fatto che intel si stia dando da fare è vero: una volta scappate le vacche non aveva alternative e, se sono vere le voci che girano, ha cercato di sistemarle pagando anche qualche mazzetta ma su questo argomento potrai verificare meglio nell'altro thread dove ti ho risposto e fai la tua puntuale figura da cioccolataio.
E mi raccomando, vedi di non stancarti perché non ho nessuna intenzione di lasciaretene passare una, con le persone arroganti e disoneste intellettualmente non riesco a non reagire.

grazie Varg
ah ,quindi è sempre lo stesso script dell'altra volta ma aggiornato

allora mi sa che devo dare prima il comando di uninstall e fargli mettere il nuovo
poi proseguo con le command che mi hai suggerito

ma l'altra volta non bastava dare Set-ExecutionPolicy -ExecutionPolicy Bypass per scavalcare momentaneamente i permessi e alla fine di tutto
Set-ExecutionPolicy Restricted per rimettere tutto a posto?

Con il comando di bypass funziona sempre ed è comodo perché, una volta chiuso lo shell, torna a default.

Configurazione in firma e retpoline abitilato in automatico dopo l'ultimo windows update, bypass e poi getspeculation:

https://i.postimg.cc/k48hdLTf/Screen-Hunter-393-May-17-17-02.jpg

Testato l'ssd le cui prestazioni sono leggermente migliorate dopo l'ultimo aggiornamento con retpoline da così:

https://i.postimg.cc/9X6cQvHG/Screen-Hunter-290-Dec-28-02-30.jpg

a così:

https://i.postimg.cc/dt5nBKQC/Screen-Hunter-392-May-17-16-51.jpg

Vedo che stiamo diventando sempre più mattinieri eh :asd:
Veramente gli orari sono più o meno sempre gli stessi quando scrivo messaggi di mattina. Problemi anche a confrontare gli orari?

Comunque ieri sera ho preferito farmi una bella dormita, visto che nei giorni passati ho rubato troppo tempo al sonno.
E vedo che la tua megalomania è senza limiti tanto che adesso ti elevi al ruolo di Burioni :asd: Fly Down bello che quando hanno distribuito la modestia tu non c'eri :asd:
Il principio d'autorità non esiste e viene tirato in ballo da gente che di logica non ne capisce, come hai dimostrato e continui ancora a dimostrare con queste tue battutine da due soldi.
e comunque vai che incasso questa nuova raffica di insulti gratuiti.
Constatazioni di fatto:
- incapacità di leggere e/o comprendere ciò che dicono gli altri;
- incapacità di confronti numerici (vedi gli orari in cui scrivo);
- insufficienze di logica;
- profondi problemi di memoria.

:read:
Sulla questione dell'HT torniamo al principio: intel sulla serie 9 desktop non lo ha messo su nessuna cpu tranne le 9900, fatto strano perché prima c'era sempre su tutti gli I7 che sono di fascia inferiore.
Intel non ha rilasciato parecchie processori per la sua serie 9, come invece fa di solito. In quei pochi che ha rilasciato, su qualcuno ha messo l'HT, come fa di solito quando differenzia il top di gamma (che lo integra) e i modelli inferiori (che non lo integrano). Il pattern, qui, è stato lo stesso.

Se non avesse voluto più puntare sull'HT non soltanto non l'avrebbe messo sul top di gamma, ma nemmeno in tutti gli altri processori della serie 9 che, invece, lo integrano (e sono tanti).

D'altra parte non c'è nessun motivo per cui dovrebbe rinunciare all'HT, visti i vantaggi che offre.
Poi ti ripeto che se tiri in ballo un link lo posti, si chiama correttezza e io i miei riferimenti li posto sempre tutti, non faccio affermazioni chiedendo agli altri di documentarmele.
Il punto è un altro: avresti già dovuto saperlo, perché il link è stato postato qui, e tu hai pure REPLICATO a quel commento che lo riportava.

Dunque risulta evidente che tu NON l'abbia letto. Oppure NON l'abbia capito.

Io, invece, me lo sono smazzato tutto e ho preso atto dei fatti e dettagli che riportava.
Sul fatto che intel si stia dando da fare è vero: una volta scappate le vacche non aveva alternative e, se sono vere le voci che girano, ha cercato di sistemarle pagando anche qualche mazzetta ma su questo argomento potrai verificare meglio nell'altro thread dove ti ho risposto e fai la tua puntuale figura da cioccolataio.
Ti ho risposto poco fa, così vediamo chi è a uso fare brutte figure.
E mi raccomando, vedi di non stancarti perché non ho nessuna intenzione di lasciaretene passare una, con le persone arroganti e disoneste intellettualmente non riesco a non reagire.
Detto da uno che sistematicamente taglia roba e non risponde, fa semplicemente ridere.

Cercare di ribaltare la realtà dopo tutte le figure barbine che hai fatto (e non soltanto nell'ultimo periodo) è il classico tentativo dei disperati che non sanno più a cosa aggrapparsi.

Veramente gli orari sono più o meno sempre gli stessi quando scrivo messaggi di mattina. Problemi anche a confrontare gli orari?

Comunque ieri sera ho preferito farmi una bella dormita, visto che nei giorni passati ho rubato troppo tempo al sonno.

Il principio d'autorità non esiste e viene tirato in ballo da gente che di logica non ne capisce, come hai dimostrato e continui ancora a dimostrare con queste tue battutine da due soldi.

Constatazioni di fatto:
- incapacità di leggere e/o comprendere ciò che dicono gli altri;
- incapacità di confronti numerici (vedi gli orari in cui scrivo);
- insufficienze di logica;
- profondi problemi di memoria.

:read:

Intel non ha rilasciato parecchie processori per la sua serie 9, come invece fa di solito. In quei pochi che ha rilasciato, su qualcuno ha messo l'HT, come fa di solito quando differenzia il top di gamma (che lo integra) e i modelli inferiori (che non lo integrano). Il pattern, qui, è stato lo stesso.

Se non avesse voluto più puntare sull'HT non soltanto non l'avrebbe messo sul top di gamma, ma nemmeno in tutti gli altri processori della serie 9 che, invece, lo integrano (e sono tanti).

D'altra parte non c'è nessun motivo per cui dovrebbe rinunciare all'HT, visti i vantaggi che offre.

Il punto è un altro: avresti già dovuto saperlo, perché il link è stato postato qui, e tu hai pure REPLICATO a quel commento che lo riportava.

Dunque risulta evidente che tu NON l'abbia letto. Oppure NON l'abbia capito.

Io, invece, me lo sono smazzato tutto e ho preso atto dei fatti e dettagli che riportava.

Ti ho risposto poco fa, così vediamo chi è a uso fare brutte figure.

Detto da uno che sistematicamente taglia roba e non risponde, fa semplicemente ridere.

Cercare di ribaltare la realtà dopo tutte le figure barbine che hai fatto (e non soltanto nell'ultimo periodo) è il classico tentativo dei disperati che non sanno più a cosa aggrapparsi.

E anche di qua facciamo il pieno di insulti da Megaloman :asd:https://i.pinimg.com/originals/60/60/bf/6060bfebe0f5cb13386cb48cd150e835.jpg
Se sei sicuro delle tue idee non c'è bisogno di scomodare altre figure autorevoli con le quali tu non hai nulla da spartire :asd:

Continui a far finta di non capire, gli I9 sono top di gamma quindi c'era da aspettarsi l'HT su tutte le cpu come del resto lo era per tutti gli I7. E vai che anche oggi hai sfornato cioccolato fresco qui come negli altri thread. Ripeto dormi che è meglio :asd

sinceramente penso che non importi più a nessuno chi abbia ragione

sinceramente penso che non importi più a nessuno chi abbia ragione

Sono sinceramente d'accordo con te :) Ammetto il fatto che, non lasciar perdere, possa essere un mio limite e chiedo scusa sia a te che a chiunque altro non gradisca la diatriba tra me e cdi, probabilmente la maggioranza dei lettori. Il problema è che mi sento preso in giro da cdi e ne sto facendo una questione di principio perchè non credo sia giusto diffondere notizie che in alcuni casi sono secondo me clamorosamente false, lasciado perdere tutti gli insulti ricevuti da cdi.

sinceramente penso che non importi più a nessuno chi abbia ragione

*

PS Ho provato ora a disabilitare Retpoline ma da registro era già disabilitato. Quella chiave non funziona più perchè rimane sempre abilitato.

https://i.postimg.cc/4xKhCJ6t/Image-1.jpg

Varg, c6?? :D

Updated March 5, 2019:
https://techcommunity.microsoft.com/t5/Windows-Kernel-Internals/Mitigating-Spectre-variant-2-with-Retpoline-on-Windows/ba-p/295618

Ripristinando il valore 8, rimane comunque abilitato. Ho provato a rimettere 400 e 8 in seguito ad un riavvio ma non cambia niente.
Che possa essere l'ultimo microcode di febbraio 2019? Se non fosse che le ultime volte che ho eseguito il flash si è sempre piantato e son dovuto ricorrere al programmer (non c'ho voglia stavolta), avrei già provato a ripristinare il vecchio microcode.

Rispetto all'ultima volta che ho eseguito il test di Magician (quando ho messo l'ultimo microcode), ho perso altri 10000 punti IOPS sia in lettura che in scrittura.

*

Rispetto all'ultima volta che ho eseguito il test di Magician (quando ho messo l'ultimo microcode), ho perso altri 10000 punti IOPS sia in lettura che in scrittura.

Dopo aver fatto un po' di pulizia sul ssd in realtà a me la situazione è ulteriormente migliorata rispetto al pre-retpoline ed è la seguente:

senza retpoline:
https://i.postimg.cc/9X6cQvHG/Screen-Hunter-290-Dec-28-02-30.jpg

con retpoline:
https://i.postimg.cc/2yxCn0hk/Screen-Hunter-396-May-18-20-11.jpg

A tool to check whether your system is affected by Micro-architectural Data Sampling and other attacks (non l'ho testato):

https://github.com/vusec/ridl
https://mdsattacks.com/files/mdstool-win.zip
https://mdsattacks.com/files/mdstool-linux.zip

Con il comando di bypass funziona sempre ed è comodo perché, una volta chiuso lo shell, torna a default.

no no , anche riavviando il bypass rimane
bisogna ripristinare con Set-ExecutionPolicy Restricted

https://i.postimg.cc/4d0qwr39/shell.png

Nel thread di 10 è stata segnalata la stessa cosa. Io me lo son trovato abilitato automaticamente, anche perché quando è stato aggiunto Retpoline tempo fa eradisabilitsto di default. L'avevo abilitato manualmente per fare dei test ma lo avevo ridisabilitato perché sul mio PC era pure meno performante rispetto al microcode Intel.
Se cerchi in questo thread (non tanto piú indietro) avevo scritto come abilitarlo/disabilitarlo manualmente.

però leggo che hai abilitato e disabilitato e non risponde più ai comandi da reg :fagiano:

che poi c'è qualcosa che non mi torna
ho aggiornato il bios del NUC , e l'ultimo changelog dice

https://i.postimg.cc/J4HDTJpD/NUC.png

ma io leggo sempre lo stesso microcode del precedente BIOS
la revisione è la stessa

https://i.postimg.cc/9QFf67pY/NUC2.png

Il microcode e diverso a seconda della CPU, alcune non sono toccate dagli update, altre si.

Inviato dal mio Nokia 6.1 utilizzando Tapatalk

Dopo aver fatto un po' di pulizia sul ssd in realtà a me la situazione è ulteriormente migliorata rispetto al pre-retpoline ed è la seguente:

CUT

Boh, qua anche dopo aver eseguito il performance optimization non è cambiato nulla.
C'è da dire che quest'installazione me la porto dietro da parecchio e visto che quest'estate, se tutto va secondo i piani, rifarò il PC da zero non mi ci metto neanche a fare un'installazione pulita che mi porterebbe via un pomeriggio.
Tra l'altro, vedendo la situazione dopo aver aggiornato il microcode con quello di febbraio 2019, non dovrebbe nemmeno essere correlato il rallentamento ma vai a capire...con tutti sti aggiornamenti alla fine non si capisce più niente.


però leggo che hai abilitato e disabilitato e non risponde più ai comandi da reg :fagiano:

che poi c'è qualcosa che non mi torna
ho aggiornato il bios del NUC , e l'ultimo changelog dice

https://i.postimg.cc/J4HDTJpD/NUC.png

ma io leggo sempre lo stesso microcode del precedente BIOS
la revisione è la stessa

https://i.postimg.cc/9QFf67pY/NUC2.png

Esatto, per questo mi chiedo se interviene il microcode abilitando Retpoline di suo (dopo l'aggiornamento con l'ultimo microcode di febbraio 2019 non ho più eseguito il controllo da Powershell). Non trovo altre spiegazioni se non eventuali bug.

Non è detto che l'ultimo BIOS, anche se postdatato rispetto all'ultimo microcode rilasciato per una determinata CPU, contenga l'ultimo microcode disponibile.
Una delle mobo che ho per le mani ha ricevuto un aggiornamento che risolve un problema di sicurezza dell'Intel Management Engine (altra rogna inutile) ma il microcode è rimasto lo stesso del BIOS precedente (nonostante fosse uscita una nuova revisione nel frattempo).

PS Potete controllare che valore ha la chiave di registro

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\FeatureSettingsOverride?

Non è detto che l'ultimo BIOS, anche se postdatato rispetto all'ultimo microcode rilasciato per una determinata CPU, contenga l'ultimo microcode disponibile.

si ma io avevo il bios precedente con lo stesso microcode
e nel change log dice che è stato aggiornato

poi la cosa ancora più stana è che Intel ha rilasciato una revisione .410 per i Braswell N3XXX nel lontano marzo 2018

https://i.postimg.cc/Cx1HYRP0/code.png

e qui siamo fermi sempre a 367
per me hanno cannato qualcosa quando l'hanno compilato

PS Potete controllare che valore ha la chiave di registro

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\FeatureSettingsOverride?

quando ho un secondo vado a vederlo

no no , anche riavviando il bypass rimane
bisogna ripristinare con Set-ExecutionPolicy Restricted

https://i.postimg.cc/4d0qwr39/shell.png



Quando faccio bypass e poi chiudo la shell e successivamente la riapro se provo ad effettuare ancora il getspeculation non me lo accetta, prima devo necessariamente fare un nuono bypass :)

Boh, qua anche dopo aver eseguito il performance optimization non è cambiato nulla.
C'è da dire che quest'installazione me la porto dietro da parecchio e visto che quest'estate, se tutto va secondo i piani, rifarò il PC da zero non mi ci metto neanche a fare un'installazione pulita che mi porterebbe via un pomeriggio.
Tra l'altro, vedendo la situazione dopo aver aggiornato il microcode con quello di febbraio 2019, non dovrebbe nemmeno essere correlato il rallentamento ma vai a capire...con tutti sti aggiornamenti alla fine non si capisce più niente.

Vai a capire :confused:

PS Potete controllare che valore ha la chiave di registro

HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\FeatureSettingsOverride?

controllato , quella chiave non c'è

c'è solo FeatureSettings impostato a C00

non so quanto possano essere attinenti od interessanti in questo thread i test comparativi performances MDS (https://www.phoronix.com/scan.php?page=article&item=mds-zombieload-mit&num=6) delle CPU.

in fondo alla pagina le medie geometriche.

https://hardware.hdblog.it/2019/05/20/intel-patch-zombieload-prestazioni-perdita/

non so quanto possano essere attinenti od interessanti in questo thread i test comparativi performances MDS (https://www.phoronix.com/scan.php?page=article&item=mds-zombieload-mit&num=6) delle CPU.

in fondo alla pagina le medie geometriche.

Premesso che parlo a titolo personale, li trovo assolutamente pertinenti e pubblicati nel thread giusto che ormai sta facendo da collettore per tutte le criticità spectre e meldown like.
Ciò detto si tratta davvero di una gran botta che si va a sommare a tutto il resto :( il 10% circa in meno non è poco e bisogna vedere se è un dato definitivo...

controllato , quella chiave non c'è

c'è solo FeatureSettings impostato a C00

Example: Feature settings values for enabling SSBD (speculative store bypass) system wide:
FeatureSettingsOverride = 0x8 and FeatureSettingsOverrideMask = 0
To add Retpoline, feature settings value for Retpoline (0x400) should be bitwise OR'd:
FeatureSettingsOverride = 0x408 and FeatureSettings OverrideMask = 0x400

https://i.postimg.cc/s1tKSVWn/Cattura.png (https://postimg.cc/s1tKSVWn)

:boh:

qui i test su piattaforme server (https://www.phoronix.com/scan.php?page=article&item=intel-mds-xeon&num=1)

al fondo dell'ultima pagina le medie

Quadro impietoso di TomsHw (che commenta i test di Phoronix) nei confronti di intel, il che è tutto dire, considerato che TomsHw è sempre stato pro-intel.
Riporta in sostanza che mentre per AMD la perdita di performance a causa delle vulnerabilità a cui è soggetta è mediamente del 3%, per intel si parla del 16% che potrebbe peggiorare, nel caso dovesse rendersi un domani necessaria la disabilitazione dell'HT, fino a puntedel 50%, speriamo proprio di no :(
https://www.tomshardware.com/news/intel-amd-mitigations-performance-impact,39381.html

Ad occhio la situazione su questo notebook (https://www.phoronix.com/scan.php?page=news_item&px=Spec-Melt-L1TF-MDS-Laptop-Run) è notevolmente peggio...

Example: Feature settings values for enabling SSBD (speculative store bypass) system wide:
FeatureSettingsOverride = 0x8 and FeatureSettingsOverrideMask = 0
To add Retpoline, feature settings value for Retpoline (0x400) should be bitwise OR'd:
FeatureSettingsOverride = 0x408 and FeatureSettings OverrideMask = 0x400

https://i.postimg.cc/s1tKSVWn/Cattura.png (https://postimg.cc/s1tKSVWn)

:boh:
Su nessuna macchina ho la voce FeatureSettings, sono presenti solo FeatureSettingsOverride & FeatureSettingsOverrideMask

Questa sera ho aggiornato il microcode del mio 4790k in firma alla versione 0x27 che dovrebbe mitigare, ma non ho capito quanto, anche le ultime vulnerabilità più recenti: https://security.netapp.com/advisory/ntap-20190515-0001/

Qui https://www.intel.com/content/dam/www/public/us/en/documents/corporate-information/SA00233-microcode-update-guidance_05132019.pdf la microcode revision guidance del 14/05/2019.
Ho fatto un veloce cinebench e un test sull'ssd e nulla sembrerebbe cambiato rispetto alla versione precedente de ucode... solo, ripeto, non riesco a capire quanto siano efficaci i nuovi microcode contro zombieload & co.:stordita:

su un vechio notebook con CPU Intel T4400 è arrivato un aggiornamento Intel microcode 14.05.19...
non so se riguarda queste nuove vulnerabilità però è notevole che per un prodotto così vecchio e di fascia così bassa arrivino ancora aggiornamenti

:eek: dei Penryn del 2009

allora è valido anche per il mio P8600

peccato che il Vaio in cui è montato non riceverà mai un aggiornamento BIOS

edit

ma sei sicuro ?
nel PDF intel del 14/5 , i Penryn risultano sempre "Not planned"

https://i.postimg.cc/3xfCQM71/intel.png

:eek: dei Penryn del 2009

allora è valido anche per il mio P8600

peccato che il Vaio in cui è montato non riceverà mai un aggiornamento BIOS

edit

ma sei sicuro ?
nel PDF intel del 14/5 , i Penryn risultano sempre "Not planned"

https://i.postimg.cc/3xfCQM71/intel.png


il package microcode (https://packages.ubuntu.com/search?keywords=intel-microcode&searchon=names&suite=bionic&section=all) è arrivato, devo verificare i cambiamenti e se è stato applicato alla CPU in questione...

si se non ricordo male il package è uno per tutte le cpu, ma poi le modifiche sono solo su alcune

che, sempre se ricordo bene, sarebbe uno di quegli aspetti da migliorare lato 'chiarezza', specialmente in seguito allo scoperchiamento del vaso
salvo mi sfugga qualcosa (sempre possibile) non credo che splittare in più file (eventuali ripetizioni comprese) sarebbe complicato da implementare, nè costoso da gestire

Nuove vulnerabilià... nuovo speculation control :asd:
Passatemi il termine, io ormai lo chiamerei perculation control :sofico:
Oramai è diventato kilometrico a furia di nuove vulnerabilità che si aggiungono di continuo :D
Per controllare le ultimissime della categoria MDS bisogna installare la versione 1.0.14, se guardate l'immagine sotto vi basta fare gli stessi miei passaggi:

https://i.postimg.cc/Mzf4PsPG/Screen-Hunter-401-May-24-18-44.jpg

è sempre lo stesso di 10 giorni fa. :fagiano:

è sempre lo stesso di 10 giorni fa. :fagiano:

Si si lo so :fagiano: era solo per far vedere lo speculation control una volta aggiornato il microcode del mio 4790k con la versione 0x27 e per lasciare traccia di come fare :fagiano:

Test di Phoronix sul gaming https://www.phoronix.com/scan.php?page=news_item&px=Zombie-Load-Gaming-Impact Le mitigazioni per MDS e Zombieload hanno un impatto trascurabile.

Che strano... Windows e' solo aggiornabile fino alla 1709. Niente 1803 e 1809.

https://support.microsoft.com/it-it/help/4093836/summary-of-intel-microcode-updates

A quanto pare per Giuffrida, uno dei membri del team universitario che ha scoperto le vulnerabilità MDS, la responsabilità di queste criticità sarebbe da attribuire alla troppa leggerezza con cui hanno lavorato i chip designer di intel:

Intel's chip designers may have believed that a wrong guess, even one that serves up sensitive data, didn't matter. "It throws these results away," says VUSec's Guiffrida. "But we still have this window of vulnerability that we use to leak the information

Ma soprattutto nello stesso articolo viene fatto notare come queste nuove vulnerabilità siano allo stesso tempo semplici da sfruttare e potenzialmente devastanti e che per ridurre i rischi bisognerebbe disabilitare l'HT mentre invece per intel si tratta di qualcosa di molto meno preoccupante e non serve disabilitare l'HT:

In the meantime, however, the researchers and Intel disagree on the severity of the problem and how to triage it. Both TU Graz and VUSec recommend that software makers disable hyperthreading, a feature of Intel chips that accelerates their processing by allowing more tasks to be performed in parallel, but could make certain variants of the MDS attacks vastly easier to pull off. Intel insisted in a phone call with WIRED that the flaws don't warrant disabling that feature, which would have a serious performance cost for users. In fact, the company has rated the four vulnerabilities at a mere "low to medium" severity—a rating that both TU Graz and VUSec researchers challenged.

Infine viene spiegato meglio il presunto tentativo di intel di "mitigare" le nuove vulnerabilità col denaro:

VUSec's Giuffrida notes that his team was paid $100,000 by Intel for their work as part of the company's "bug bounty" program that rewards researchers who warn the company about critical flaws. That's hardly the kind of money paid out for trivial issues, he points out. But he also says that Intel at one point offered VUSec only a $40,000 bug bounty, accompanied by a $80,000 "gift"—which Giuffrida saw as an attempt to reduce the bounty amount cited publicly and thus the perceived severity of the MDS flaws. VUSec refused the offer of more total money in favor of a bounty that better reflected the severity of its findings, and it threatened to opt out of a bug bounty in protest. Intel changed its offer to the full $100,000.

Fonte https://www.wired.com/story/intel-mds-attack-speculative-execution-buffer/

Ecco, io a questo punto mi chiedo se dopo, aver applicato le varie mitigazioni, ci sia ancora un rischio significativo oppure no.

A proposito della disabilitazione dell'HT:

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

https://www.techspot.com/article/1850-how-screwed-is-intel-no-hyper-threading/

A proposito della disabilitazione dell'HT:

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

Praticamente un calcio nei cogl... volevo dire denti :D Se per caso ti dovesse capitare di trovare qualcosa sull'efficacia delle attuali mitigazioni sappi che sono mooolto interessato. Mi sarebbe piaciuto tenere il 4790k almeno per un altro paio di anni ma se continua così...

mi pare ovvio, dopo anni spesi ad ottimizzare il software per sfruttare l'ht, se lo disattivi ti accorgi subito che manca, basti pensare la differenza di prezzo che si pagava tra i5 e i7 all'epoca... sembra quasi che stiano suggerendo un approccio BSD like... ovvio che anche intel lo sappia, e magari stanno temporeggiando in attesa di trovare una soluzione che salvi capra e cavoli... almeno nel frattempo che sviluppano qualcosa di nuovo che non ha questo problema...

... e se anche Toms (sempre stato pro intel) la butta giù pesante :( :( :( https://www.tomshw.it/hardware/cpu-intel-amd-impatto-zombieload-spectre-meltdown/

Sí ma sti geni testano con un processore senza HT? A sto punto potevano fare il test col mio i5 3570k. :asd:

Sí ma sti geni testano con un processore senza HT? A sto punto potevano fare il test col mio i5 3570k. :asd:

Il fatto è che secondo loro l'HT va disabilitato :( e quindi usare il 9700k è giusto perchè è come usare il 9900k senza HT, ecco perchè scrivevo che la buttano giù pesante :( . Del resto anche i ricercatori universitari che hanno scoperto la vulnerabilità scrivono che è meglio disabilitare l'HT https://twitter.com/c_giuffrida/status/1128364903905906688

Ah ok, vista cosí ha senso. Non ho letto tutta la recensione e non ci avevo pensato.

Ah ok, vista cosí ha senso. Non ho letto tutta la recensione e non ci avevo pensato.

Spero solo che in qualche modo si riesca ad evitare la disabilitazione dell'HT altrimenti chi come me ha un I7 che ad oggi va ancora decentemente dovrà scegliere tra sicurezza e prestazioni :( comunque, non so se ci hai fatto caso, un tizio con un 4790K che ha applicato le mitigazioni ha chiesto, nel tweet linkato sopra, a Giuffrida se è ancora consigliabile disabilitare l'HT :D Speriamo che risponda :confused:

A quanto pare per Giuffrida, uno dei membri del team universitario che ha scoperto le vulnerabilità MDS, la responsabilità di queste criticità sarebbe da attribuire alla troppa leggerezza con cui hanno lavorato i chip designer di intel:

Intel's chip designers may have believed that a wrong guess, even one that serves up sensitive data, didn't matter. "It throws these results away," says VUSec's Guiffrida. "But we still have this window of vulnerability that we use to leak the information
Mi pare normale visto che, come già ampiamente discusso anche qui tempo fa, quelle trovate sono vulnerabilità del tutto nuove, che all'epoca nessuno immaginava.
Ma soprattutto nello stesso articolo viene fatto notare come queste nuove vulnerabilità siano allo stesso tempo semplici da sfruttare e potenzialmente devastanti e che per ridurre i rischi bisognerebbe disabilitare l'HT mentre invece per intel si tratta di qualcosa di molto meno preoccupante e non serve disabilitare l'HT:

In the meantime, however, the researchers and Intel disagree on the severity of the problem and how to triage it. Both TU Graz and VUSec recommend that software makers disable hyperthreading, a feature of Intel chips that accelerates their processing by allowing more tasks to be performed in parallel, but could make certain variants of the MDS attacks vastly easier to pull off. Intel insisted in a phone call with WIRED that the flaws don't warrant disabling that feature, which would have a serious performance cost for users. In fact, the company has rated the four vulnerabilities at a mere "low to medium" severity—a rating that both TU Graz and VUSec researchers challenged.
Come già detto, bisogna anche vedere QUANTE informazioni si riescano a estrarre in un certo tempo.

Finora i test effettuati impegnano le macchine provate a fare solo quello.

Senza, poi, considerare il fatto che il codice d'essere presente nel sistema e... fatto girare (ma questo vale per tutte le vulnerabilità).
Infine viene spiegato meglio il presunto tentativo di intel di "mitigare" le nuove vulnerabilità col denaro:

VUSec's Giuffrida notes that his team was paid $100,000 by Intel for their work as part of the company's "bug bounty" program that rewards researchers who warn the company about critical flaws. That's hardly the kind of money paid out for trivial issues, he points out. But he also says that Intel at one point offered VUSec only a $40,000 bug bounty, accompanied by a $80,000 "gift"—which Giuffrida saw as an attempt to reduce the bounty amount cited publicly and thus the perceived severity of the MDS flaws. VUSec refused the offer of more total money in favor of a bounty that better reflected the severity of its findings, and it threatened to opt out of a bug bounty in protest. Intel changed its offer to the full $100,000.

Fonte https://www.wired.com/story/intel-mds-attack-speculative-execution-buffer/
Quindi non c'è stato alcun tentativo di corruzione da parte di Intel, e quella riportata è soltanto l'impressione di quel ricercatore.

Almeno questo è stato finalmente chiarito.
Ecco, io a questo punto mi chiedo se dopo, aver applicato le varie mitigazioni, ci sia ancora un rischio significativo oppure no.
Se sono mitigazioni, mi aspetto che il rischio permanga, altrimenti si parlerebbe di fix del problema.

Ma non è affatto chiaro, e sarebbe interessante che se ne parlasse meglio.

Mi pare normale visto che, come già ampiamente discusso anche qui tempo fa, quelle trovate sono vulnerabilità del tutto nuove, che all'epoca nessuno immaginava.

Il fatto è che intel è di gran lunga la più colpita sia per numero, che per gravità, che per perdita di performace dovuta alle mitigazioni. In questo senso il ricercatore credo sostenga che gli altri forse abbiano lavorato meglio tanto che è per la sola intel che si parla di necessità di disabilitare l'smt


Come già detto, bisogna anche vedere QUANTE informazioni si riescano a estrarre in un certo tempo.

Io per primo spero pochissime ma non ci scommetterei


Finora i test effettuati impegnano le macchine provate a fare solo quello.

Senza, poi, considerare il fatto che il codice d'essere presente nel sistema e... fatto girare (ma questo vale per tutte le vulnerabilità).


E arispero ancora ma come sopra sarei prudente


Quindi non c'è stato alcun tentativo di corruzione da parte di Intel, e quella riportata è soltanto l'impressione di quel ricercatore.

Almeno questo è stato finalmente chiarito.


Chiarito non mi sembra, siamo davanti ad un team universitario che afferma di aver rifiutato del denaro perchè si è creata una situazione non in linea con i loro principi morali ovvero dire qualcosa di diverso dalla realtà in cambio di denaro : VUSec refused the offer of more total money in favor of a bounty that better reflected the severity of its findings, and it threatened to opt out of a bug bounty in protest. Intel changed its offer to the full $100,000.

Infatti sempre lo stesso ricercatore, e credo parli proprio a nome di tutto il suo team, aggiunge poi:

It's clear what Intel is doing," says Giufrrida. "It's in their interest to say, 'No, after Spectre and Meltdown, we didn't overlook other vulnerabilities; it's just that these were so minor that they slipped by.'"


Se sono mitigazioni, mi aspetto che il rischio permanga, altrimenti si parlerebbe di fix del problema.


Certo, l'importante è che il rischio sia minimizzato e reso accettabile


Ma non è affatto chiaro, e sarebbe interessante che se ne parlasse meglio.

Concordo e speriamo in chiarimenti positivi

Il fatto è che intel è di gran lunga la più colpita sia per numero, che per gravità, che per perdita di performace dovuta alle mitigazioni. In questo senso il ricercatore credo sostenga che gli altri forse abbiano lavorato meglio tanto che è per la sola intel che si parla di necessità di disabilitare l'smt
Non è una questione quantitativa, ma qualitativa, e c'è un PRIMA e un DOPO.

PRIMA non erano note questo tipo di problematiche, e tutti i produttori cercavano il modo di migliorare le prestazioni come poteva.

DOPO tali scoperte s'è visto che Intel è affetta da tutte le vulnerabilità finora scoperte, mentre altri produttori di processori sono affetti soltanto da alcuni (ma sono comunque presenti). Tant'è che, oltre Intel, anche IBM e ARM sono affetti, chi più chi meno, da Meltdown e Spectre, ma non dall'ultima ZombieLoad (da verificare per IBM, perché non ho letto dichiarazioni in merito).

Col senno di poi è facile puntare il dito, ma è una considerazione che lascia il tempo che trova (detto in altri termini: non c'è stato alcun dopo / premeditazione).
Io per primo spero pochissime ma non ci scommetterei

E arispero ancora ma come sopra sarei prudente
I numeri sono riportati nel paper che è stato postato proprio qui da qualcuno (forse tu, ma non ricordo bene adesso. Comunque basta vedere qualche pagina dietro).
Chiarito non mi sembra, siamo davanti ad un team universitario che afferma di aver rifiutato del denaro perchè si è creata una situazione non in linea con i loro principi morali ovvero dire qualcosa di diverso dalla realtà in cambio di denaro : VUSec refused the offer of more total money in favor of a bounty that better reflected the severity of its findings, and it threatened to opt out of a bug bounty in protest. Intel changed its offer to the full $100,000.

Infatti sempre lo stesso ricercatore, e credo parli proprio a nome di tutto il suo team, aggiunge poi:

It's clear what Intel is doing," says Giufrrida. "It's in their interest to say, 'No, after Spectre and Meltdown, we didn't overlook other vulnerabilities; it's just that these were so minor that they slipped by.'"
Come si può vedere non c'è stata nessuna operazione del tipo: "per favore, non pubblicare quei risultati, e ti pago di più il disturbo", com'era stato paventato finora.

Dunque nessunissimo tentativo di "corruzione".

Corruzione magari no, ma certo damage control, con ogni mezzo... Stanno cercando di gestire la cosa anche dal punto di vista mediatico, non solo con le mitigazioni hw ma anche con i firmware, e le news. Da apprezzare comunque lo sforzo per correggere i bug con velocità, anche se non lo fanno certo per beneficenzaQuello che rattrista è comunque sapere che al momento non hanno nulla di veramente pronto da fare vedere, se si riducono a presentare un nuovo processore ultra binnato, per cercare di tamponare la concorrenza. Bastava un es modello fornetto, magari a 10nm, magari bugfree, e anche con tutti i distinguo ci saremmo accontentati, invece così il 7 quando usciranno le nuove review non sarà certo una passeggiata... Sperando mettano in saldo i 9700 a sto punto.

Non è una questione quantitativa, ma qualitativa, e c'è un PRIMA e un DOPO.
PRIMA non erano note questo tipo di problematiche, e tutti i produttori cercavano il modo di migliorare le prestazioni come poteva.

DOPO tali scoperte s'è visto che Intel è affetta da tutte le vulnerabilità finora scoperte, mentre altri produttori di processori sono affetti soltanto da alcuni (ma sono comunque presenti). Tant'è che, oltre Intel, anche IBM e ARM sono affetti, chi più chi meno, da Meltdown e Spectre, ma non dall'ultima ZombieLoad (da verificare per IBM, perché non ho letto dichiarazioni in merito).

Se parliamo di questione qualitativa le falle più gravi sono meltdown e MDS attacks (queste ultime quelle appena scoperte dai ricercatori dell'università VU di Amsterdam) che riguardano intel e non AMD, e anche per quanto riguarda Spectre, AMD è vulnerabile solo ad alcune varianti mentre intel a tutte. Quindi intel nel confronto con AMD ne esce a pezzi anche per l'impatto delle mitigazioni necessarie che nei casi più critici prevedono anche la disabilitazione dell'HT come ad esempio consigliato da google per OS chrome https://sites.google.com/a/chromium.org/dev/chromium-os/mds-on-chromeos mentre AMD non ha nessun problema di questo tipo.
In ogni caso forse non è una coincidenza che le cpu considerate come le più performanti del mercato siano anche quelle DI GRAN LUNGA più buggate e che quelle un po' meno veloci siano poi risultate essere invece anche quelle molto più sicure



Col senno di poi è facile puntare il dito, ma è una considerazione che lascia il tempo che trova (detto in altri termini: non c'è stato alcun dopo / premeditazione).

Non è questione di puntare il dito, quanto scritto sopra è un dato di fatto, ognuno ne tragga le proprie considerazioni


I numeri sono riportati nel paper che è stato postato proprio qui da qualcuno (forse tu, ma non ricordo bene adesso. Comunque basta vedere qualche pagina dietro).

Come si può vedere non c'è stata nessuna operazione del tipo: "per favore, non pubblicare quei risultati, e ti pago di più il disturbo", com'era stato paventato finora.

Dunque nessunissimo tentativo di "corruzione".

Del fatto che non ci sia stato nessun tentativo di corruzione dovresti convincere anche il team di ricerca universitario che ha fatto affermazioni differenti, team che credo sia composto da persone intelligenti che ben si guarderebbero dal fare affermazioni così "importanti" se non le ritenessero più che fondate IMHO.

Corruzione magari no, ma certo damage control, con ogni mezzo... Stanno cercando di gestire la cosa anche dal punto di vista mediatico, non solo con le mitigazioni hw ma anche con i firmware, e le news. Da apprezzare comunque lo sforzo per correggere i bug con velocità, anche se non lo fanno certo per beneficenza
Certamente, penso sia evidentissimo (e ovvio) che Intel stia cercando di metterci una pezza come può.
Quello che rattrista è comunque sapere che al momento non hanno nulla di veramente pronto da fare vedere, se si riducono a presentare un nuovo processore ultra binnato, per cercare di tamponare la concorrenza. Bastava un es modello fornetto, magari a 10nm, magari bugfree, e anche con tutti i distinguo ci saremmo accontentati, invece così il 7 quando usciranno le nuove review non sarà certo una passeggiata... Sperando mettano in saldo i 9700 a sto punto.
Beh, sono i 10nm che hanno bloccato tutto. E' da 3 anni che si aspetta il debutto di CannonLake, che mi pare evidente essere saltato in favore di IceLake. Quest'ultimo arriverà fra qualche mese, anche se soltanto per mobile (perché è il settore più redditizio). Purtroppo per i desktop ci sarà da aspettare.
Se parliamo di questione qualitativa le falle più gravi sono meltdown e MDS attacks (queste ultime quelle appena scoperte dai ricercatori dell'università VU di Amsterdam) che riguardano intel e non AMD, e anche per quanto riguarda Spectre, AMD è vulnerabile solo ad alcune varianti mentre intel a tutte. Quindi intel nel confronto con AMD ne esce a pezzi anche per l'impatto delle mitigazioni necessarie che nei casi più critici prevedono anche la disabilitazione dell'HT come ad esempio consigliato da google per OS chrome https://sites.google.com/a/chromium.org/dev/chromium-os/mds-on-chromeos mentre AMD non ha nessun problema di questo tipo.
"più gravi" -> questione quantitativa.
In ogni caso forse non è una coincidenza che le cpu considerate come le più performanti del mercato siano anche quelle DI GRAN LUNGA più buggate e che quelle un po' meno veloci siano poi risultate essere invece anche quelle molto più sicure
Non è una coincidenza: vuol dire che Intel ha saputo fare meglio degli altri i "compiti per casa" dell'epoca. Ossia spingere al massimo sulle prestazioni.
Non è questione di puntare il dito, quanto scritto sopra è un dato di fatto, ognuno ne tragga le proprie considerazioni
Le conclusioni sono abbastanza semplici: nessuno aveva la sfera di cristallo per capire cosa sarebbe scoppiato.
Del fatto che non ci sia stato nessun tentativo di corruzione dovresti convincere anche il team di ricerca universitario che ha fatto affermazioni differenti, team che credo sia composto da persone intelligenti che ben si guarderebbero dal fare affermazioni così "importanti" se non le ritenessero più che fondate IMHO.
Non c'è bisogno di convincere nessuno: è sufficiente leggere le dichiarazioni che anche tu hai riportato, che sono piuttosto chiare su come siano andate le cose.

"più gravi" -> questione quantitativa.

A mio parere gravità=problema peggiore da un punto di vista qualitativo e intel è messa peggio di AMD come pure per la quantità numerica di vulnerabilità a cui è soggetta


Non è una coincidenza: vuol dire che Intel ha saputo fare meglio degli altri i "compiti per casa" dell'epoca. Ossia spingere al massimo sulle prestazioni.

Io ho un'idea diversa: non è una coincidenza, intel ha spinto al massimo sulle prestazioni sacrificando attenzione alla sicurezza, ti ricordo infatti che intel è stata in grado di scoprire in autonomia le vulnerabilità del tipo MDS Attacks segno che forse potevano essere, almeno in minima parte, previsti problemi di sicurezza nel mantenere "in giro" informazioni sensibili durante l'attività speculativa delle sue cpu, cosa che certamente le ha dato un vantaggio prestazionale sul momento ma che ora si riflette nei problemi odierni. E non è una coincidenza che invece AMD abbia (ad oggi ma con Ryzen 3000 ci potrbbe essere il sorpasso tra circa 1 mese) cpu con prestazioni leggermente inferiori a parità di core ma non sia vulnerabile a MDS Attacks, a Meltdown e a diverse tipologie di Spectre e che, a differenza di intel, non abbia problemi a mantenere l'SMT abilitato.

Le conclusioni sono abbastanza semplici: nessuno aveva la sfera di cristallo per capire cosa sarebbe scoppiato.

Sfera di critallo o meno l'impatto su AMD di tutte le vulnerabilità emerse negli ultimi 18 mesi è minimo mentre su intel no e se dovrà rendersi mai necessaria la disabilitazione dell'HT, chi ha pagato un sovrapprezzo consistente per poter utilizzare questa caratteristica avrà poco da esserne contento

Non c'è bisogno di convincere nessuno: è sufficiente leggere le dichiarazioni che anche tu hai riportato, che sono piuttosto chiare su come siano andate le cose.
E nelle loro dichiarazioni i ricercatori universitari dicono che intel ha offerto loro denaro per dare un quadro di gravità molto inferiore a quello reale ovvero, in altre parole, per dichiarare il falso. Ripeto che, detto da un team di ricerca universitario e non da un troll su un forum, fa abbastanza effetto e, se fosse vero, sarebbe gravissimo.

A mio parere gravità=problema peggiore da un punto di vista qualitativo e intel è messa peggio di AMD come pure per la quantità numerica di vulnerabilità a cui è soggetta
qualitativo (http://treccani.it/vocabolario/qualitativo/):
"Nel linguaggio scient. è spesso usato genericam., sempre in contrapp. a quantitativo, per indicare che un discorso, un ragionamento o anche un diagramma non sono appoggiati a precisi riferimenti numerici"
Io ho un'idea diversa: non è una coincidenza, intel ha spinto al massimo sulle prestazioni sacrificando attenzione alla sicurezza,
La tua idea non combacia coi fatti e con la storia: è e rimane, per l'appunto, una tua idea.

I fatti sono che all'epoca nessuno fosse a conoscenza di vulnerabilità di questo tipo.

I fatti sono che tutti i produttori di processori siano stati affetti, chi più, chi meno, da queste nuovissime vulnerabilità.

Se hai informazioni storiche che possano smentire tutto ciò (ossia: si sapeva già che si sarebbe andati in contro a questo tipo di vulnerabilità), non hai che da riportarle.

In mancanza, quindi direi proprio di no: no, Intel non ha sacrificato la sicurezza alle prestazioni.
ti ricordo infatti che intel è stata in grado di scoprire in autonomia le vulnerabilità del tipo MDS Attacks segno che forse potevano essere, almeno in minima parte, previsti problemi di sicurezza nel mantenere "in giro" informazioni sensibili durante l'attività speculativa delle sue cpu,
Intel ha scoperto queste nuove vulnerabilità DOPO che sono state scoperte Spectre e Meltdown, e quindi DOPO che è venuta alla luce questa NUOVA tipologia di vulnerabilità.

Quindi ancora no: non potevano essere previsti problemi di sicurezza di questo tipo.

Anche qui, se hai informazioni che dimostrino che IN PASSATO (PRIMA di Spectre & Meltdown) se ne fosse già a conoscenza, non hai che da riportarle.
cosa che certamente le ha dato un vantaggio prestazionale sul momento ma che ora si riflette nei problemi odierni.
Come tutti. Chi più, chi meno.
E non è una coincidenza che invece AMD abbia (ad oggi ma con Ryzen 3000 ci potrbbe essere il sorpasso tra circa 1 mese) cpu con prestazioni leggermente inferiori a parità di core ma non sia vulnerabile a MDS Attacks, a Meltdown e a diverse tipologie di Spectre e che, a differenza di intel, non abbia problemi a mantenere l'SMT abilitato.
E' una coincidenza, invece, a meno che tu non porti le prove di cui sopra.

No, quel che PENSI (TU) non è una prova.

Peraltro proprio tu hai riportato qui, tempo fa, l'opinione di esperti di sicurezza che dimostrano il contrario di ciò che affermi.
Sfera di critallo o meno l'impatto su AMD di tutte le vulnerabilità emerse negli ultimi 18 mesi è minimo mentre su intel no e se dovrà rendersi mai necessaria la disabilitazione dell'HT,
Sfera di cristallo, e dunque coincidenza. A meno di prove in merito: vedi sopra.
chi ha pagato un sovrapprezzo consistente per poter utilizzare questa caratteristica avrà poco da esserne contento
Nessuno ha pagato un sovrapprezzo, infatti: chi ha comprato all'epoca NON poteva conoscere la situazione si sarebbe venuta a creare DOPO.

Fermo restando che non è affatto obbligatorio dover avere tutte le mitigazioni abilitate.
E nelle loro dichiarazioni i ricercatori universitari dicono che intel ha offerto loro denaro per dare un quadro di gravità molto inferiore a quello reale ovvero, in altre parole, per dichiarare il falso. Ripeto che, detto da un team di ricerca universitario e non da un troll su un forum, fa abbastanza effetto e, se fosse vero, sarebbe gravissimo.
Non è quello che hanno detto: stai ancora riportando l'OPINIONE di un ricercatore.

Ecco quello che hanno detto:
"But he also says that Intel at one point offered VUSec only a $40,000 bug bounty, accompanied by a $80,000 "gift"—which Giuffrida saw as an attempt to reduce the bounty amount cited publicly and thus the perceived severity of the MDS flaws."
Le parole sono abbastanza chiare: "Giuffrida saw". Cioè, LUI ha visto come un tentativo di ridurre la pericolosità delle falle.

E ancora:
"VUSec refused the offer of more total money in favor of a bounty that better reflected the severity of its findings, and it threatened to opt out of a bug bounty in protest. Intel changed its offer to the full $100,000."
E' VUSec che ha rifiutato l'offerta per un bounty "minore".

Non c'è stata, dunque, alcuna offerta appositamente mirata a ridurre la pericolosità delle falle.

E per essere assolutamente chiari, questo significa che NON c'è stata Intel che ha bussato alla porta della società dicendo: "se mi riduci la pericolosità delle falle ti pago un extra".

Quindi men che meno si può parlare di dichiarare il falso.

qualitativo (http://treccani.it/vocabolario/qualitativo/):
"Nel linguaggio scient. è spesso usato genericam., sempre in contrapp. a quantitativo, per indicare che un discorso, un ragionamento o anche un diagramma non sono appoggiati a precisi riferimenti numerici"

ok


La tua idea non combacia coi fatti e con la storia: è e rimane, per l'appunto, una tua idea.

E' la stessa cosa che penso anche io però rivolta alla tua di idea, che rimane solo una tua idea IMHO.


I fatti sono che all'epoca nessuno fosse a conoscenza di vulnerabilità di questo tipo.

I fatti sono che tutti i produttori di processori siano stati affetti, chi più, chi meno, da queste nuovissime vulnerabilità.

E' una tua idea, i fatti sono differenti: intel è vulnerabile a tutto, ha fatto cappotto negli ultimi 18 mesi, AMD solo ad una minima parte. Il tutto si riflette bene sull'impatto prestazonale delle mitigazioni: AMD ha una perdita minima mentre intel ha una perdita significativa, guadare per credere, dati e non idee da phoronix: https://www.phoronix.com/scan.php?page=article&item=mds-zombieload-mit&num=7

Se hai informazioni storiche che possano smentire tutto ciò (ossia: si sapeva già che si sarebbe andati in contro a questo tipo di vulnerabilità), non hai che da riportarle.

In mancanza, quindi direi proprio di no: no, Intel non ha sacrificato la sicurezza alle prestazioni.

Il dato è nei fatti, intel vulnerabile a tutto, amd vulnerabile a qualcosa, per approfondimenti vedi anche i test di phoronix sopra.

Intel ha scoperto queste nuove vulnerabilità DOPO che sono state scoperte Spectre e Meltdown, e quindi DOPO che è venuta alla luce questa NUOVA tipologia di vulnerabilità.

E' una tua idea che non potesse lavorare meglio prima, amd lo ha fatto e lo dimostrano i risultati, vedi di nuovo i test di phoronix di cui sopra.


Quindi ancora no: non potevano essere previsti problemi di sicurezza di questo tipo.

Anche qui, se hai informazioni che dimostrino che IN PASSATO (PRIMA di Spectre & Meltdown) se ne fosse già a conoscenza, non hai che da riportarle.

Previsti nei dettagli magari no, ma lasciare che ci possano essere informazioni sensibili "in giro" per la cpu accessibili senza privilegi è la differenza che c'è tra le cpu intel e amd e sicuramente non frutto del caso.


Come tutti. Chi più, chi meno.


Il tuo "come tutti" non è veritiero, vedi sopra

E' una coincidenza, invece, a meno che tu non porti le prove di cui sopra.

No, quel che PENSI (TU) non è una prova.

Peraltro proprio tu hai riportato qui, tempo fa, l'opinione di esperti di sicurezza che dimostrano il contrario di ciò che affermi.

I ricercatori pare la pensino pensano all'opposto di quello che scrivi ovvero sono convinti che intel abbia trascurato l'importanza delle scelte fatte per le proprie uarchitetture:

Intel's chip designers may have believed that a wrong guess, even one that serves up sensitive data, didn't matter. "It throws these results away," says VUSec's Guiffrida. "But we still have this window of vulnerability that we use to leak the information." https://www.wired.com/story/intel-mds-attack-speculative-execution-buffer/


Sfera di cristallo, e dunque coincidenza. A meno di prove in merito: vedi sopra.

Vedi sopra anche tu



Nessuno ha pagato un sovrapprezzo, infatti: chi ha comprato all'epoca NON poteva conoscere la situazione si sarebbe venuta a creare DOPO.

Fermo restando che non è affatto obbligatorio dover avere tutte le mitigazioni abilitate.

Quando intel ha immesso il 9900k sul mercato già sapeva: In a call with WIRED, Intel says its own researchers were the first to discover the MDS vulnerabilities last year, https://www.wired.com/story/intel-mds-attack-speculative-execution-buffer/
Il sovraprezzo sul 9700k non è quindi giustificato visto che l'HT è a serio rischio. Inoltre, come già detto, con windows 10 disabilitare le mitigazioni, oltre che potenzialmente pericoloso, è molto laborioso anche per via del fatto che gli update sono automatici e non possono essere gestiti diversamente

Non è quello che hanno detto: stai ancora riportando l'OPINIONE di un ricercatore.

Il ricercatore in questione parla a nome del suo team che non ha preso le distanze da quanto da lui affermato: mi chiedo che ragioni avrebbe per mentire...

Ecco quello che hanno detto:
"But he also says that Intel at one point offered VUSec only a $40,000 bug bounty, accompanied by a $80,000 "gift"—which Giuffrida saw as an attempt to reduce the bounty amount cited publicly and thus the perceived severity of the MDS flaws."
Le parole sono abbastanza chiare: "Giuffrida saw". Cioè, LUI ha visto come un tentativo di ridurre la pericolosità delle falle.

E ripeto la domanda perchè avrebbe mai dovuto fare un'affermazione del genere sul rifiutare del denaro ("gift") facile? Ti ricordo che non è Giuffrida che ha rifiutato quella somma ma tutta la VUsec come anche scritto sopra

E ancora:
"VUSec refused the offer of more total money in favor of a bounty that better reflected the severity of its findings, and it threatened to opt out of a bug bounty in protest. Intel changed its offer to the full $100,000."
E' VUSec che ha rifiutato l'offerta per un bounty "minore".

Appunto lo scrivi anche tu stesso ma forse non ne afferri il significato perchè la traduzione è questa: Il VUSEC ha rifiutato l'offerta di più soldi in favore di un premio che rispecchiava meglio la gravità delle sue scoperte, e ha minacciato di rinunciare alla "taglia" IN SEGNO DI PROTESTA. Intel ha cambiato la sua offerta fino a $ 100.000


Non c'è stata, dunque, alcuna offerta appositamente mirata a ridurre la pericolosità delle falle.
Ma se è scritto sopra che per tutto il team VUsec c'è stata!!!



E per essere assolutamente chiari, questo significa che NON c'è stata Intel che ha bussato alla porta della società dicendo: "se mi riduci la pericolosità delle falle ti pago un extra".

Ma è chiaro esattamente l'opposto di quello che scrvi, VUsec, se intel non avesse fatto poi un passo indietro, era pronta a protestare in modo compatto

Quindi men che meno si può parlare di dichiarare il falso.
Si può eccome :read:

seguo con interesse e scusate se mi intrometto...
...ma se non precisate alcune cose sarà difficile che possiate capire come stanno i fatti

se poi vi divertite a discutere fermate qui la lettura :D

punti senza un ordine d'importanza od altro
- precisate il tempo "prima" e "dopo" con delle date
- date indicative di quando sono stati iniziati i progetti da entrambe le case
- sebbene io non ne abbia bisogno e penso neanche voi, traducete in italiano le parti in inglese ed evidenziate le parti che ritenete rappresentino il vostro pensiero.

scusate se mi sono intromesso ma intuisco diversi equivoci/fraintendimenti, però non voglio cercare di chiarirli in prima persona :)

seguo con interesse e scusate se mi intrometto...
...ma se non precisate alcune cose sarà difficile che possiate capire come stanno i fatti

se poi vi divertite a discutere fermate qui la lettura :D

punti senza un ordine d'importanza od altro
- precisate il tempo "prima" e "dopo" con delle date
- date indicative di quando sono stati iniziati i progetti da entrambe le case
- sebbene io non ne abbia bisogno e penso neanche voi, traducete in italiano le parti in inglese ed evidenziate le parti che ritenete rappresentino il vostro pensiero.

scusate se mi sono intromesso ma intuisco diversi equivoci/fraintendimenti, però non voglio cercare di chiarirli in prima persona :)

Grazie per i suggerimenti,sono sicuramente interessanti e costruttivi :)

Purtroppo anche oggi non ho tempo, ma rispondo anche alla richiesta digieffe che è sensata e pertinente sulla questione.

In sintesi: la data che fa da spartiacque è quella della rivelazione di Meltdown (che è la prima vulnerabilità scoperta di tipo Side-band) da parte dei ricercatori. Ovviamente non pubblica, ma alle aziende coinvolte.

Pertanto tutte le considerazioni fatte PRIMA di tale data sono del tutto inutili e irrilevanti.

A meno che, come già detto, non venga DIMOSTRATO (ma coi FATTI, non con le parole) che fossero state pubblicate altre falle di tipo side-band come quelle che hanno scatenato il tutto, prima di quella data ovviamente.

Purtroppo anche oggi non ho tempo, ma rispondo anche alla richiesta digieffe che è sensata e pertinente sulla questione.

In sintesi: la data che fa da spartiacque è quella della rivelazione di Meltdown (che è la prima vulnerabilità scoperta di tipo Side-band) da parte dei ricercatori. Ovviamente non pubblica, ma alle aziende coinvolte.

Pertanto tutte le considerazioni fatte PRIMA di tale data sono del tutto inutili e irrilevanti.

A meno che, come già detto, non venga DIMOSTRATO (ma coi FATTI, non con le parole) che fossero state pubblicate altre falle di tipo side-band come quelle che hanno scatenato il tutto, prima di quella data ovviamente.

Il dato di fatto è che sugli attacchi side channel ci sono paper che risalgono anche ad oltre 20 anni fa e comunque molto più vecchi delle vulnerabilità specifiche emerse negli ultimi 18 mesi, riferimenti:
https://en.wikipedia.org/wiki/Side-channel_attack#cite_note-2
https://www.rambus.com/wp-content/uploads/2015/08/TimingAttacks.pdf
https://www.rambus.com/timing-attacks-on-implementations-of-diffie-hellman-rsa-dss-and-other-systems/
https://security.stackexchange.com/questions/81316/origin-of-side-channel-attacks
https://www.microsoft.com/en-us/research/publication/side-channel-leaks-in-web-applications-a-reality-today-a-challenge-tomorrow/?from=http%3A%2F%2Fresearch.microsoft.com%2Fpubs%2F119060%2Fwebappsidechannel-final.pdf

L'ulteriore dato di fatto è che intel è vulnerabile a tre famiglie di attacchi di questo tipo per intero: meltdown, spectre e MDS Attacks (che include zombieload e molti altri).
Amd è vulnerabile solo ad una parte delle criticità raggruppate sotto la definizione di spectre.
Intel ha perdite di prestazioni 5 volte superiori ad AMD, riferimenti:
https://www.tomshardware.com/news/intel-amd-mitigations-performance-impact,39381.html
https://www.extremetech.com/computing/291649-intel-performance-amd-spectre-meltdown-mds-patches

Aggiungo anche questo riferimento molto interessante ovvero un il titolo di un libro (Power Analysis Side Channel Attacks: The Processor Design-level Context) del 2010 che affronta l'argomento delle possibili vulnerabilità side-chennel sui processori e i possibili rimedi:
https://books.google.it/books?id=n9wsQwAACAAJ&redir_esc=y

Nella presentazione del libro c'è scritto testualmente: It also presents novel processor designs to combat against such attacks e stiamo parlando del 2010...

A questo link maggiori dettagli sul contenuto del libro: https://www.researchgate.net/publication/267861208_Power_Analysis_Side_Channel_Attacks_The_Processor_Design-level_Context

Tutti i link riportati (eccetto uno) parlano della stessa problematica: attacco di tipo side channel riguardo all'IMPLEMENTAZIONE di ALGORITMI crittografici. Addirittura alcuni link puntano alla stessa identica fonte.
Un solo link parla di attacchi side channel "web", ma non ci sono sufficienti dettagli per capire di cosa si tratterebbe nello specifico. In ogni caso non c'è alcun riferimento alla problematica oggetto della discussione.

Infatti ti avevo chiesto di portare pubblicazioni su "falle di tipo side-band come quelle che hanno scatenato il tutto". Ossia vulnerabilità MICRO-ARCHITETTURALI che consentano di accedere a dati privilegiati (kernel, hypervisor, SMM) o di altri processi/thread.

Gli altri due link alla fine del secondo commento sono informazioni sulle attuali vulnerabilità, con le solite questioni quantitative e non qualitative, dunque ancora una volta non hanno nulla a che vedere con la questione di cui sopra, e quindi non li ho nemmeno aperti.

P.S. Da diversi anni ormai i microprocessori moderni implementano algoritmi come AES, DES, e RSA in hardware (fornendo apposite istruzioni), e quindi avendo sostanzialmente tempi di calcolo fissi. Dunque gli attacchi side-channel di cui parlano quei paper dovrebbero essere superati.

Rispondo sulle altre questioni.
Quando intel ha immesso il 9900k sul mercato già sapeva: In a call with WIRED, Intel says its own researchers were the first to discover the MDS vulnerabilities last year, https://www.wired.com/story/intel-mds-attack-speculative-execution-buffer/
Il sovraprezzo sul 9700k non è quindi giustificato visto che l'HT è a serio rischio. Inoltre, come già detto, con windows 10 disabilitare le mitigazioni, oltre che potenzialmente pericoloso, è molto laborioso anche per via del fatto che gli update sono automatici e non possono essere gestiti diversamente
Anche altri produttori di processori hanno continuato a commercializzare processori affetti da vulnerabilità che nel frattempo erano state scoperte.

Ti ricordo che Meltdown e Spectre sono state rese pubbliche (ai soli produttori di CPU) il 28 Luglio 2017. E questo NON ha fermato nessun produttore (né Intel né AMD né IBM né i vari vendor di SoC ARM) dalla successiva commercializzazione.

Invece da allora Intel è l'UNICA che abbia successivamente commercializzato processori con alcune mitigazioni hardware.
Il ricercatore in questione parla a nome del suo team che non ha preso le distanze da quanto da lui affermato: mi chiedo che ragioni avrebbe per mentire...

E ripeto la domanda perchè avrebbe mai dovuto fare un'affermazione del genere sul rifiutare del denaro ("gift") facile? Ti ricordo che non è Giuffrida che ha rifiutato quella somma ma tutta la VUsec come anche scritto sopra
Sì, e qual è il problema? Che parli da solo o a nome del team è del tutto indifferente, visto che ci lavora e che presumibilmente abbiano le stesse posizioni.

Inoltre non si tratta di menzogne. Lui ha semplicemente affermato di aver VISTO tale offerta come un tentativo di ridurre l'importanza della vulnerabilità. Dunque rimane una SUA opinione, e non c'è nessuna bugia in merito.

Che poi non è nemmeno chiaro per quale motivo tu abbia affermato che abbia mentito, perché non ce n'è traccia.
Appunto lo scrivi anche tu stesso ma forse non ne afferri il significato perchè la traduzione è questa: Il VUSEC ha rifiutato l'offerta di più soldi in favore di un premio che rispecchiava meglio la gravità delle sue scoperte, e ha minacciato di rinunciare alla "taglia" IN SEGNO DI PROTESTA. Intel ha cambiato la sua offerta fino a $ 100.000

Ma se è scritto sopra che per tutto il team VUsec c'è stata!!!

Ma è chiaro esattamente l'opposto di quello che scrvi, VUsec, se intel non avesse fatto poi un passo indietro, era pronta a protestare in modo compatto
E che c'entra questo col presunto tentativo di corruzione? Hai fatto bene a riportare la traduzione, perché è chiarissima, e dimostra come Intel NON abbia cercato di "corrompere" (allargando un po' il significato del termine) nessuno.

Questi i fatti:
- è stata scoperta MDS;
- Intel ha offerto un bounty minore + un bonus;
- VUSec ha rifiutato e ha preteso un bounty maggiore.

Questo, invece, un tentativo di "corruzione":
- vengo da te in segreto per parlare di una cosa;
- durante l'incontro ti dico: "senti, ho saputo che hai per le mani una cosa che mi creerebbe problemi. Facciamo che tu riduci l'importanza del problema, accettando un bounty minore. In cambio ti pago il favore con una donazione extra".

Se non fosse ancora chiaro, Intel non ha mai chiesto a VUSec di ridurre l'importanza del bounty, e di pagarle il disturbo per questo.
Si può eccome :read:
Solo nell'ipotesi di cui sopra, che però non c'è.

Infatti, e come già detto sopra, quelle riportate sono le OPINIONI di VUSec e di chi lavora per lei.

Tutti i link riportati (eccetto uno) parlano della stessa problematica: attacco di tipo side channel riguardo all'IMPLEMENTAZIONE di ALGORITMI crittografici. Addirittura alcuni link puntano alla stessa identica fonte.
Un solo link parla di attacchi side channel "web", ma non ci sono sufficienti dettagli per capire di cosa si tratterebbe nello specifico. In ogni caso non c'è alcun riferimento alla problematica oggetto della discussione.

Infatti ti avevo chiesto di portare pubblicazioni su "falle di tipo side-band come quelle che hanno scatenato il tutto". Ossia vulnerabilità MICRO-ARCHITETTURALI che consentano di accedere a dati privilegiati (kernel, hypervisor, SMM) o di altri processi/thread.

Gli altri due link alla fine del secondo commento sono informazioni sulle attuali vulnerabilità, con le solite questioni quantitative e non qualitative, dunque ancora una volta non hanno nulla a che vedere con la questione di cui sopra, e quindi non li ho nemmeno aperti.

P.S. Da diversi anni ormai i microprocessori moderni implementano algoritmi come AES, DES, e RSA in hardware (fornendo apposite istruzioni), e quindi avendo sostanzialmente tempi di calcolo fissi. Dunque gli attacchi side-channel di cui parlano quei paper dovrebbero essere superati.

Quello che volevo far capire è che le vulnerabilità di tipo side-channel attack sono tutt'altro che nuove e anche se non sono emerse per la prima volta sulle uarchitetture delle cpu, il meccanismo di funzionamento è quello.
Poteva essere un ottimo campanello di allarme per gli addetti ai lavori perchè è inutile crittare informazioni sensibilisu un computer se poi la cpu le rende accessibili ad utenti senza privilegi.
Bisogna poi considerare che tra intel ed AMD, come ampiamente documentato nei miei post precedenti, quella che è stata gravemente colpita è intel, amd poco o nulla. Io personalmente ne deduco che AMD ha fatto un lavoro molto migliore di intel sulla sicurezza. Poteva essere il contrario e invece no.

Rispondo sulle altre questioni.

Anche io



Anche altri produttori di processori hanno continuato a commercializzare processori affetti da vulnerabilità che nel frattempo erano state scoperte.

Ti ricordo che Meltdown e Spectre sono state rese pubbliche (ai soli produttori di CPU) il 28 Luglio 2017. E questo NON ha fermato nessun produttore (né Intel né AMD né IBM né i vari vendor di SoC ARM) dalla successiva commercializzazione.

Non hai colto il senso di quello che volevo dire: MDS attacks per essere mitigato adeguatamente, secondo google e secondo la UVsec deve essere disabilitato SEMPRE e anche secondo intel va disabilitato negli scenari più delicati e prima ancora di commercializzarlo intel lo sapeva bene che per rimediare a MDS attacks il 9900k ma anche tutte le altre cpu della serie 9 con HT avrebbero dovuto rinuciare all'HT. Però ha continuato lo stesso imperterrita a venderle ad un prezzo più alto per via di una funzione, l'HT, che di li a qualche mese sarebbe diventato pericoloso utilizzare sapendo bene, lo ripeto, quello che stava facendo ovvero vendere un motore 2000 turbo ad un prezzo maggiorato rispetto ai motori 2000 aspirati sapendo che dopo qualche mese il turbo non sarebbe più stato utilizzabile, pena il rischio di rimanere a piedi. Quindi non c'entra nulla col fatto che anche gli altri abbiano venduto cpu con vulnerabilità perchè le vulnerabilità in questione sono risolvibili con mitigazioni e non rinunciando all'SMT nel caso di AMD, cosa che sappiamo avere un altissimo impatto prestazionale negli scenari multithread.


Invece da allora Intel è l'UNICA che abbia successivamente commercializzato processori con alcune mitigazioni hardware.

Amd con Ryzen serie 2000 uscito ad aprile 2018 non ha fatto in tempo ad uscire con le mitigazioni in hardware per la piccola parte delle vulnerabilità che la riguardano mentre per mds attacks, per meltdown e per buona parte di spectre non ha bisogno di mitigazioni in harware perchè è completamente immune a differenza di intel che invece è soggetta a tutte le vulnerabilità e che comunque è uscita 6 mesi dopo con la serie 9 con alcune mitigazioni in hardware ma con la spada di Damocle enorme di MDS attacks. La serie Ryzen 3000 che arriverà a brevissimo avrà le mitigazioni in hardware anche per le poche vulnerabilità di AMD.


Sì, e qual è il problema? Che parli da solo o a nome del team è del tutto indifferente, visto che ci lavora e che presumibilmente abbiano le stesse posizioni.

Il problema è che mi era sembrato, leggendoti, che minimizzassi sostenendo che solo Giuffrida era di quell'idea, invece è tutto il team


Inoltre non si tratta di menzogne. Lui ha semplicemente affermato di aver VISTO tale offerta come un tentativo di ridurre l'importanza della vulnerabilità. Dunque rimane una SUA opinione, e non c'è nessuna bugia in merito.

Non è solo una SUA opinione, è l'opinione di TUTTO il Team di ricerca compatto, c'è una certa differenza tra uno e molti.
Che poi non è nemmeno chiaro per quale motivo tu abbia affermato che abbia mentito, perché non ce n'è traccia.


E che c'entra questo col presunto tentativo di corruzione? Hai fatto bene a riportare la traduzione, perché è chiarissima, e dimostra come Intel NON abbia cercato di "corrompere" (allargando un po' il significato del termine) nessuno.

Questi i fatti:
- è stata scoperta MDS;
- Intel ha offerto un bounty minore + un bonus;
- VUSec ha rifiutato e ha preteso un bounty maggiore.

Questo, invece, un tentativo di "corruzione":
- vengo da te in segreto per parlare di una cosa;
- durante l'incontro ti dico: "senti, ho saputo che hai per le mani una cosa che mi creerebbe problemi. Facciamo che tu riduci l'importanza del problema, accettando un bounty minore. In cambio ti pago il favore con una donazione extra".
Se non fosse ancora chiaro, Intel non ha mai chiesto a VUSec di ridurre l'importanza del bounty, e di pagarle il disturbo per questo.


Allora anche tu affermi che c'è stata tentata corruzione da parte di intel (tentativo poi finito male con tanto di solita figuraccia tipo i benchmark delle sue cpu con le mitigazioni che ha tentato di vietare) perchè i fatti che sono avvenuti sono i seguenti:
- intel fa un offerta economica complessivamente più alta rispetto allo standard stabilito in questi casi a patto che VUsec sminuisca la gravità delle nuove falle;
- VUsec rifiuta il maggior quantitativo di denaro per poter dire liberamente come stanno le cose secondo loro

ecco il testo in questione "VUSec refused the offer of more total money in favor of a bounty that better reflected the severity of its findings, and it threatened to opt out of a bug bounty in protest. Intel changed its offer to the full $100,000."


Solo nell'ipotesi di cui sopra, che però non c'è.

Infatti, e come già detto sopra, quelle riportate sono le OPINIONI di VUSec e di chi lavora per lei.

E dici poco? Parliamo di persone, molte, estremamente intelligenti, ricercatori universitari, senza nessun interesse economico e lo hanno dimostrato rifiutando la parte di denaro offertagli in più non dovuta, che all'improvviso fanno delle accuse molto gravi a intel, perchè?

Che strano... Windows e' solo aggiornabile fino alla 1709. Niente 1803 e 1809.

https://support.microsoft.com/it-it/help/4093836/summary-of-intel-microcode-updates

Non voglio interrompere l'interessante dialogo tra cdimauro e maxsin72 :)


ma per favore avrei una domanda da nubbio sulla questione. :O

Ora con la versione KB4100347 si arriva fino alla versione Windows 1803.
https://support.microsoft.com/en-us/help/4100347/intel-microcode-updates-for-windows-10-version-1803-and-windows-server
Ed immagino da qualche parte esista anche il link per le versioni successive di Windows....

Se non è possibile agire per l'aggiornamento del microcode della CPU perchè l'OS non è aggiornato a Windows 10 (ad esempio Windows 8.1 o Windows 7),

e nemmeno è possibile utilizzare Linux & derivati e dunque la procedura prevista dal thread [GUIDA] UPDATE MICROCODE CPU INTEL (https://www.hwupgrade.it/forum/showthread.php?t=2852280)

dunque per definizione i PC che hanno quegli OS non possono essere aggiornabili a livello microcode CPU per mitigare i rallentamenti dovuti agli aggiornamenti Spectre & Meltdown?

:confused:

Non voglio interrompere l'interessante dialogo tra cdimauro e maxsin72 :)


ma per favore avrei una domanda da nubbio sulla questione. :O

Ora con la versione KB4100347 si arriva fino alla versione Windows 1803.
https://support.microsoft.com/en-us/help/4100347/intel-microcode-updates-for-windows-10-version-1803-and-windows-server
Ed immagino da qualche parte esista anche il link per le versioni successive di Windows....

Se non è possibile agire per l'aggiornamento del microcode della CPU perchè l'OS non è aggiornato a Windows 10 (ad esempio Windows 8.1 o Windows 7),

e nemmeno è possibile utilizzare Linux & derivati e dunque la procedura prevista dal thread [GUIDA] UPDATE MICROCODE CPU INTEL (https://www.hwupgrade.it/forum/showthread.php?t=2852280)

dunque per definizione i PC che hanno quegli OS non possono essere aggiornabili a livello microcode CPU per mitigare i rallentamenti dovuti agli aggiornamenti Spectre & Meltdown?

:confused:

Per aggiornare i microcode del proprio bios, indipendentemente dall'OS utilizzato, io e altri in questo thread abbiamo usato UBU, di seguito il link https://www.win-raid.com/t154f16-Tool-Guide-News-quot-UEFI-BIOS-Updater-quot-UBU.html
UBU nell'ultima versione "contiene" già gli ultimi microcode disponibili.
Io non ho mai avuto problemi e, se non ricordo male, credo di aver già aggiornato 5 volte il microcode e flashato il bios altrettante volte con successo. Il rischio però è quello, se qualcosa dovesse andare storto, di flashare un bios corrotto con tutti i problemi che ne deriverebbero. Chi dovesse invece avere un dual bios non dovrebbe avere nulla da temere.

Grazie per la risposta, maxsin72.

Il rischio però è quello, se qualcosa dovesse andare storto, di flashare un bios corrotto con tutti i problemi che ne deriverebbero.

Quale sarebbe il problema di flashare ed ottenere un BIOS corrotto? La mia non è una mobo UEFI e nè dual BIOS .

Si può sempre tornare indietro ri-flashando con il tool di aggiornamento della mobo, no? :confused:

Che appunto non si avvia piú. Schermo nero, ventole che girano e nient'altro. UEFI o meno non cambia, l'unica salvezza sarebbe il dual BIOS, un chip di riserva (si trovano sulla baia ad esempio) o un programmer da utilizzare con un altro PC per riprogrammare il chip del BIOS.
Alcune mobo supportano il flash alla cieca inserendo il file del BIOS in una determinata porta USB (flashback mi pare si chiami) ma sono rare.

Che appunto non si avvia piú. Schermo nero, ventole che girano e nient'altro. UEFI o meno non cambia, l'unica salvezza sarebbe il dual BIOS, un chip di riserva (si trovano sulla baia ad esempio) o un programmer da utilizzare con un altro PC per riprogrammare il chip del BIOS.
Alcune mobo supportano il flash alla cieca inserendo il file del BIOS in una determinata porta USB (flashback mi pare si chiami) ma sono rare.


Grazie per la risposta, maxsin72.



Quale sarebbe il problema di flashare ed ottenere un BIOS corrotto? La mia non è una mobo UEFI e nè dual BIOS .

Si può sempre tornare indietro ri-flashando con il tool di aggiornamento della mobo, no? :confused:

Vedo che ti ha già risposto ottimamente Varg87 :)

Interessante risposta del VUsec su twitter: confermano che secondo loro le mitigazioni contro MDS Attacks non servono a niente se non si disabilita l'HT.
Ecco i tweets:

https://i.postimg.cc/63w6WYyQ/Screen-Hunter-414-Jun-15-11-27.jpg

While these vulnerabilities are serious on shared/cloud machines, the impact for desktop/server machines is limited, so meh. The mitigations are near-useless if you're going to leave HT enabled, so you might as well disable them (and make your machine faster)..

Tradotto:

Mentre queste vulnerabilità sono gravi su macchine condivise / cloud, l'impatto per macchine desktop / server è limitato, quindi meh. Le attenuazioni sono quasi inutili se si ha intenzione di lasciare attivato l'HT, quindi potresti anche disabilitarle (e rendere la tua macchina più veloce) ...

@Varg87 & maxsin72: grazie per le risposte.
Chiara la problematica del rischio aggiornamento microcode nel BIOS/UEFI.

Una cosa non capisco ancora (scusate): questi aggiornamenti al microcode permettono anche di recuperare velocità perduta a causa dei soli aggiornamenti di mitigazione di Windows o...completano solamente la protezione?

@Varg87 & maxsin72: grazie per le risposte.
Chiara la problematica del rischio aggiornamento microcode nel BIOS/UEFI.

Una cosa non capisco ancora (scusate): questi aggiornamenti al microcode permettono anche di recuperare velocità perduta a causa dei soli aggiornamenti di mitigazione di Windows o...completano solamente la protezione?

Il loro scopo primario è quello di mitigare le criticità di sicurezza poi è anche vero che sono uscitie nuove mitigazioni con un impatto inferiore sulle prestazioni come ad esempio retpoline. Complessivamente però si è avuta comunque una perdita di prestazioni.

Zen 2 (Ryzen serie 3000), che uscirà ad inizio luglio, sarà immune a Meltdown, Foreshadow, Spectre V3a, Lazy FPU, Spoiler e MDS Attacks. Mitigato in hardware Spectre V4 (Zen e Zen+ sono mitigati a livello di OS).
In confronto, la 9a generazione intel "Coffee Lake Refresh" ha bisogno sia di mitigazioni via software che sui microcode per Spectre V4, Spectre V3a, MDS Attacks e RIDL. Fonte: https://www.techpowerup.com/256478/amd-zen-2-has-hardware-mitigation-for-spectre-v4
Per non parlare poi della molto spinosa questione della necessità di disattivare l'HT almeno negli scenari più delicati.

Non ho ricevuto feedback su sta roba strana... giuro che se nessuno mi risponde non lo chiedo piu'... :)

Che strano... Windows e' solo aggiornabile fino alla 1709. Niente 1803 e 1809.

https://support.microsoft.com/it-it/help/4093836/summary-of-intel-microcode-updates


E' assurdo perche' la mitigazione precedente partiva lasciando fuori le versioni di Windows piu' vecchie, come e' giusto... prima metti a posto quelle piu' recenti, quelle piu' sicure E POI quelle piu' vecchie.
E intanto resto scoperto... boh...

Non ho ricevuto feedback su sta roba strana... giuro che se nessuno mi risponde non lo chiedo piu'... :)




E' assurdo perche' la mitigazione precedente partiva lasciando fuori le versioni di Windows piu' vecchie, come e' giusto... prima metti a posto quelle piu' recenti, quelle piu' sicure E POI quelle piu' vecchie.
E intanto resto scoperto... boh...

Non posso che confermare quello che vedi anche tu e trovarlo altrettanto inspiegabile visto che windows 10 si aggiorna automaticamente alle versioni più recenti e quindi non protette verso MDS Attacks. Io il nuovo microcode l'ho aggiornato con UBU tramite bios.

Il loro scopo primario è quello di mitigare le criticità di sicurezza poi è anche vero che sono uscitie nuove mitigazioni con un impatto inferiore sulle prestazioni come ad esempio retpoline. Complessivamente però si è avuta comunque una perdita di prestazioni.

Concordo sulla complessiva perdita di prestazioni ma la mia domanda era quella di capire se un aggiornamento a livello di microcode migliora la prestazioni rispetto alla perdita dovuta alle sole mitigazione via Windows security updates.

Zen 2 (Ryzen serie 3000), che uscirà ad inizio luglio, sarà immune a Meltdown, Foreshadow, Spectre V3a, Lazy FPU, Spoiler e MDS Attacks. Mitigato in hardware Spectre V4 (Zen e Zen+ sono mitigati a livello di OS).
Peccato che questa CPU se utilizzata in ambiente mission critical e relativo OS Windows, non è previsto il supporto da parte di Enterprise LTSC 2019, visto che quel silicon non esisteva alla data di rilascio.

Concordo sulla complessiva perdita di prestazioni ma la mia domanda era quella di capire se un aggiornamento a livello di microcode migliora la prestazioni rispetto alla perdita dovuta alle sole mitigazione via Windows security updates.

Da quello che ho capito anche gli aggiornamenti a livello di microcode riducono le prestazioni in modo significativo, poi, mano a mano che ne sono usciti di nuovi e sono stati ottimizzati, qualcosa sarà anche stato recuperato. Le mitigazioni che hanno l'impatto più contenuto sono quelle in hardware ovvero nel "silicio".


Peccato che questa CPU se utilizzata in ambiente mission critical e relativo OS Windows, non è previsto il supporto da parte di Enterprise LTSC 2019, visto che quel silicon non esisteva alla data di rilascio.

Se non ricordo male leggevo in giro qualcosa sul fatto che il loro supporto da parte di Microsoft su Windows sarebbe stato ufficializzato alla loro uscita.

... e intanto intel assume un altro ex-AMD, John Sell, https://www.bitsandchips.it/business/11826-intel-assume-john-sell-ex-amd-e-padre-del-soc-di-xbox-one che andrà ad occuparsi di "Security for Intel Architecture, Graphics, and Software".
A quanto pare intel ha voglia di fare sul serio per il futuro e cosa di meglio che chiamare a se gli ex-AMD come Keller, Sell e Koduri? :sofico:

Chiaro il discorso mitigazioni in hardware /silicio.



Se non ricordo male leggevo in giro qualcosa sul fatto che il loro supporto da parte di Microsoft su Windows sarebbe stato ufficializzato alla loro uscita.


maxsin72, se riesci a rintracciare la fonte di tale indiscrezioni, sarebbe molto gradita ave: ... anche perchè sarebbe un'eccezione rispetto alla regola sopra riportata e ripetuta anche da Microsoft in tempi relativamente recenti (proprio per scoraggiare l'uso della LTSB/LTSC).

Chiaro il discorso mitigazioni in hardware /silicio.




maxsin72, se riesci a rintracciare la fonte di tale indiscrezioni, sarebbe molto gradita ave: ... anche perchè sarebbe un'eccezione rispetto alla regola sopra riportata e ripetuta anche da Microsoft in tempi relativamente recenti (proprio per scoraggiare l'uso della LTSB/LTSC).

Se riesco a trovare dove l'ho letto posto sicuramente il link. In ogni caso è solo questione di aspettare ancora un pochino perchè tra poco più di 2 settimane ci sarà il lancio ufficiale di Zen 2 e sicuramente ne sapremo di più :)

Impatto mitigazioni su i5 8400 e 9400F, in alcuni scenari si perde anche il 50% di prestazioni:eek: https://www.phoronix.com/scan.php?page=article&item=intel-9400f-mitigations&num=1

@maxsin72: aspettiamo e vediamo se davvero avviene un'eccezione alle politiche supporto nuovi silicon. Mi sembrerebbe davvero strano che Microsoft facesse un passo indietro dopo tanto marketing (per usare una parola gentile) per scoraggiare l'uso della versione mission critical di Win10.

Non posso che confermare quello che vedi anche tu e trovarlo altrettanto inspiegabile visto che windows 10 si aggiorna automaticamente alle versioni più recenti e quindi non protette verso MDS Attacks. Io il nuovo microcode l'ho aggiornato con UBU tramite bios.

Hanno finalmente aggiornato.

edit: non hanno incluso il Sandy Bridge :muro:

Hanno finalmente aggiornato.

edit: non hanno incluso il Sandy Bridge :muro:
Ho visto che nell'elenco non c'è nemmeno il mio 4790k il cui microcodice è alla versione 0x27 che però ho già aggiornato a livello di bios con UBU. Spero solo che in pochi giorni provvedano ad aggiornare ancora :rolleyes:

Impatto mitigazioni su i5 8400 e 9400F, in alcuni scenari si perde anche il 50% di prestazioni:eek: https://www.phoronix.com/scan.php?page=article&item=intel-9400f-mitigations&num=1
Ma CHI dovrebbe sfruttare queste “falle”???

Ma CHI dovrebbe sfruttare queste “falle”???

Ovviamente nessuno, è tutto un gioco :D

è tutto un gombloddo per farmi passare ad AMD (e ci sono riusciti, a breve si intende). :ciapet:

è tutto un gombloddo per farmi passare ad AMD (e ci sono riusciti, a breve si intende). :ciapet:

:D :D :D caspita la pista del gombloddo non l'avevo considerata :sofico:

oracle sta proseguendo a implementare una soluzione alternativa (per linux) che consentirebbe di lasciare abilitato l'ht sugli intel. la chiama kernel address space isolation (in precendenza kvm address space isolation)

http://lkml.iu.edu/hypermail/linux/kernel/1907.1/03688.html

@maxsin72: aspettiamo e vediamo se davvero avviene un'eccezione alle politiche supporto nuovi silicon. Mi sembrerebbe davvero strano che Microsoft facesse un passo indietro dopo tanto marketing (per usare una parola gentile) per scoraggiare l'uso della versione mission critical di Win10.

Ci sono novità sul supporto della LTSC ai nuovi Zen2?

phoronix ha appena pubblicato una iniziale (dice integrerà ulteriormente) comparativa con una pletora di cpu sia intel sia amd, di due generazioni, confrontando l'impatto tra mitigazioni di default del kernel linux 5.2git accese/spente

è tutto bench sintetico (e su carichi per lo più single thread) ma cmq può dare delle indicazioni

da notare come per gli zen 2 le mitigazioni (che sono in hw) hanno cmq un certo impatto, e larabel ipotizza che sia perchè le mitigazioni attuali non 'distinguono' ancora

@maxsin72: aspettiamo e vediamo se davvero avviene un'eccezione alle politiche supporto nuovi silicon. Mi sembrerebbe davvero strano che Microsoft facesse un passo indietro dopo tanto marketing (per usare una parola gentile) per scoraggiare l'uso della versione mission critical di Win10.

Ci sono novità sul supporto della LTSC ai nuovi Zen2?

A quanto pare il supporto della LTSC c'è https://answers.microsoft.com/en-us/windows/forum/all/windows-10-ltsc-1809-fixed-the-scheduler-for-ryzen/8ca7847a-39ec-4b48-b5b6-d92016ed0f4a

per il mio NUC hanno rilasciato un ulteriore bios aggiornato
flasho ed effettivamente il microcode finalmente è cambiato in 368

riprovo lo speculation control , ma di retpoline ancora nulla
rispetto allo scorso bios è passata su true solo questa voce

https://i.postimg.cc/6pj3H8ct/micro.png

phoronix ha appena pubblicato una iniziale (dice integrerà ulteriormente) comparativa con una pletora di cpu sia intel sia amd, di due generazioni, confrontando l'impatto tra mitigazioni di default del kernel linux 5.2git accese/spente

è tutto bench sintetico (e su carichi per lo più single thread) ma cmq può dare delle indicazioni

da notare come per gli zen 2 le mitigazioni (che sono in hw) hanno cmq un certo impatto, e larabel ipotizza che sia perchè le mitigazioni attuali non 'distinguono' ancora

Ho visto anche io il test di Phoronix ed effettivamente i risultati non sono quelli che ci si aspetterebbe. Il dubbio che ho è che, in teoria, se sono presenti le mitigazioni in hardware quelle in software (efficaci anche su quelle cpu, vedi Ryzen serie 1000 e 2000, prive delle mitigazioni in hardware) non dovrebbero essere più necessarie. O sbaglio? :confused: E anche fosse necessario qualcosa a livello software per far funzionare le mitigazioni in hardware in modo corretto continuo a non spegarmi un impatto così importante su Zen 2. Ma il tempo forse mi/ci chiarirà le idee.

Interessante documento di IMB sul significativo impatto prestazionale delle mitigazioni su server intel su cui girano VM https://www-01.ibm.com/support/docview.wss?uid=ibm10958705

Link per microcodici per il "fai da te" :D con UBU, i più recenti sono stati aggiornati il 19/06 https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/tree/master/intel-ucode

A quanto pare il supporto della LTSC c'è https://answers.microsoft.com/en-us/windows/forum/all/windows-10-ltsc-1809-fixed-the-scheduler-for-ryzen/8ca7847a-39ec-4b48-b5b6-d92016ed0f4a

Grazie mille per il link.

In sostanza leggendo in rete Zen 2 funziona sulla LTSC però al momento il nuovo scheduler è appannaggio solo della 1903 e verrà rilasciato in futuro con un kb.

Ho trovato anche questo bench:

https://www.youtube.com/watch?v=5XMWS0_9gNo

Meno differenza nelle applicazioni reali rispetto ai bench sintetici in sostanza.

Grazie mille per il link.

In sostanza leggendo in rete Zen 2 funziona sulla LTSC però al momento il nuovo scheduler è appannaggio solo della 1903 e verrà rilasciato in futuro con un kb.

Ho trovato anche questo bench:

https://www.youtube.com/watch?v=5XMWS0_9gNo

Meno differenza nelle applicazioni reali rispetto ai bench sintetici in sostanza.

Di nulla :)

Stando a qua:

https://docs.microsoft.com/en-us/windows-hardware/design/minimum/windows-processor-requirements

il supporto al Ryzen 3xxx non è menzionato nè sulla build 1809 nè sulla 1903...

Però sulla 1903 direi che è assicurato dal fatto che la stessa AMD l'ha menzionata, e tutt'ora la consiglia, come versione di riferimento per via dei miglioramenti allo scheduler.

Ancora più interessante sarebbe sapere qual è lo stato delle mitigazioni di Windows se si trova un Ryzen 3xxx sotto. Online però non trovo niente e anche nei documenti ufficiali c'è confusione :muro:

i ryzen 2 dovrebbero essere già safe per buona parte delle vulnerabilità
casomai il 'problema' potrebbe essere sapere se alcune mitigazioni sw siano applicate lo stesso (anche se non necessarie) o meno

ps: forse era già quello che a cui alludevi, in caso sorry

i ryzen 2 dovrebbero essere già safe per buona parte delle vulnerabilità
casomai il 'problema' potrebbe essere sapere se alcune mitigazioni sw siano applicate lo stesso (anche se non necessarie) o meno

ps: forse era già quello che a cui alludevi, in caso sorry

Si, esatto. Sono curioso di vedere se Windows disabilita le mitigazioni software visto che sono inutili con un Ryzen 3 :)

ad esempio ad ora (qualche gg fa) il kernel linux (quello che conosco meglio) applica a tappeto, anche dove non serve quindi. ma senza dubbio a breve verrà implementato un meccanismo selettivo, che disabilita in caso di cpu safe

non sto seguendo ma se non ricordo male le mitigazioni sono disabilitabili anche in win, e in tal caso non dovrebbe essere difficile trovare qualche bench aggiro di r3000 vs win con mitigazioni on/off

Secondo Toms, google starebbe meditando di abbandonare intel per i propri server per passare ad AMD anche per via delle delle varie criticità che sono emerse. È infatti da ricordare che google ha disabilitato anche l'HT per ragioni di sicurezza sui suoi attuali server intel, con un massiccio impatto prestazionale https://amp.tomshardware.com/news/google-switch-intel-server-cpus-amd-epyc,40045.html

Oggi aggiungiamo una nuova falla fresca fresca, chissà se colpisce solo intel o anche AMD, comunque microsoft ha già pubblicato la patch:

https://www.punto-informatico.it/windows-nuova-patch-contro-spectre-meltdown/

AMD crede di non essere vulnerabile alla nuova criticità e questa è sicuramente una buona notizia https://www.phoronix.com/scan.php?page=news_item&px=CVE-2019-1125-SWAPGS

Inoltre per chi ha intel, chi ha installato gli aggiornamenti di luglio 2019 di windows 10, è già protetto https://support.microsoft.com/it-it/help/4072698/windows-server-speculative-execution-side-channel-vulnerabilities-prot

UPDATED su 6 agosto 2019:Il 6 agosto 2019 Intel ha rilasciato i dettagli di una vulnerabilità del kernel Windows. Questa vulnerabilità è una variante della vulnerabilità canale laterale esecuzione speculativa 1 variante Spectre e sia stata assegnata 2019-CVE-1125.

Il 9 luglio 2019 ci ha rilasciato gli aggiornamenti della protezione per il sistema operativo Windows per ridurre questo problema. Si noti che sono bloccati, la documentazione di questa attenuazione pubblicamente fino alla divulgazione del settore coordinato su Martedì 6 agosto 2019.

Clienti che dispongono di Windows Update attivata e applicata la protezione rilasciati il 9 luglio 2019 sono protetti automaticamente. Non è necessaria alcuna ulteriore configurazione.

Nota:Questa vulnerabilità non richiede un aggiornamento di microcodice dal produttore del dispositivo (OEM).

nb, da rimarcare che parrebbe che la mitigazione in oggetto, pur non richiedendo aggiornamento del ucode, abbia un ulteriore costo in prestazioni

vedremo i test che sta preparando phoronix (saranno solo lato linux ma daranno cmq un'idea)

nb, da rimarcare che parrebbe che la mitigazione in oggetto, pur non richiedendo aggiornamento del ucode, abbia un ulteriore costo in prestazioni

vedremo i test che sta preparando phoronix (saranno solo lato linux ma daranno cmq un'idea)

Purtroppo non poteva che essere così, chissà invece se la patch, pur non essendo necessaria nel loro caso, viene applicata anche ai sistemi AMD.
Mi chiedo poi come è messa la futura serie 10000 di intel.

non so come sia lo stato dell'arte rispetto al richiesto meccanismo che non applichi in caso di cpu non vulnerabile. non ricordo nemmeno se fosse una 'carenza' solo del kernel linux, o anche gli altri

lato intel non sono aggiornato, ma sarebbe strano facessero uscire cpu ancora vulnerabili, almeno a quelle note...

non so come sia lo stato dell'arte rispetto al richiesto meccanismo che non applichi in caso di cpu non vulnerabile. non ricordo nemmeno se fosse una 'carenza' solo del kernel linux, o anche gli altri

lato intel non sono aggiornato, ma sarebbe strano facessero uscire cpu ancora vulnerabili, almeno a quelle note...

Bisognerebbe capire se, nel momento in cui hanno finalizzato la serie 10000 (manca poco al lancio e credo che ormai il progetto sia definito da un po'), quest'ultima vulnerabilità era già nota o meno e, in caso affermativo, se hanno fatto in tempo ad agire sul "silicio".

e come si fa a sapere?
chi vivrà...

tra l'altro fosse finita qui la storia, sarebbe semplice...
intendo in modo super partes, che ritengo che farne questioni 'partigiane' sarebbe imho poco adeguato

e come si fa a sapere?
chi vivrà...

tra l'altro fosse finita qui la storia, sarebbe semplice...
intendo in modo super partes, che ritengo che farne questioni 'partigiane' sarebbe imho poco adeguato

In effetti non credo ci vorrà molto per saperne di più, il lancio della serie 10000 è previsto per l'ultimo trimestre del 2019.
E purtroppo c'è da aspettarsi, come scrivi anche tu giustamente, che non sia finita qui. Sulle questioni "partigiane", da consumatore, credo che sia corretto ragionare in modo da tutelare al massimo gli interessi dei consumatori. Questo secondo me significa poter avere una visione del quadro d'insieme che sia la più dettagliata possibile in modo da poter scegliere consapevolmente al meglio come impegnare i propri sudati guadagni.

Sulle questioni "partigiane", da consumatore, credo che sia corretto ragionare in modo da tutelare al massimo gli interessi dei consumatori. Questo secondo me significa poter avere una visione del quadro d'insieme che sia la più dettagliata possibile in modo da poter scegliere consapevolmente al meglio come impegnare i propri sudati guadagni.

in linea di principio concordo, ci mancherebbe.
tuttavia realisticamente, è altamente probabile che coloro i quali necessitano anche degli zerovirgola nelle prestazioni, siano anche già in grado di scegliere il prodotto più adatto.
quindi escludiamo bench, 5 frame al secondo in meno su centinaia, e altre essenzialità simili. mentre agli altri (quelli che non necessitano) cambia nulla
non resta poi molto, temo

o meglio, restano gli appassionati che ne discutono volentieri, se i toni sono pacati

vedremo i test che sta preparando phoronix (saranno solo lato linux ma daranno cmq un'idea)

ha pubblicato un primo roundup, ad ora l'impatto appare limitato se non ininfluente, circa 1% medio (che è praticamente a livello di tolleranza 'naturale') con un singolo picco del 5%

ha pubblicato un primo roundup, ad ora l'impatto appare limitato se non ininfluente, circa 1% medio (che è praticamente a livello di tolleranza 'naturale') con un singolo picco del 5%

Metto il link https://www.phoronix.com/scan.php?page=article&item=swapgs-spectre-impact&num=1

Per ora non mi è sembrato di vedere test sull'impatto della velocità degli SSD che sono quelli, insieme alle VM, dove l'impatto è maggiore. Del resto quelli di Phoronix sono già stati bravissimi a fornire dati in così poco tempo, basterà aspettare per ulteriori test.

vedremo
gli ssd li toglierei dal 'paniere' cmq, che se un calo si vede solo in un bench sintetico, e dove di banda ce n'è d'avanzo, non mi straccerei le vesti

nb che monto un nvme m.2 sulla macchina che uso, quindi non dico che non conta nulla, ma che non mi pare così significativo

ps: 'quelli' di phoronix mi sa che è sempre il solo larabell, che praticamente ha automatizzato tutto per fare i test, per quello fa presto

vedremo
gli ssd li toglierei dal 'paniere' cmq, che se un calo si vede solo in un bench sintetico, e dove di banda ce n'è d'avanzo, non mi straccerei le vesti

nb che monto un nvme m.2 sulla macchina che uso, quindi non dico che non conta nulla, ma che non mi pare così significativo

ps: 'quelli' di phoronix mi sa che è sempre il solo larabell, che praticamente ha automatizzato tutto per fare i test, per quello fa presto

Pensa invece che con le prime mitigazioni sul mio sistema in firma per diversi mesi i tempi di caricamento mi erano raddoppiati (ho avuto una perdita di prestazioni di circa il 60%), solo dopo che le mitigazioni hanno iniziato ad essere affinate sono tornato a livelli accettabili con una perdita di circa il 20% rispetto alla situazione originale.

d'accordo (anche se mi paiono percentuali esagerate) ma dato che la minestra è sempre la stessa, è probabile che le mitigazioni abbiano già una certa ottimizzazione basata sulla (ormai lunga...) esperienza passata. detta così ma non sarebbe strano.

fondamentalmente, nun ce fasciamo la testa prima di...

da tenere conto che sul tr di una memoria di massa impattano anche altri fattori, fs in primis, e può cambiare anche non poco tra uno e l'altro a seconda del tipo di lavoro. questo specie in ambito linux (lì li farà) dove di fs usabili stabilmente ce n'è una mezza dozzina abbondante. quindi da prendere con il beneficio del dubbio, come riproducibilità lato win

tra l'altro lato win è meno 'isolabile' una singola modifica, dato che è tutto chiuso

d'accordo (anche se mi paiono percentuali esagerate) ma dato che la minestra è sempre la stessa, è probabile che le mitigazioni abbiano già una certa ottimizzazione basata sulla (ormai lunga...) esperienza passata. detta così ma non sarebbe strano.

fondamentalmente, nun ce fasciamo la testa prima di...

da tenere conto che sul tr di una memoria di massa impattano anche altri fattori, fs in primis, e può cambiare anche non poco tra uno e l'altro a seconda del tipo di lavoro. questo specie in ambito linux (lì li farà) dove di fs usabili stabilmente ce n'è una mezza dozzina abbondante. quindi da prendere con il beneficio del dubbio, come riproducibilità lato win

tra l'altro lato win è meno 'isolabile' una singola modifica, dato che è tutto chiuso

Ti posso assicurare che non esagero, ho pubblicato tutti i test proprio in questo thread e prima che scoppiasse il caso avevo circa 90.000 IOPS, con le prime mitigazioni sono sceso sulle 40.000 per poi risalire intorno alle 75.000 e i tempi di caricamento di alcuni applicativi pesanti che uso spesso sono variati di conseguenza. In ogni caso non mi fascio la testa perchè almeno per un altro anno il 4790k me lo tengo :)

Ci si commuove quasi a vedere certi numeri dopo il periodo di magra dell'ultimo anno e mezzo. :sofico: :asd:

https://i.postimg.cc/sQX2X8ZM/Cattura.png (https://postimg.cc/sQX2X8ZM)

https://i.postimg.cc/R6DZnRcX/Cattura2.png (https://postimg.cc/R6DZnRcX)

:ciapet:

non metto in dubbio, è che penso che alcuni cali così marcati possano essere stati circoscritti a particolari combinazioni hw/sw, quindi non generalizzabili (anche se non trascurabili eh) lo scrivo da non 'winer' quindi certamente è a livello di sensazione

ad esempio, sarà confrontare mele con pere ma afaik nel sottobosco pinguino non ci sono stati casi del genere. pure qui non che segua punto-punto, che avrei anche di meglio da fare, cmq l'hardware sotto sempre quello è

btw, penso che la ricchezza di tool che benchmarkano sia una palla al piede, va a finire che si guardano solo quelli al posto di usare. estremizzo ovviamente, ma un pò come (visto che è passato varg, che ci si incrocia spesso nel thread di cosa si sta ascoltando :D) ascoltare solo come si sente piuttosto che ascoltare e basta

io sinceramente sono stato molto meglio sia da quando ho smesso di benchare costantemente, sia da quando ho smesso di frequentare il mondo cosiddetto audiofilo (cmq la xonar essence gò anca mi eh...)

I microcode per haswell sono disponibili già da un pezzo e, come già ripetuto più volte, per via di un'architettura meno recente subiscono maggiormente gli effetti negativi della patch al microcode. La versione 24 del microcode che è stabile e supera i problemi della versione 23 per il mio 4790K è stata rilasciata da intel addirittura il 21/01/2018 e resa disponibile ai comuni mortali il 12 marzo 2018:
https://s14.postimg.cc/6m24f01ap/Screen_Hunter_84_Mar._22_18.03.jpg

Ecco come sono cambiate le performance del mio SSD:
https://s14.postimg.cc/h8vxkjc1t/Screen_Hunter_88_Mar._23_23.04.jpg

https://s14.postimg.cc/qupi0c329/Screen_Hunter_89_Mar._25_01.07.jpg


Autoquoto un paio di miei test con l'impatto prestazionale dovuto all'aggiornamento dei primi microcode usciti.

Ci si commuove quasi a vedere certi numeri dopo il periodo di magra dell'ultimo anno e mezzo. :sofico: :asd:

https://i.postimg.cc/sQX2X8ZM/Cattura.png (https://postimg.cc/sQX2X8ZM)

https://i.postimg.cc/R6DZnRcX/Cattura2.png (https://postimg.cc/R6DZnRcX)

:ciapet:

Apperò abbiamo messo insieme un bel sistemino bello reattivo ne :D

non metto in dubbio, è che penso che alcuni cali così marcati possano essere stati circoscritti a particolari combinazioni hw/sw, quindi non generalizzabili (anche se non trascurabili eh) lo scrivo da non 'winer' quindi certamente è a livello di sensazione

ad esempio, sarà confrontare mele con pere ma afaik nel sottobosco pinguino non ci sono stati casi del genere. pure qui non che segua punto-punto, che avrei anche di meglio da fare, cmq l'hardware sotto sempre quello è

btw, penso che la ricchezza di tool che benchmarkano sia una palla al piede, va a finire che si guardano solo quelli al posto di usare. estremizzo ovviamente, ma un pò come (visto che è passato varg, che ci si incrocia spesso nel thread di cosa si sta ascoltando :D) ascoltare solo come si sente piuttosto che ascoltare e basta

io sinceramente sono stato molto meglio sia da quando ho smesso di benchare costantemente, sia da quando ho smesso di frequentare il mondo cosiddetto audiofilo (cmq la xonar essence gò anca mi eh...)

Si si certo, ovviamente mi riferivo al mio caso ma ho avuto modo di vedere in rete che non era poi così isolato. Comunque vivo sereno e per quello che faccio col computer non mi faccio problemi. E' solo che mi piace parlarne e avere i dati sottomano e quando trovo persone come te o Varg o altri con cui è piacevole farlo e mi diverto :)

Pagina ufficiale di AMD con l'aggiornamento per SWAPGS https://www.amd.com/en/corporate/product-security

una questione non direttamente legata ma che ha ramificazioni anche su sicurezza e capacità di patchare senza limiti di tempo a livello bios

sembrano sempre meno remote implementazioni open a tal riguardo, o per lo meno in ambito server per ora, che si spera si espanda più sotto...

sarebbe veramente un altro livello di gestibilità...

Caspita negli USA fanno proprio sul serio :D , hanno addirittura un sito governativo che segue tutte le vulnerabilità "tecnologiche" https://www.us-cert.gov/ncas/current-activity/2019/08/06/swapgs-spectre-side-channel-vulnerability

Se riesco a trovare dove l'ho letto posto sicuramente il link. In ogni caso è solo questione di aspettare ancora un pochino perchè tra poco più di 2 settimane ci sarà il lancio ufficiale di Zen 2 e sicuramente ne sapremo di più :)

Ci sono novità sul supporto della LTSC ai nuovi Zen2?

A quanto pare il supporto della LTSC c'è https://answers.microsoft.com/en-us/windows/forum/all/windows-10-ltsc-1809-fixed-the-scheduler-for-ryzen/8ca7847a-39ec-4b48-b5b6-d92016ed0f4a


@maxsin72: non riesco ad interpretare quel link come supporto della LTSC per Zen2 :eek: ma semplicemente la promessa di rendere noto l'elenco delle patch disponibili per le diverse CPU:

"There has been no update yet regarding the path for Ryzen CPU users for LTSC but it seems like ever since the E3 conference, there will be an update on patches for all the CPU users for different brands."

E questo 2 mesi e mezzo fa; da allora non vedo updates in quel thread da parte di Tony1125. ( a parte che quel pollo ha scritto "I have LTSC for gaming as I cannot stand Pro or Home, sorry." :muro: )

Grazie mille per il link.

In sostanza leggendo in rete Zen 2 funziona sulla LTSC però al momento il nuovo scheduler è appannaggio solo della 1903 e verrà rilasciato in futuro con un kb.

@ThEbEsT'89: potresti linkare la fonte per favore?

@maxsin72: non riesco ad interpretare quel link come supporto della LTSC per Zen2 :eek: ma semplicemente la promessa di rendere noto l'elenco delle patch disponibili per le diverse CPU:

"There has been no update yet regarding the path for Ryzen CPU users for LTSC but it seems like ever since the E3 conference, there will be an update on patches for all the CPU users for different brands."

E questo 2 mesi e mezzo fa; da allora non vedo updates in quel thread da parte di Tony1125. ( a parte che quel pollo ha scritto "I have LTSC for gaming as I cannot stand Pro or Home, sorry." :muro: )




In effetti le informazioni non abbondano per niente però, stando ai link sotto riportati, il supporto con la 1903 dovrebbe esserci (un utente di reddit afferma i usarlo con il 3900x):

https://www.reddit.com/r/Amd/comments/ctwexo/anybody_running_windows_10_ltsc_2019_and_a_3900x/

E sempre su reddit parlano di compatibilità con il 3900x: https://old.reddit.com/r/Windows10LTSC/wiki/incompatibility#wiki_hardware_compatibility

Comunque credo sia al massimo una questione di tempo perchè Zen 2 sembra vendere molto bene e microsoft dovrà provvedere di conseguenza.

Comunque credo sia al massimo una questione di tempo perchè Zen 2 sembra vendere molto bene e microsoft dovrà provvedere di conseguenza.

Ti ringrazio per i link a reddit :mano: ma pensi che Microsoft solo perchè una CPU vende bene si mette a ridiscutere il supporto annunciato riguardo la filosofia adottata sino ad esso sui silicon e per di più verso la LTSC riguardo la quale cerca in ogni modo di scoraggiarne l'utilizzo? :O

Dopotutto anche su reddit un utente dice solo che lo sta usando ma di conferme che lo scheduler sia ottimizzato per quel silicon non ne vedo anche perchè lo è solo per la 1903 mentre la LTSC 2019 è solo 1809..

Quel performance hit (https://old.reddit.com/r/Piracy/comments/cd5kmv/windows_10_may_update_vs_windows_ltsc/ets4oeu/) è riportato solo per il benchmark 3DMark; non ho idea quanto possa inficiare in altre situazioni sia in termini di performance pure che di stabilità.

Ti ringrazio per i link a reddit :mano: ma pensi che Microsoft solo perchè una CPU vende bene si mette a ridiscutere il supporto annunciato riguardo la filosofia adottata sino ad esso sui silicon e per di più verso la LTSC riguardo la quale cerca in ogni modo di scoraggiarne l'utilizzo? :O

Dopotutto anche su reddit un utente dice solo che lo sta usando ma di conferme che lo scheduler sia ottimizzato per quel silicon non ne vedo anche perchè lo è solo per la 1903 mentre la LTSC 2019 è solo 1809..

Quel performance hit (https://old.reddit.com/r/Piracy/comments/cd5kmv/windows_10_may_update_vs_windows_ltsc/ets4oeu/) è riportato solo per il benchmark 3DMark; non ho idea quanto possa inficiare in altre situazioni sia in termini di performance pure che di stabilità.

Già la prossima versione di windows 10 sarà finalmente ottimizzata per il multicore spinto, mi riesce difficile non pensare che, prima o poi, microsoft provvederà ad ottimizzare al meglio la LTSC anche per Ryzen :)

Ma la prossima versione non va a ritroso con il channel Long Term: quello rimane 1809 fino alla prossima release, magari nel 2021. Come la 1607 rimane tale fino al 2026.


Certo, la LTSC 2019 v 1809 sarà supportata fino al 2029 ma questo non significa che venga infranta la regola dei silicon supportati esistenti alla data del rilascio, rispettata nel 2015 e nel 2016 del channel Long Term Service. Quindì sì, certamente, la prossima versione LTSC presumibilmente nel 2021, supporterà il Ryzen Gen 2, ma appunto si parla di altri due anni... quando ci sarà a quel punto magari anche lo Zen 3. E se lo Zen 3 dovesse uscire dopo, stesso discorso...

Attualmente la 1809 esiste già da 12 dei 30 mesi concessi alle versioni rilasciate solo nel periodo 'Fall' prima che vengano dismesse (decisione presa proprio a partire dalla 1809), contro i 18 mesi standard.

Ed è tutto da dimostrare che Microsoft ed il suo tirannico modello WaaS abbia convenienza ad ottimizzare una versione non up-to-date come la 1809, cosa che ritarderebbe l'adozione del 1903 (e successive) solo per far piacere ad AMD per via di una specifica linea di CPU. Intel potrebbe aver qualcosa da dire e chiedere lo stesso per altre specifiche CPU ed il tutto per accontentare l'1/2% delle piattaforme Windows 10?... Dubito. :O

Ma la prossima versione non va a ritroso con il channel Long Term: quello rimane 1809 fino alla prossima release, magari nel 2021. Come la 1607 rimane tale fino al 2026.


Certo, la LTSC 2019 v 1809 sarà supportata fino al 2029 ma questo non significa che venga infranta la regola dei silicon supportati esistenti alla data del rilascio, rispettata nel 2015 e nel 2016 del channel Long Term Service. Quindì sì, certamente, la prossima versione LTSC presumibilmente nel 2021, supporterà il Ryzen Gen 2, ma appunto si parla di altri due anni... quando ci sarà a quel punto magari anche lo Zen 3. E se lo Zen 3 dovesse uscire dopo, stesso discorso...

Attualmente la 1809 esiste già da 12 dei 30 mesi concessi alle versioni rilasciate solo nel periodo 'Fall' prima che vengano dismesse (decisione presa proprio a partire dalla 1809), contro i 18 mesi standard.

Ed è tutto da dimostrare che Microsoft ed il suo tirannico modello WaaS abbia convenienza ad ottimizzare una versione non up-to-date come la 1809, cosa che ritarderebbe l'adozione del 1903 (e successive) solo per far piacere ad AMD per via di una specifica linea di CPU. Intel potrebbe aver qualcosa da dire e chiedere lo stesso per altre specifiche CPU ed il tutto per accontentare l'1/2% delle piattaforme Windows 10?... Dubito. :O

Mi riferivo a questa notizia e alla capacità della 19H2 di sfruttare i core che raggiungono il clock più alto https://www.tomshw.it/hardware/windows-10-19h2-uso-core-migliori-cpu/

Tutto bello, interessante soprattutto per CPU di fascia alta magari da overcloccare ma purtroppo il 19H2 ovvero versione 1909 è un tema che non riguarda la LTSC 2019 versione 1809 che rimarrà tale fino alla successiva LTSC presumibilmente nel 2021 e dunque la riflessione riguardante il supporto per le CPU Ryzen 2 cade nel vuoto ancora. Quello, il 2021, sarà il probabile prima o poi, purtroppo per il canale di lungo termine.

Tutto bello, interessante soprattutto per CPU di fascia alta magari da overcloccare ma purtroppo il 19H2 ovvero versione 1909 è un tema che non riguarda la LTSC 2019 versione 1809 che rimarrà tale fino alla successiva LTSC presumibilmente nel 2021 e dunque la riflessione riguardante il supporto per le CPU Ryzen 2 cade nel vuoto ancora. Quello, il 2021, sarà il probabile prima o poi, purtroppo per il canale di lungo termine.

Capisco, spero però non vada così come tu dici.
Se AMD dovesse continuare a guadagnare quote di mercato sia nel mainstream che soprattutto nel mondo professionale, per microsoft adeguare anche la LTSC alle mutate esigenze del mercato dovrebbe essere un passaggio obbligato.

Intel sta lavorando a SAPM ovvero ad un nuovo sistema di mitigazione, pontenzialmente funzionante anche contro future criticità, che dovrebbe avere un impatto prestazionale inferiore rispetto a quello delle attuali mitigazioni:

https://www.techpowerup.com/259746/intels-storm-presents-sapm-paper-on-hardware-based-protection-against-side-channel-execution-flaws

https://www.tomshardware.com/news/intel-sapm-spectre-cpu-hardware-mitigation-security,40529.html

non ho letto il white paper, anche perchè non lo capirei completamente, ma da quello che mi pare di avere inteso si tratta quasi di un 'nero su bianco di un brainstorming' (virgolette...)
non è stata ancora 'validata' come tecnica, e ci andrà credo ancora qualche anno, perchè eventualmente appaia nei chip. fanno in tempo ad apparirne altre :D

battuta per carità, anche se mi pare il minimo che si stiano spremendo al massimo le meningi siliconiche, dopo tutto l'ambaradam

Capisco, spero però non vada così come tu dici.
Se AMD dovesse continuare a guadagnare quote di mercato sia nel mainstream che soprattutto nel mondo professionale, per microsoft adeguare anche la LTSC alle mutate esigenze del mercato dovrebbe essere un passaggio obbligato.

Ecco, diciamo che è una speranza :sperem: ma che è legata a quell' 1/2% di LTSC tra l'altro fortemente osteggiato dalla stessa Microsoft, quindi a mio avviso altamente improbabile anche perchè rischierebbe di creare un precedente AMD vs Intel ed eventuale pretesa anche di quest'ultima di vedersi supportare dei silicon post-rilascio delle LTSC.
Per me Microsoft risponde: "vuoi il supporto dello scheduler ottimizzato per AMD Ryzen 2? Fai il downgrade da LTSC al channel Enterprise ed aggiorna Windows 10 all'ultima versione disponibile". :O

E la risposta per la LTSC per il 2020 è già nota anche a livello del software di punta in ambito Microsoft, ovvero Office : "vuoi il supporto per Office 365ProPlus che ha in dotazione anche tutti i vari add-on di Power BI (che è tra le c.d. app desktop di Office) che lo standard Office 2019 non offre in nessuna configurazione Windows? Passa ad una versione di Windows 10 che supporti Office 365 ProPlus e... la LTSC 2019 non lo supporterà (https://support.microsoft.com/it-it/help/4076504/announcement-office-system-requirements)".
https://www.reddit.com/r/sysadmin/comments/8nt4bk/per_ms_windows_10_ltscltsb_will_no_longer_support/

E qui stiamo parlando di software di Microsoft che gira su Os di Windows con un market share ben superiore all'1/2%... comprenderai dunque il mio scettiscismo nel vedere Microsoft rompere la regola dei silicon.

Riferimento alle CPU supportate dalle varie versioni di Windows:
https://docs.microsoft.com/en-us/windows-hardware/design/minimum/windows-processor-requirements

Ecco, diciamo che è una speranza :sperem: ma che è legata a quell' 1/2% di LTSC tra l'altro fortemente osteggiato dalla stessa Microsoft, quindi a mio avviso altamente improbabile anche perchè rischierebbe di creare un precedente AMD vs Intel ed eventuale pretesa ache di quest'ultima di vedersi supportare dei silicon post-rilascio delle LTSC.
Per me Microsoft risponde: "vuoi il supporto dello scheduler ottimizzato per AMD Ryzen 2? Fai il downgrade da LTSC al channel Enterprise ed aggiorna Windows 10 all'ultima versione disponibile". :O

E la risposta per la LTSC per il 2020 è già nota anche a livello del software di punta in ambito Microsoft, ovvero Office : "vuoi il supporto per Office 365ProPlus che ha in dotazione anche tutti i vari add-on di Power BI (che è tra le c.d. app desktop di Office) che lo standard Office 2019 non offre in nessuna configurazione Windows? Passa ad una versione di Windows 10 che supporti Office 365 ProPlus e... la LTSC 2019 non lo supporterà (https://support.microsoft.com/it-it/help/4076504/announcement-office-system-requirements)".
https://www.reddit.com/r/sysadmin/comments/8nt4bk/per_ms_windows_10_ltscltsb_will_no_longer_support/

E qui stiamo parlando di software di Microsoft che gira su Os di Windows con un market share ben superiore all'1/2%... comprenderai dunque il mio scettiscismo nel vedere Microsoft rompere la regola dei silicon.

Si stava meglio, e decisamente, senza gli aggiornamenti continui introdotti con windows 10. Oggi dire di avere su win10 non vuol dire nulla, problemi sw e hw a non finire.

non ho letto il white paper, anche perchè non lo capirei completamente, ma da quello che mi pare di avere inteso si tratta quasi di un 'nero su bianco di un brainstorming' (virgolette...)
non è stata ancora 'validata' come tecnica, e ci andrà credo ancora qualche anno, perchè eventualmente appaia nei chip. fanno in tempo ad apparirne altre :D

battuta per carità, anche se mi pare il minimo che si stiano spremendo al massimo le meningi siliconiche, dopo tutto l'ambaradam

Esatto, sono ancora in una fase iniziale ma credo sia un progetto interessante a condizione che abbia uno sviluppo sufficientemente veloce ovvero non oltre i 6/9 mesi. Vedremo :)

Ecco, diciamo che è una speranza :sperem: ma che è legata a quell' 1/2% di LTSC tra l'altro fortemente osteggiato dalla stessa Microsoft, quindi a mio avviso altamente improbabile anche perchè rischierebbe di creare un precedente AMD vs Intel ed eventuale pretesa ache di quest'ultima di vedersi supportare dei silicon post-rilascio delle LTSC.
Per me Microsoft risponde: "vuoi il supporto dello scheduler ottimizzato per AMD Ryzen 2? Fai il downgrade da LTSC al channel Enterprise ed aggiorna Windows 10 all'ultima versione disponibile". :O

E la risposta per la LTSC per il 2020 è già nota anche a livello del software di punta in ambito Microsoft, ovvero Office : "vuoi il supporto per Office 365ProPlus che ha in dotazione anche tutti i vari add-on di Power BI (che è tra le c.d. app desktop di Office) che lo standard Office 2019 non offre in nessuna configurazione Windows? Passa ad una versione di Windows 10 che supporti Office 365 ProPlus e... la LTSC 2019 non lo supporterà (https://support.microsoft.com/it-it/help/4076504/announcement-office-system-requirements)".
https://www.reddit.com/r/sysadmin/comments/8nt4bk/per_ms_windows_10_ltscltsb_will_no_longer_support/

E qui stiamo parlando di software di Microsoft che gira su Os di Windows con un market share ben superiore all'1/2%... comprenderai dunque il mio scettiscismo nel vedere Microsoft rompere la regola dei silicon.

In effetti, da quello che scrivi, capisco bene i tuoi dubbi e capisco che a volte le politiche commerciali delle grandi multinazionali del settore siano incomprensibili. :confused: Una volta di più non ci resta che aspettare :what:

effetti collaterali sparsi, diciamo...
leggo che il tool per aggiornare su linux i microcode tornerà ad operare parallelamente su tutti i core, invece che in modo seriale.
il tutto dopo svariate lamentele di chi gestisce cloud server e affini, che dato l'elevato numero di core vengono molto penalizzati dall'operazione

Sembra che SAPM potrà essere una soluzione in hardware che lavorerà direttamente dalla memoria (cache?) dei futuri processori intel. Quindi chi ha una cpu "vecchia" si tiene tutte le mitigazioni :D

Ecco un paio di articoli in italiano:

https://www.tomshw.it/hardware/sapm-intel-memoria-contro-attacchi-esecuzione-speculativa/

https://www.ilsoftware.it/articoli.asp?tag=Intel-SAPM-una-memoria-per-scongiurare-attacchi-Meltdown-e-Spectre_20028

Dopo la mitigazione delle vulnerabilità più recenti con i vari windows update ho avuto ancora una perdita di circa il 10% sulle IOPS rispetto ai valori che ero riuscito a recuperare con retpoline.

Test recente:

https://i.postimg.cc/2j4WHdZq/Screen-Hunter-441-Oct-10-23-19.jpg


Test vecchio dopo l'aggiormento con retpoline:

https://s14.postimg.cc/h8vxkjc1t/Screen_Hunter_88_Mar._23_23.04.jpg

:muro:

I vari Windows funzionavano ancora troppo bene su hw vecchio; quale modo migliore per forzare il rinnovo verso nuove macchine? :O

Che release esattamente di Windows 10 e se possibile, ricordi quale batch di aggiornamenti?

:muro:

I vari Windows funzionavano ancora troppo bene su hw vecchio; quale modo migliore per forzare il rinnovo verso nuove macchine? :O

Che release esattamente di Windows 10 e se possibile, ricordi quale batch di aggiornamenti?

Devo guardare meglio a casa per le esatte release ma il calo prestazionale l'ho avuto dopo che sono state implementate le mitigazioni per MDS, mentre il dato precedente era quello relativo all'introduzione di retpoline che mi aveva fatto recuperare la gran parte delle prestazioni che invece, con le prime mitigazioni, si erano più che dimezzate.

Comprendo. Siamo alle soglie della 1909 che in quanto 'Fall' release nelle licenze enterprise significa poter sospendere per 30 mesi gli aggiornamenti, in pratica una semi-LTSC.

Tienici aggiornati riguardo questi benchmark se passi alla 1909 che dovrebbe essere una piccolo salto di enablements (https://www.hwupgrade.it/forum/showpost.php?p=46426211&postcount=39635)rispetto alla 1903 della scorsa tarda primavera.

Comprendo. Siamo alle soglie della 1909 che in quanto 'Fall' release nelle licenze enterprise significa poter sospendere per 30 mesi gli aggiornamenti, in pratica una semi-LTSC.

Tienici aggiornati riguardo questi benchmark se passi alla 1909 che dovrebbe essere una piccolo salto di enablements (https://www.hwupgrade.it/forum/showpost.php?p=46426211&postcount=39635)rispetto alla 1903 della scorsa tarda primavera.

Senz'altro farò dei test e pubblicherò i dati :)

Finalmente (erano pronti già da maggio per chi sa utilizzare applicazioni come UBU) su windows 10 sono arrivati i microcode con le ultime mitigazioni anche per Haswell https://www.tomshw.it/hardware/cpu-intel-haswell-un-update-di-windows-10-protegge-dalle-falle-mds/

Dopo aver utilizzato per piú di 3 anni la stessa installazione sul vecchio PC con 3570k, ora adibito ad altro utilizzo, sabato ho deciso di dare una bella pulita facendo una nuova installazione con precedente secure erase su quel PC.
Rispetto all'installazione precedente ho recuperato piú di 10000 punti su Magician sia in lettura che in scrittura nel test degli IOPS, in sequenziale qualche punto ma poca roba. Chiaramente rispetto alla situazione pre Spectre mancano all'appello quei 20-30K punti.

Ottima occasione per passare a Ryzen

Dopo aver utilizzato per piú di 3 anni la stessa installazione sul vecchio PC con 3570k, ora adibito ad altro utilizzo, sabato ho deciso di dare una bella pulita facendo una nuova installazione con precedente secure erase su quel PC.
Rispetto all'installazione precedente ho recuperato piú di 10000 punti su Magician sia in lettura che in scrittura nel test degli IOPS, in sequenziale qualche punto ma poca roba. Chiaramente rispetto alla situazione pre Spectre mancano all'appello quei 20-30K punti.

Ti confermo grossomodo la stessa situazione per il PC in firma.

https://www.tomshw.it/hardware/falle-cpu-intel-sviluppatore-linux-problema-attuale/

Niente di nuovo.

https://www.tomshw.it/hardware/falle-cpu-intel-sviluppatore-linux-problema-attuale/

Niente di nuovo.

gli è crashato il server? :D

Esatto. :asd:
Quando l'ho postato era raggiungibile.

https://www.ilsoftware.it/articoli.asp?tag=Nuova-vulnerabilita-nei-processori-Intel-ZombieLoad-2_20250
In arrivo il DLC ambientato durante la Grande Guerra. :asd:

https://www.ilsoftware.it/articoli.asp?tag=Nuova-vulnerabilita-nei-processori-Intel-ZombieLoad-2_20250
In arrivo il DLC ambientato durante la Grande Guerra. :asd:

:doh: La cosa devastante è che riguarda tutte le cpu da Haswell fino a Cascade Lake https://wccftech.com/intel-cpus-from-haswell-to-cascade-lake-vulnerable-to-zombieload-v2/ :muro: Quindi anche le cpu di intel più recenti sono vulnerabili. Per AMD invece nessun problema. Adesso vediamo se buttano fuori il nuovo microcode così da aggiornarlo subito con UBU altrimenti passeranno mesi prima che il microde tramite windows 10 venga aggiornato :muro:

In realtà c'è giá il fix software

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-11135

anche per il pinguino c'è già la patch per il kernel (costo in prestazioni in via di valutazione)
se non ho letto male l'info era sotto embargo e solo alla disponibilità del fw correttivo è stata resa pubblica

btw c'entra parzialmente non essendo vulnerabilità diretta, ma c'è da aggiungere il contemporaneo fix per il bug 'jcc erratum', da skylake in poi se non ho capito male, un altro 4% di costo da aggiungere (sempre via bench sintetici quindi precisione non assoluta, ma cmq qualcosa si)

https://www.ilsoftware.it/articoli.asp?tag=Vulnerabilita-nei-processori-Intel-come-attivare-le-protezioni_20256

dagli iniziali test di larabel, anche su linux l'impatto delle nuove mitigazioni con le TSX (Transactional Synchronization Extensions) disabilitate, sembra pressochè nullo,
mentre schizza ad un non marginale 8% medio abilitandole

in pratica ad ora sembra apparire ampiamente conveniente lasciare disabilitato il parametro e per non saper leggere nè scrivere applicare le mitigazioni, che così facendo sono 'gratis'

In realtà c'è giá il fix software

https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-11135

Ti ringrazio per l'info, mi sono accorto infatti che è stato installato il fix con il Windows update più recente.

dagli iniziali test di larabel, anche su linux l'impatto delle nuove mitigazioni con le TSX (Transactional Synchronization Extensions) disabilitate, sembra pressochè nullo,
mentre schizza ad un non marginale 8% medio abilitandole

in pratica ad ora sembra apparire ampiamente conveniente lasciare disabilitato il parametro e per non saper leggere nè scrivere applicare le mitigazioni, che così facendo sono 'gratis'


A quanto pare Phoronix conferma quanto da te anticipato dopo aver fatto una suite di test molto completa: https://phoronix.com/scan.php?page=article&item=zombieload-v2-taa&num=1

La media dei risultati dei test che hanno fatto è questa:

https://i.postimg.cc/XY8N1BMR/Screen-Hunter-458-Nov-17-00-08.jpg

l'anticipazione non è nè mia nè di altri... larabel è l'autore di phoronix :D

l'anticipazione non è nè mia nè di altri... larabel è l'autore di phoronix :D

Si si certo, intendevo dire che l'anticipazione che hai riportato si è poi rivelata corretta su un'ampia suite di test. Mi sembri molto preparato ma ho capito benissimo che non sei tu ad eseguire i test :sofico:

ok :D
ad ogni modo anche l'articolo linkato precedentemente fa riferimento alla disabilitazione delle tsx come 'trucco' per evitare penalizzazioni. di qui aggiungevo la nota dal punto di vista pinguino

probabilmente la stessa intel (dato che la vulnerabilità era sotto embargo) ha indicato la cosa preventivamente

ok :D
ad ogni modo anche l'articolo linkato precedentemente fa riferimento alla disabilitazione delle tsx come 'trucco' per evitare penalizzazioni. di qui aggiungevo la nota dal punto di vista pinguino

probabilmente la stessa intel (dato che la vulnerabilità era sotto embargo) ha indicato la cosa preventivamente

Comunque avevo immaginato che larabel potesse essere di Phoronix :D A questo punto mi aspetto un comportamento simile anche sotto windows 10,quasi quasi lo disabilito anche io il tsx...

si, è certamente 'crossplatform' il comportamento, direi (ahimè) come è sempre stato per questa 'famiglia' di vulnerabilità

btw ho sempre segnalato le comparative fatte su linux per il semplice fatto che (a parte che è il sistema che conosco meglio) è più semplice 'accendere e spegnere' le mitigazioni.
poi non saranno corrispondenze 1:1 (anche perchè sono tutti test sintetici) ma un'idea di massima su come regolarsi la possono dare

si, è certamente 'crossplatform' il comportamento, direi (ahimè) come è sempre stato per questa 'famiglia' di vulnerabilità

btw ho sempre segnalato le comparative fatte su linux per il semplice fatto che (a parte che è il sistema che conosco meglio) è più semplice 'accendere e spegnere' le mitigazioni.
poi non saranno corrispondenze 1:1 (anche perchè sono tutti test sintetici) ma un'idea di massima su come regolarsi la possono dare

Aggiungiamici poi che Phoronix esegue sempre delle suite di test davvero complete, oramai è un riferimento anche per chi non ha linux secondo me.

Ho provato a disabilitare il TSX però ho perso circa il 10% di prestazioni sulle IOPS e alla fine l'ho ripristinato. A quanto pare su windows l'effetto è diverso rispetto a quello su linux.

Arieccoci con l'ennesima nuova vulnerabilità targata intel :muro: ormai ho perso il conto :sob: https://www.zdnet.com/article/new-plundervolt-attack-impacts-intel-cpus/
Si chiama plundervolt attack, comunque ho visto che intel per risolvere ha lanciato una nuova architettura il cui processore di punta è il pentium G3420 :yeah:

Stavo per postarla proprio ora. :sofico:
Se non altro stavolta i processori precedenti alla sesta generazione sono esenti.

Stavo per postarla proprio ora. :sofico:
Se non altro stavolta i processori precedenti alla sesta generazione sono esenti.

Già, il mio povero 4790k per questa volta è stato risparmiato :D

Qui un link di intel con maggiori dettagli https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00289.html

Due anni di mitigazione sulle CPU intel in base ai test di Phoronix: https://www.phoronix.com/scan.php?page=article&item=spectre-meltdown-2&num=1

...e aggiungo... chissà se è finita :sofico:

Ho appena avviato poco fa un PC seminuovo con l'R5 3600 per verificare che almeno si avviasse. Domani arrivano le sue RAM e pensiono un altro Intel (2500k). :fagiano:
Il 3570k rimarrà a lungo sull'HTPC mi sa, al limite aggiorneró i microcode con UBU e anche se dovesse perdere ancora prestazioni, amen. :sofico:

Ho appena avviato poco fa un PC seminuovo con l'R5 3600 per verificare che almeno si avviasse. Domani arrivano le sue RAM e pensiono un altro Intel (2500k). :fagiano:
Il 3570k rimarrà a lungo sull'HTPC mi sa, al limite aggiorneró i microcode con UBU e anche se dovesse perdere ancora prestazioni, amen. :sofico:

Io il 4790k lo terrò ancora un po', almeno 1 se non 2 anni. Per caso ti è capitato sott'occhio qualcosa che riguardi gli aggiornamenti dei microdode degli haswell?
Sulla pagina di intel è da un po' di mesi che non trovo più i microcode per linux che erano utilizzabili anche con UBU.

per quanto riguarda lo stato dell'arte lato microcode un'indicazione può darla la data degli aggiornamenti dei pacchetti (qui sotto della arch, quindi up to date)


extra/intel-ucode 20191115-3 (2.4 MiB 3.0 MiB)
Microcode update files for Intel CPUs

core/amd-ucode 20191220.6871bff-1 (24.9 KiB 34.2 KiB) (Installed)
Microcode update files for AMD CPUs

quindi sembrerebbe che da metà novembre non ci siano nuove
btw salta all'occhio anche la differente dimensione dei pacchetti, ma non conoscendo nel dettaglio il meccanismo di applicazione, non aggiungo commenti tanto per

[edit]
cmq a onor del vero il pacchetto intel è stato ripacchettizzato l'ultima volta l'11 dicembre (senza dettagli ulteriori nel changelog)

per quanto riguarda lo stato dell'arte lato microcode un'indicazione può darla la data degli aggiornamenti dei pacchetti (qui sotto della arch, quindi up to date)


extra/intel-ucode 20191115-3 (2.4 MiB 3.0 MiB)
Microcode update files for Intel CPUs

core/amd-ucode 20191220.6871bff-1 (24.9 KiB 34.2 KiB) (Installed)
Microcode update files for AMD CPUs

quindi sembrerebbe che da metà novembre non ci siano nuove
btw salta all'occhio anche la differente dimensione dei pacchetti, ma non conoscendo nel dettaglio il meccanismo di applicazione, non aggiungo commenti tanto per

Fino a non molto tempo fa, i pacchetti con i microcode aggiornati eranno accessibili e scaricabili dalle pagine ufficiali del supporto intel, ora non si trovano più. Hai qualche link per caso? :)

Trovati, sono reperibili a questo link https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files

Io il 4790k lo terrò ancora un po', almeno 1 se non 2 anni. Per caso ti è capitato sott'occhio qualcosa che riguardi gli aggiornamenti dei microdode degli haswell?
Sulla pagina di intel è da un po' di mesi che non trovo più i microcode per linux che erano utilizzabili anche con UBU.

Non so, so solo che l'ultimo del 3570k è datato febbraio 2019. Ho anche uno Skylake (i3 6100) con la penultima se non terzultima versione che non posso aggiornare perchè Asus non ha rilasciato altri aggiornamenti, con UBU ha problemi e il programmer non sembra funzionare con quel chip quindi non rischio neanche con esperimenti che molto probabilmente andrebbero male (ho installato il KB4465065 di Windows).
Tanto ormai questi PC verranno avviati poche volte giusto per multimedia e poco più.
Sinceramente non sto neanche più seguendo sta storia.

Non so, so solo che l'ultimo del 3570k è datato febbraio 2019. Ho anche uno Skylake (i3 6100) con la penultima se non terzultima versione che non posso aggiornare perchè Asus non ha rilasciato altri aggiornamenti, con UBU ha problemi e il programmer non sembra funzionare con quel chip quindi non rischio neanche con esperimenti che molto probabilmente andrebbero male (ho installato il KB4465065 di Windows).
Tanto ormai questi PC verranno avviati poche volte giusto per multimedia e poco più.
Sinceramente non sto neanche più seguendo sta storia.

Capisco, invece io mi sono incuriosito e sto scaricando l'ultima versione di UBU così da verificare se il mio microcode è l'ultimo oppure no.

OK, appena verificato con UBU e per il 4790k l'ultimo aggiornamento del ucode è il n. 27 del 26/02/2019 che ho già. Meglio così :)

mitigazioni in arrivo per nuova vulnerabilità nei chip con grafica integrata intel
almeno cambia il target, non si tratta di meltdown/spectre e figliocci...
e almeno stavolta serve avere accesso alla macchina fisica
il tutto cross platform, come immaginabile

parrebbe che i chip più 'vecchi' impattati (ad ora haswell) potrebbero avere più 'costo', cmq phoronix sta eseguendo in queste ore dei bench con le patch già applicate, e si avrà una qualche idea...

mitigazioni in arrivo per nuova vulnerabilità nei chip con grafica integrata intel
almeno cambia il target, non si tratta di meltdown/spectre e figliocci...
e almeno stavolta serve avere accesso alla macchina fisica
il tutto cross platform, come immaginabile

parrebbe che i chip più 'vecchi' impattati (ad ora haswell) potrebbero avere più 'costo', cmq phoronix sta eseguendo in queste ore dei bench con le patch già applicate, e si avrà una qualche idea...

Ah ecco :D Giusto per colpire anche quella parte di silicio presente sul die delle cpu intel che fino ad oggi non era stata coinvolta...:sofico:

si ok, ma veramente non si finisce più qua, e alla fine va male per tutti
peraltro tutto da stabilire che lato amd non possa mai verificarsi un caso simile
nel senso che evidentemente c'è iperesposizione di queste casistiche lato intel, dato il pregresso

ouch, l'impatto sugli intel gen7 (in modo particolare) della nuova mitigazione sembra enorme...
tutto con un certo grado di preliminarietà, poi tutti bench sintetici, ma temo non si scappi... se non smussabile può arrivare ai limiti della non utilizzazibilità della patch (opzione 'safe' se viene confermato, non ancora al 100%, che l'unica per sfruttare è avere accesso alla macchina fisica)

ouch, l'impatto sugli intel gen7 (in modo particolare) della nuova mitigazione sembra enorme...
tutto con un certo grado di preliminarietà, poi tutti bench sintetici, ma temo non si scappi... se non smussabile può arrivare ai limiti della non utilizzazibilità della patch (opzione 'safe' se viene confermato, non ancora al 100%, che l'unica per sfruttare è avere accesso alla macchina fisica)

Sarebbe interessante capire se, chi ha una scheda grafica discreta, disabilitando l'IGP intel (utile magari per usare uno schermo in più o per utilizzare l'accelerazione nella compressione video) può risolvere o meno.

Presumo valga solo per chi utilizza la scheda integrata e installa la patch, evitabile anche perchè sfruttabile solo con accesso fisico al PC.

Presumo valga solo per chi utilizza la scheda integrata e installa la patch, evitabile anche perchè sfruttabile solo con accesso fisico al PC.

Esatto, lo stavo leggendo proprio adesso anche io su Phoronix, metto i link agli articoli:

https://www.phoronix.com/scan.php?page=news_item&px=Intel-Gen7-Graphics-Flaw

https://www.phoronix.com/scan.php?page=article&item=intel-gen7-hit&num=1

a stamattina l'unico aspetto non certo (sulla non sfruttabilità da remoto) veniva indicato su webgl. ma nel senso che ad ora non c'erano nè conferme nè smentite

per chi non seguisse phoronix
intel ha annotato nella patch per i gen7 che il target primario è stato fin'ora di chiudere il buco, senza focalizzarsi sulle prestazioni
inoltre se non ricordo male ad ora la patch non verrà 'mergeata' in mainline, o per lo meno non prima di passare per la (non leggera, suppongo...) fase di ottimizzazione

vedremo

ps: il tutto relativo alla patch per linux, ma dubito che per altri os sia tanto diversa

Ulteriori test su phoronix: https://www.phoronix.com/scan.php?page=news_item&px=Intel-More-Gen7-Gfx-Initial-Hit

Ulteriori dettagli su iGPU leak https://www.phoronix.com/scan.php?page=news_item&px=Intel-iGPU-Leak-Details
Sembra che la mitigazione finale, a differenza di quella emessa di recente in modo urgente, potrà avere un impatto prestazionale trascurabile.

l'aspetto più interessante è cmq che la falla sembra poter essere sfruttata anche da remoto (rendering siti web), anche se, va specificato, senza pieno controllo ma 'solo' la capacità di identificare gli utenti locali

il tutto con ancora qualche margine di incertezza, e ovviamente valido per il pinguino. per altri os non mi esprimo

Ulteriori dettagli su iGPU leak https://www.phoronix.com/scan.php?page=news_item&px=Intel-iGPU-Leak-Details
Sembra che la mitigazione finale, a differenza di quella emessa di recente in modo urgente, potrà avere un impatto prestazionale trascurabile.
Per evitare l'applicazione della patch (in questo caso parlo di windows), hai per caso letto da qualche parte se è sufficiente non aggiornare il bios della mobo o è necessario evitare pure driver video intel più recenti? :incazzed:

Per evitare l'applicazione della patch (in questo caso parlo di windows), hai per caso letto da qualche parte se è sufficiente non aggiornare il bios della mobo o è necessario evitare pure driver video intel più recenti? :incazzed:

Da quello che ho capito questa vulnerabilità si risolve tramite driver aggiornati senza coinvolgere il bios.

Ecco il link dei driver da "evitare" (per gli haswell) :D https://downloadcenter.intel.com/it/download/29313?product=80807 se non si vuole chiudere la vulnerabilità :sofico:
Sono quelli aggiornati al 10/01/2020 e nelle note è indicato proprio "This release contains security fixes".

Da quello che ho capito questa vulnerabilità si risolve tramite driver aggiornati senza coinvolgere il bios.
Strano, sul sito della mia asrock è uscito un aggiornamento bios proprio il 2 di gennaio con: Update Intel Microcode and ME e Update GOP, insomma, proprio non molto dopo l'annuncio del bug.

Cmq allora evito il bios e i driver video di fine dicembre mettendo invece quelli di fine novembre. Zio Can che nervi... :ncomment:

Ecco il link dei driver da "evitare" (per gli haswell) :D https://downloadcenter.intel.com/it/download/29313?product=80807 se non si vuole chiudere la vulnerabilità :sofico:
Sono quelli aggiornati al 10/01/2020.
Io ho un 8gen (8500), quindi per andare sul sicuro vado su quelli di fine novembre :)

Io ho un 8gen (8500), quindi per andare sul sicuro vado su quelli di fine novembre :)

La tua cpu non dovrebbe subire nessun rallentamento, il problema è su haswell e ivy bridge. Fossi in te aggiornerei :)

Il problema è che prima o poi potrebbero manifestarsi problemi con alcuni software e allora sarebbero dolori. Mi è capitato in passato che ad esempio Davinci Resolve non funzionasse piú con un paio di revisioni di driver video Intel, problema risolto con gli aggiornamenti successivi.
Quindi o non si aggiorna piú niente o si incrociano le dita.

Il problema è che prima o poi potrebbero manifestarsi problemi con alcuni software e allora sarebbero dolori. Mi è capitato in passato che ad esempio Davinci Resolve non funzionasse piú con un paio di revisioni di driver video Intel, problema risolto con gli aggiornamenti successivi.
Quindi o non si aggiorna piú niente o si incrociano le dita.

Al limite, trattandosi di driver, dovrebbe bastare fare un rollback.

La tua cpu non dovrebbe subire nessun rallentamento, il problema è su haswell e ivy bridge. Fossi in te aggiornerei :)
Visto che il bug riguarda tutte le igpu pre-Gen11 Icelake (almeno da quanto letto su phoronix), magari mi conviene andare di driver più vecchi finché non si vedranno dei test sulle igpu Gen 9.5 (cioè la uhd graphics 630 del mio Coffee infame) per verificare l'impatto prestazionale della mitigazione. :)

Ma se non si usa la grafica intel il problema non sussiste, io ad esempio non la uso e l' ho proprio disattivata da bios.

Inviato dal mio Mi 9T utilizzando Tapatalk

Mi pare abbastanza ovvio che il problema riguardi chi usa l'integrata. Una patch standalone sarebbe stata la soluzione migliore.

Io ho un 8gen (8500), quindi per andare sul sicuro vado su quelli di fine novembre :)

Ti consiglio caldamente di installare i driver più recenti perchè con la tua cpu non avresti nessun impatto prestazionale. Riporto testualmente da Phoronix The patch had mentioned though Gen8 was not impacted thanks to an earlier workaround

Ti consiglio caldamente di installare i driver più recenti perchè con la tua cpu non avresti nessun impatto prestazionale. Riporto testualmente da Phoronix The patch had mentioned though Gen8 was not impacted thanks to an earlier workaround
Aspè, la frase che hai riportato appartiene al seguente contesto:

"The Linux kernel patch for this hardware defect that was merged earlier today only was for the very common Gen9 graphics, basically from Skylake through all relevant/shipping CPUs today pre-Icelake. The patch had mentioned though Gen8 was not impacted thanks to an earlier workaround. But now it turns out Intel Gen7/Gen7.5 graphics are also affected: this basically means Ivy Bridge and Haswell processors along with the likes of Valley View"

Da quanto sopra, osservo che quando cita "Gen" lo fa in riferimento alla "graphics", non alla Gen della Cpu, quindi quando parla di "Gen8" credo faccia riferimento alla "Gen8 graphics", la quale non è quella montata sul Coffee Lake come precedentemente avevo menzionato; infatti sul Coffee è presente la Gen9.5 graphics, la quale rientra nel seguente discorso di Phoronix: "only was for the very common Gen9 graphics, basically from Skylake through all relevant/shipping CPUs today pre-Icelake".

Riassumendo, un conto è il riferimento alla Gen della CPU, un conto è invece la Gen riferita alla igpu dei proci Intel.

Ma se non si usa la grafica intel il problema non sussiste,
Il punto è che la maggior parte di quelli che mondialmente hanno acquistato cpu intel con grafica integrata non hanno acquistato anche una vga discreta (i pc videoludici sono ben meno rispetto a tutti gli altri), visto che con la discreta di intel ci puoi fare di tutto, e molto bene, anche multimedialmente parlando (quicksync), tranne ovviamente i giochi o utilizzi professionali specifici/intensi.

Sono comunque convinto che dopo tutte queste rotture di coglioni con le cpu Intel, sia/sarebbe doveroso che questa azienda, con le sue future cpu senza bug (o bug fixati senza alcun decadimento prestazionale), facesse un qualche sconto per eventuale upgrade a tutti gli attuali clienti di cpu "fallate", almeno da skylake in avanti.

Intanto sul Precision che ho preso a settembre, con i9 9980HK, dopo gli ultimi aggiornamenti Dell e MS fine 2019/inizio 2020 ho perso un 3-4% di prestazioni in generale (confermato banalmente anche da Cinebench). Non so esattamente se sia stato un ennesimo update di microcode o altro, ma considerando che è una macchina da più di 4mila euro, mi girano le balle mica poco.:muro: :rolleyes:

Aspè, la frase che hai riportato appartiene al seguente contesto:

"The Linux kernel patch for this hardware defect that was merged earlier today only was for the very common Gen9 graphics, basically from Skylake through all relevant/shipping CPUs today pre-Icelake. The patch had mentioned though Gen8 was not impacted thanks to an earlier workaround. But now it turns out Intel Gen7/Gen7.5 graphics are also affected: this basically means Ivy Bridge and Haswell processors along with the likes of Valley View"

Da quanto sopra, osservo che quando cita "Gen" lo fa in riferimento alla "graphics", non alla Gen della Cpu, quindi quando parla di "Gen8" credo faccia riferimento alla "Gen8 graphics", la quale non è quella montata sul Coffee Lake come precedentemente avevo menzionato; infatti sul Coffee è presente la Gen9.5 graphics, la quale rientra nel seguente discorso di Phoronix: "only was for the very common Gen9 graphics, basically from Skylake through all relevant/shipping CPUs today pre-Icelake".

Riassumendo, un conto è il riferimento alla Gen della CPU, un conto è invece la Gen riferita alla igpu dei proci Intel.

Credo sia da intendersi che dalla Gen8 in avanti non ci sia impatto perché c'è stato un workaround da lì in avanti sulle nuove CPU e igpu, infatti i test di Phoronix sono su ivy bridge e haswell che invece subiscono un importante calo di prestazioni.
Quindi tu puoi stare tranquillo ;)

Il punto è che la maggior parte di quelli che mondialmente hanno acquistato cpu intel con grafica integrata non hanno acquistato anche una vga discreta (i pc videoludici sono ben meno rispetto a tutti gli altri), visto che con la discreta di intel ci puoi fare di tutto, e molto bene, anche multimedialmente parlando (quicksync), tranne ovviamente i giochi o utilizzi professionali specifici/intensi.

Certamente, lo dicevo solo per essere sicuro che non mi fosse sfuggito qualcosa :D

Sono comunque convinto che dopo tutte queste rotture di coglioni con le cpu Intel, sia/sarebbe doveroso che questa azienda, con le sue future cpu senza bug (o bug fixati senza alcun decadimento prestazionale), facesse un qualche sconto per eventuale upgrade a tutti gli attuali clienti di cpu "fallate", almeno da skylake in avanti.

Dubito che lo faccia, io sono ancora con Haswell e dovrei aggiornare tutto il PC fisso, ma sto meditando di passare a ryzen.

Dubito che lo faccia, io sono ancora con Haswell e dovrei aggiornare tutto il PC fisso, ma sto meditando di passare a ryzen.

Anche io, vediamo se riesco a resistere fino al cambio di socket e alle ddr5 per passare ad AMD.