Newsgroup: it.comp.hardware
Titolo: Bug "Zenbleed" negli AMD basati su Zen 2 (ryzen, threadripper, epyc)

Si sfrutta da remoto, basta un javascript per ciucciarti password e dati 
crittati:
 
https://lock.cmpxchg8b.com/zenbleed.html
 
 
AMD (as usual) ha fatto orecchio da mercante, ma adesso che la falla e' 
stata pubblicata dovra' fornire le patch per il firmware, data prevista 
ottobre-dicembre:
 
https://www.amd.com/en/resources/product-security/bulletin/amd-sb-7008.html
 


Nel log dei ricercatori c'è scritto che la prima patch beta era pronta a 
maggio. Nella pagina di AMD il microcode aggiornato è già nei bios 
aggiornati con le versioni AGESA lì descritte.
 
Ormai la prassi è che la disclosure avviene quando è già pronto il fix, 
come successo pure in questo caso (vedi pagina da te stesso segnalata):
 
"AMD thanks Tavis Ormandy of Google Information Security Engineering for 
reporting this issue and engaging in coordinated vulnerability disclosure."
 
Almeno leggile le cose che posti.

 ottobre-dicembre:
 
https://imgur.com/Z0qVaph
 
 
https://tinyurl.com/4ma58ue3
 
 
 
https://launchpad.net/ubuntu/+source/amd64-microcode/3.20191218.1ubuntu2.1
 
 
 
ps: ho una CPU Intel.

 Almeno leggile le cose che posti.
 
La patch rilasciata da AMD riguarda solo i chip della serie EPYC 7002, 
cioe' quelli per il mercato server.
Per tutti gli altri (desktop/laptop) il rilascio delle patch e' previsto 
tra ottobre e dicembre, lo dice AMD stessa nel link che ho postato e che 
evidentemente *tu non hai letto*.
 
Queste le date previste delle patch per le CPU piu' diffuse:
Ryzen 3000 (desktop) Dicembre 2023
Ryzen 4000G (desktop) Dicembre 2023
Ryzen 4000 (laptop) Novembre 2023
Ryzen 5700U/5500U/5300U (laptop) Dicembre 2023
Ryzen 7020 (laptop) Dicembre 2023
Ryzen Threadripper 3000 Ottobre 2023
Ryzen Threadripper Pro 3000WX Novembre/Dicembre 2023
 
Un elenco piu' dettagliato si trova qua:
https://www.tomshardware.com/news/zenbleed-bug-allows-data-theft-from-amds-zen-2-processors-patches-released
 
 
In attesa della patch, quei sistemi sono particolarmente vulnerabili, 
dal momento che la disclosure e' stata pubblicata.
 
Da notare che (as usual) il bug e' stato scoperto e dettagliato dal team 
Project Zero di Google e non da AMD, dal momento che AMD non investe un 
centesimo sulla sicurezza, come gia' ho avuto modo di scrivere in passato.

 centesimo sulla sicurezza, come gia' ho avuto modo di scrivere in passato.
 
Per analogia, anche Intel e ARM investono zero in sicurezza, visto che 
Meltdown e Spectre sono state scoperta dallo stesso Project Zero e 
altri. Leggo da Wikipedia che, scoperto Spectre a gennaio 2018, Intel ha 
rilasciato le patch "correttive" a giugno 2018. Come vedi, i tuoi 
argomenti ti si possono facilmente ritorcere contro poiché sono 
piuttosto fallaci.
 
PS: ho cpu Intel su fisso e portatile


 
Comunque e' curioso che questa falla sia presente solo
sulle cpu con arch Zen2, considerando che (come al solito) sfrutta
le "croniche" debolezze riguardo l'esecuzione speculativa come accaduto
con i ben piu' "famosi" Spectre e Meltdown...

 piuttosto fallaci.
 
Tu devi avere qualche problema con l'inglese, in particolare con le date:
"Google said it informed the affected companies about the Spectre flaw 
on 1 June 2017 and later reported the Meltdown flaw before 28 July 2017."
 
Le patch al microkernel di Intel sono arrivate subito, ma avevano 
problemi, oltre a questo c'e' da considerare che erano coinvolte anche 
CPU molto vecchie per cui si e' preferito correggere il problema via 
software, Microsoft ha fornito le patch verso fine gennaio.

 come accaduto con i ben piu' "famosi" Spectre e Meltdown...
 
Questa (e altre gia' note) la si puo' benissimo classificare come 
Meltdown, o variante di Meltdown, se preferisci.

 software, Microsoft ha fornito le patch verso fine gennaio.
 
Ammetto di aver confuso le date, ma questo non ha nessun valore rispetto 
alle affermazioni che fai su chi spende in sicurezza e chi no, anche perché
la tua argomentazione è fondamentalmente debole e basata sulla tua personale
opinione.
 
 

 con i ben piu' "famosi" Spectre e Meltdown...
 
Se ho interpretato bene il documento riassuntivo e il datasheet di AMD, succede
che deve innanzitutto coinvolgere l'utilizzo di codice con le AVX2 dove vengono
utilizzati sia registri a 128 bit XMM che a 256 bit YMM. In sostanza XMM sono i
128 bit meno significativi del corrispondente YMM (come accade, per esempio, con
i general purpose EAX che sono i 32 bit meno significativi del registro RAX 
a 64 bit).
 
Se si usano registri XMM e YMM nella stessa istruzione, il registro XMM viene
"promosso" nel corrispondente YMM a 256 bit.
 
Tutto gira intorno a quella istruzione "vzeroupper", che sostanzialmente serve
ad azzerare i 128 bit più significativi di tutti i registri YMM.
L'effetto, oltre che azzerare i bit più significativi, è anche quello di rimuovere
una dipendenza fra registri che potrebbe impattare sul riordino delle istruzioni
interne al core per sfruttare l'esecuzione parallela.
 
Le CPU Zen2 hanno la feature "XMM Register Merge Optimization" (vedi par. 2.11.5 
del datasheet), e dal datasheet dice sostanzilamente che se la parte più significativa
dei registri YMM è stata azzerata, il processore ne tiene traccia e può eseguire 
alcune particolari istruzioni senza attendere altre istruzioni che toccano quei
bit, migliorando l'esecuzione parallela.
 
Il problema si verifica in una particolare circostanza quando c'è un branch
predetto non correttamente e bisogna ripristinare lo stato precedente ad una
speculazione; semplicemente lo stato non viene ripristinato correttamente, perché
c'è una ulteriore ottimizzazione (lo z-bit) che evita di azzerare i bit più significativi
realmente quando c'è vzeroupper, e che invece imposta un flag per tenerne traccia. Lo
stato interno, al back-tracking, non viene ripristinato correttamente (l'autore non
specifica se il problema è lo z-bit, ma più presumibilmente è legato al "register
renaming" dei registri fisici interni al core per avere l'esecuzione parallela superscalare)
per cui parti di dati dell'esecuzione speculativa rimangono presenti nei registri ripristinati
DOPO il back-tracking. Spulciando dentro ai registri ecco che viene fuori il contenuto compromettente.
 
Il tutto è reso pericoloso dal fatto che le AVX2 sono usate nelle comuni operazioni
di conteggio della lunghezza di stringhe (strlen) e copia di memoria (memcpy/memmove),
per cui ecco che ci si trova di tutto dentro.
 

 opinione.
 
ROTFL! Chiarissimo.


Purtroppo con certi signori " so-tutto-io " pare non serva a nulla 
cercare di instaurare un corretto dialogo/confronto : l'unica verità 
ammessa è la loro.
IMHO con gente simile l'unica cosa sensata è ignorarli, se non proprio 
collocarli nel kill file almeno fino alla scomparsa dei sintomi da 
effetto Dunning-Kruger.
 

 istruzioni che toccano quei bit, migliorando l'esecuzione parallela.
 
Ed e' appunto curioso che questa "ottimizzazione" ce l'abbiano
solo le cpu su base Zen2...probabilmente le gen successive ne hanno
fatto a meno perche' potevano in certi e particolari casi provocare
problematiche come quelle che sono saltate fuori recentemente.


Da quello che so, con Zen3 hanno ristrutturato pesantemente il branch 
predictor e non ho idea di cos'altro; probabilmente quel bug, assieme ad 
un'altra vulnerabilità che era venuta fuori qualche tempo fa, è stato 
segato via dal refactoring...

 non ti importava e adesso vuoi la documentazione? Deciditi.
 
Sisi, figurati, da uno che non sa nemmeno distinguere fra bug e 
vulnerabilità c'è sicuro da fidarsi. Francamente non mi ricordo, quello 
che mi frega poco è la tua interpretazione alterata di qualche numerino.
 
 

 via dal refactoring...
 
Puo' essere...

 parlando.
 
La boiata che hai scritto e' che sarebbe necessario attendere la patch 
prima di pubblicare, non e' cosi', la prassi e':
1. informare il produttore del problema
2. lasciargli un tempo *ragionevole* per il rilascio di una patch, nel 
caso di Project Zero di solito sono 90 giorni, ma dipende dal problema.
3. pubblicare, anche se il produttore non ha ancora rilasciato una patch
 
Il punto 3 serve a costringere i produttori a darsi una mossa, ed e' a 
tutela dei consumatori, che sono le vere vittime di queste situazioni.

 Puo' essere...
 
Ah, manco a farlo apposta l'altra vulnerabilità a cui mi riferivo è 
citata nel documento per Zenbleed come nota [4]: 
https://grsecurity.net/amd_branch_mispredictor_part_2_where_no_cpu_has_gone_before
 
 
Anche lì Zen1 e Zen2 avevano il problema, sparito poi con Zen3:
 
"Apparently, the Zen3 microarchitecture received a significant upgrade 
and redesign of its branch prediction unit (BPU), which effectively 
eliminated the flaw and rendered the Zen3 microarchitecture immune to 
the vulnerability. Later, AMD PSIRT confirmed that this indeed had been 
the case."

 sono previste fra ottobre e dicembre.
 
https://github.com/google/security-research/tree/master/pocs/cpus/zenbleed
 
- paragrafo Timeline.
 
Da cui estraggo:
 
2023-05-15 - We draft a brief status report and share our findings with 
AMD PSIRT.
...
2023-05-23 - We receive a beta microcode update for Rome from AMD.
 
 
Per tutto il resto, mi sono rotto le palle a sufficienza per oggi.

 Per tutto il resto, mi sono rotto le palle a sufficienza per oggi.
 
Concordo, e le hai rotte anche agli altri con i tuoi stupidi giochetti.