{"id":138893,"date":"2025-07-09T23:11:55","date_gmt":"2025-07-09T21:11:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/ataka-tsa-privodyashhaya-k-utechke-informaczii-iz-mikroarhitekturnyh-struktur-cpu-amd"},"modified":"2025-07-09T23:11:55","modified_gmt":"2025-07-09T21:11:55","slug":"ataka-tsa-privodyashhaya-k-utechke-informaczii-iz-mikroarhitekturnyh-struktur-cpu-amd","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/novosti-interneta\/ataka-tsa-privodyashhaya-k-utechke-informaczii-iz-mikroarhitekturnyh-struktur-cpu-amd","title":{"rendered":"Attacco TSA, che causa la fuoriuscita di informazioni dalle microarchitetture delle CPU AMD","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
L'azienda AMD ha rivelato informazioni su una nuova classe di attacchi microarchitetturali sui suoi processori \u2014 TSA (Transient Scheduler Attack). Questo attacco consente a un aggressore di bypassare i meccanismi di isolamento della CPU e di identificare i dati elaborati in altri contesti, ad esempio, ottenere informazioni dal livello utente riguardo ai dati in elaborazione a livello kernel, o dall'interno di un sistema guest ottenere dati utilizzati in un altro sistema guest. <\/p>\n
Le vulnerabilit\u00e0 sono state identificate durante lo sviluppo di un toolkit creato da ricercatori di Microsoft e dell'\u00c9cole Polytechnique F\u00e9d\u00e9rale de Lausanne per il test di stress dell'isolamento microarchitetturale tra diverse aree di confine di accesso, come il nucleo, le macchine virtuali e i processi. <\/p>\n
Il metodo di attacco si basa sulla dipendenza dei tempi di esecuzione di alcune istruzioni dallo stato delle strutture microarchitetturali. Quando la CPU attende un rapido completamento dell'istruzione di lettura dei dati dalla memoria (ad esempio, supponendo che i dati siano nel cache L1), ma non riesce a recuperare con successo i dati, si verifica uno stato di \"falso completamento\" dell'istruzione. A questo punto, prima ancora di determinare questo stato, la CPU pu\u00f2 pianificare l'esecuzione speculativa di altre operazioni dipendenti dal risultato dell'istruzione di caricamento dalla memoria. <\/p>\n
Poich\u00e9 il caricamento non \u00e8 andato a buon fine, i dati associati vengono considerati non validi dalla CPU e l'operazione di caricamento viene ripetuta successivamente. Le operazioni dipendenti vengono anch'esse rieseguite una volta che i dati corretti sono disponibili. Tuttavia, non viene eseguita una pulizia della pipeline dopo l'esecuzione dell'istruzione per cui \u00e8 stato registrato lo stato di \"falso completamento\", e dati errati possono essere instradati alle operazioni dipendenti. <\/p>\n
L'esecuzione di tali operazioni non modifica lo stato della cache e del TLB (Translation Lookaside Buffer), ovvero i dati non possono essere recuperati tramite i metodi tradizionali di valutazione dello stato della cache. Tuttavia, questi dati influiscono sui tempi di esecuzione di altre istruzioni. L'analisi dei tempi di esecuzione pu\u00f2 essere utilizzata come fonte di fuga di informazioni dalle strutture microarchitetturali, rimaste dopo l'esecuzione speculativa di altre operazioni. <\/p>\n
A seconda della fonte di estrazione dei dati residui, sono state identificate due vulnerabilit\u00e0: <\/p>\n
\n
CVE-2024-36350 (TSA-SQ \u2014 TSA Store Queue) \u2014 fuga di dati dal buffer di memoria temporanea per le operazioni di scrittura (Store Queue), che consente di determinare il risultato dell'esecuzione delle istruzioni di scrittura in memoria.\n
CVE-2024-36357 (TSA-L1 \u2014 TSA L1 Data Cache) \u2014 fuga attraverso il cache L1D. <\/ul>\n
Le vulnerabilit\u00e0 si manifestano nella famiglia di processori AMD (Fam19h) basata sulle microarchitetture Zen 3 e Zen 4. Ad esempio, il problema \u00e8 presente nelle serie CPU AMD Ryzen 5000\/6000\/7000\/8000, AMD EPYC Milan\/Milan-X\/Genoa\/Genoa-X\/Bergamo\/Siena, AMD Instinct MI300A, AMD Ryzen Threadripper PRO 7000 WX, AMD EPYC Embedded 7003\/8004\/9004\/97X4, AMD Ryzen Embedded 5000\/7000\/V3000. <\/p>\n
Le modifiche necessarie per mitigare le vulnerabilit\u00e0 sono state incluse nell'aggiornamento di microcodice di dicembre e nelle firmware di PI (Platform Initialization) fornite ai produttori OEM. Le patch per proteggere contro le vulnerabilit\u00e0 sono state inviate per essere incluse nel kernel Linux (\u00e8 prevista un'opzione della riga di comando del kernel per disattivare la protezione, che influisce negativamente sulle prestazioni, chiamata \"tsa=off\"). La correzione \u00e8 stata inoltre aggiunta al hypervisor Xen. \u00c8 necessaria sia l'aggiornamento del microcodice che l'abilitazione della modalit\u00e0 di protezione a livello kernel o hypervisor per mitigare la vulnerabilit\u00e0. \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"