DDRop, un interposer da 159 dollari rimette in discussione le garanzie del confidential computing

Un circuito stampato che costa meno di duecento dollari, inserito per pochi minuti tra processore e memoria, basta a far leggere alla CPU dati vecchi credendoli attuali. Su quel difetto poggia DDRop, la ricerca divulgata il 14 settembre 2026 da nove ricercatori di KU Leuven, ETH Zurigo, Durham University e Google. Intel e AMD hanno riconosciuto i risultati e hanno risposto che gli attacchi fisici alla memoria restano fuori dal proprio modello di minaccia.

La distinzione conta più di quanto sembri. Il confidential computing viene venduto come la tecnologia che protegge i dati anche dal fornitore di infrastruttura. Se gli scenari di attacco esclusi dal modello di minaccia coincidono con quelli che una valutazione sui trasferimenti deve esaminare, il problema smette di essere solo tecnico.

Che cosa è stato pubblicato

Il lavoro si intitola «DDRop: Active Memory Interposer Attacks on Confidential VMs by Dropping DDR5 Writes» e sarà presentato alla conferenza ACM CCS 2026, in programma all’Aia dal 15 al 19 novembre. Gli autori hanno pubblicato il sito divulgativo ddropattack.eu e hanno rilasciato a sorgente aperto schemi, disegni della scheda, firmware del microcontrollore e codice degli attacchi sul repository GitHub del progetto.

Il paper documenta attacchi funzionanti su tre tecnologie: Intel TDX, Intel Scalable SGX e AMD SEV-SNP. La cronaca internazionale ha dato risalto alle prime due; la terza risulta colpita allo stesso modo, come indicano sia l’abstract sia la tabella riassuntiva del lavoro.

Il difetto: cifratura senza freschezza

Le tre tecnologie cifrano la memoria per proteggere i carichi di lavoro dall’ipervisore e dall’operatore del centro dati. Per reggere volumi di memoria grandi, però, rinunciano alla freschezza crittografica, cioè alla capacità di stabilire se un valore letto sia quello scritto per ultimo.

Gli autori spiegano la conseguenza con un’immagine efficace: il processore può confermare che la memoria è cifrata, non che è attuale. Un dato vecchio si decifra perfettamente. Basta quindi impedire che una scrittura arrivi al modulo di memoria perché il contenuto precedente, scelto dall’attaccante, resti al suo posto senza che il motore di cifratura rilevi alcuna anomalia.

Intel TDX usa AES in modalità XTS con chiavi per dominio e offre in via opzionale una modalità di integrità crittografica. Si basa su un codice di autenticazione da 28 bit per linea di cache, che Intel descrive come derivato da SHA-3 e che riduce la copertura dei bit di correzione d’errore. AMD SEV-SNP usa AES in modalità XEX con chiavi per ospite e, come scrivono gli autori, non prevede né integrità crittografica né freschezza. Nessuna delle due configurazioni rileva un dato obsoleto.

Come funziona l’interposer

La novità tecnica sta nel dispositivo. Gli interposer passivi già noti per DDR5 richiedevano analizzatori logici ingombranti e imponevano di abbassare la frequenza del bus, un intervento che un controllo all’avvio potrebbe individuare. L’interposer di DDRop è una scheda compatta di interruttori analogici, lavora alla frequenza nativa della memoria e si installa in pochi minuti.

Il meccanismo sfrutta il controllo di parità del bus comandi. Sui moduli registrati DDR5 un componente dedicato verifica la parità dei comandi in arrivo. Quando rileva un errore scarta il comando e segnala l’anomalia alla CPU su una linea di allerta, che ne provoca il reinvio. L’interposer forza l’errore di parità e scollega la linea di allerta. Il modulo scarta la scrittura, il processore non riceve alcuna segnalazione e la scrittura sparisce.

La distinta base pubblicata dagli autori indica 159 dollari per un singolo sistema, calcolati su una produzione di dieci unità e al netto di ricerca, sviluppo e montaggio. Il paper dichiara un costo complessivo inferiore a 200 dollari. Per confronto, gli stessi autori ricordano che un attacco passivo del 2020 richiedeva strumentazione da circa 170.000 dollari.

Che cosa ottiene l’attaccante su Intel TDX

Su TDX l’attacco colpisce le tabelle delle pagine sicure, la struttura che il modulo TDX gestisce in via esclusiva per impedire all’ipervisore di manipolare le traduzioni di indirizzo. Quando l’ipervisore chiede l’allocazione di una nuova pagina di tabella, il modulo TDX la inizializza scrivendo voci vuote. L’interposer scarta quelle scritture e la pagina conserva un testo cifrato preparato in precedenza, che si decifra in voci di tabella malevole.

Gli autori descrivono la primitiva come deterministica al cento per cento. Da lì derivano due casi di studio verificati sulla piattaforma di prova.

Nel primo, l’attaccante corrompe gli attributi della struttura di controllo di una macchina virtuale vittima. Il dato è cifrato con una chiave diversa, quindi si decifra come rumore pseudocasuale: ogni tentativo ha una probabilità del cinquanta per cento di attivare il bit di debug. Attivato quel bit, l’ipervisore legge la memoria in chiaro della vittima tramite l’interfaccia di debug e poi ripristina il testo cifrato originale. Gli autori verificano che, dopo il ripristino, il rapporto di attestazione della vittima risulta invariato.

Nel secondo caso l’attaccante avvia una propria macchina virtuale con il codice che preferisce e ne riscrive la misura di avvio, sostituendola con quella del carico di lavoro legittimo. Alla richiesta di attestazione il modulo TDX restituisce un rapporto firmato che contiene la misura falsificata. È un punto da leggere con attenzione: la falsificazione riguarda l’attestazione della macchina dell’attaccante, non quella della vittima. L’effetto pratico è comunque grave, perché un verificatore remoto accetta come attendibile un ambiente che non lo è.

Su AMD SEV-SNP e su Scalable SGX

Su SEV-SNP i ricercatori sfruttano l’interfaccia di ricollocazione delle pagine esposta al gestore non attendibile. Né il modulo TDX né il processore sicuro AMD azzerano la posizione di origine dopo lo spostamento. Combinando una ricollocazione preparatoria e una seconda ricollocazione con le scritture soppresse, l’attaccante fa sì che una pagina della vittima erediti il contenuto in chiaro di un’altra pagina della stessa vittima.

Sulla piattaforma di prova AMD la copia riguarda metà delle linee di cache della pagina bersaglio, per effetto dell’interleaving della memoria. Su Scalable SGX gli autori dimostrano la primitiva di base, cioè la lettura di dati obsoleti da parte di un’enclave, senza costruire una catena di attacco completa.

Due architetture restano fuori dalla verifica sperimentale. Arm CCA non è stata provata perché non esiste ancora silicio commerciale che la supporti, e gli autori scrivono che potrebbe essere colpita allo stesso modo. Le GPU NVIDIA per il confidential computing usano memoria a banda larga integrata nel pacchetto del chip: i bus di comando e dati non sono accessibili a un avversario fisico, quindi un interposer non è installabile.

Perché il vecchio Client SGX resiste

La prima generazione di SGX, destinata a processori per postazioni di lavoro e ormai dismessa, si difende da sola. Assegna un contatore a ogni linea di cache, costruisce un albero di integrità su quei contatori e conserva la radice dell’albero in memoria interna al processore. Scartare una scrittura rende l’albero incoerente e il controllore di memoria se ne accorge.

Il prezzo di quella robustezza era la dimensione dell’area protetta, limitata a 256 megabyte. La lezione architetturale è esattamente questa: integrità e freschezza sono state sacrificate per rendere la cifratura scalabile ai carichi di lavoro cloud.

Non è un incidente di percorso, ed è Intel stessa a dirlo. Il 12 marzo 2026, sei mesi prima della divulgazione di DDRop, Simon Johnson, che in Intel guida lo sviluppo di TDX, ha presentato il ragionamento alla conferenza OC3 di Berlino. Tre forze definiscono quello che l’azienda chiama il perimetro di sicurezza accettabile: il livello di garanzia, il costo e le prestazioni. La formula usata nelle slide è netta: è il costo totale di possesso a definire il confine reale della sicurezza. L’architettura ottimale, si legge, massimizza la sicurezza verificabile dentro un involucro economicamente sostenibile.

Lo stesso intervento riconosce il limite della cifratura AES-XTS, diventata standard di fatto del settore perché efficiente e facile da distribuire. Offre una protezione limitata quando l’attaccante può osservare o manipolare la memoria cifrata, e la ricerca accademica recente ha dimostrato attacchi contro diverse implementazioni che la impiegano. Protezioni crittografiche più forti sono possibili, aggiunge Intel, ma non senza far salire il costo della piattaforma.

La risposta di Intel e AMD

Intel ha pubblicato l’annuncio di sicurezza 2026-09-14-001. L’azienda riconosce la ricerca e afferma che gli scenari descritti ricadono fuori dal proprio modello di minaccia per il confidential computing. Dichiara inoltre di valutare ulteriori irrobustimenti architetturali e meccanismi di rilevamento, fra cui lo sviluppo degli endorsement di proprietà della piattaforma. L’annuncio elenca quattro requisiti dell’attacco: accesso fisico al server, installazione fisica dell’interposer, esecuzione di software privilegiato, impossibilità di sfruttamento da remoto. Le contromisure raccomandate ai clienti sono pratiche di difesa in profondità: limitare e sorvegliare l’accesso fisico ai server, mantenere procedure sicure di gestione della filiera e dell’hardware, applicare il privilegio minimo, tenere aggiornati i sistemi.

AMD ha pubblicato il bollettino AMD-SB-3048. La posizione è più netta: la tecnica si fonda su un attacco fisico al bus di memoria, che resta fuori dal modello di minaccia pubblicato per SEV-SNP. AMD dichiara di non assegnare alcun identificativo CVE e di non prevedere mitigazioni. Il bollettino elenca come prodotti interessati le serie EPYC 4004, 4005, 8004, 9004 e 9005, con le rispettive varianti embedded a partire dalla serie 4005, e i processori Instinct MI300A.

Sulle tempistiche, l’appendice etica del paper riporta la prima segnalazione a Intel il 4 novembre 2025, con estensioni il 19 febbraio e l’8 aprile 2026. AMD è stata avvisata il 28 gennaio 2026, Arm il 29 aprile. AMD ha chiesto un periodo di riservatezza e la data di divulgazione coordinata è stata fissata al 14 settembre 2026, con il consenso di Intel. Alla chiusura di questo articolo non risultano comunicazioni specifiche dei principali fornitori cloud né un bollettino di Arm.

La contromisura allo studio identifica chi tiene l’hardware

L’annuncio di sicurezza rinvia a un documento tecnico su cui vale la pena soffermarsi, perché chiarisce la direzione presa. Si intitola «Platform Ownership Endorsements for Confidential Computing», ha identificativo 871281 ed è aggiornato al 2 febbraio 2026. Descrive un’architettura che consente a una parte remota di stabilire chi detiene fisicamente la piattaforma su cui gira il carico di lavoro.

Il meccanismo funziona così. Il proprietario raccoglie, durante la filiera di fornitura o la manutenzione, gli identificativi univoci di piattaforma generati al primo avvio. Su quegli identificativi emette un’attestazione firmata di proprietà. In fase di attestazione remota il verificatore controlla anche quell’attestazione e approva soltanto le piattaforme il cui proprietario sia riconosciuto come affidabile nel garantire la protezione fisica. Intel raccomanda il formato CoRIM e annuncia quattro strumenti di supporto, che dichiara non ancora rilasciati.

Il documento è esplicito su ciò che l’architettura non fa: nessuna piattaforma può essere completamente sicura contro gli attacchi fisici. La risposta di Intel, quindi, non elimina la soppressione delle scritture. Sposta la questione dal piano tecnologico a quello della custodia: chi ha in mano quel server, e su quale base ci fidiamo di lui.

I limiti dell’attacco

Va detto con altrettanta chiarezza che cosa DDRop non fa. L’attacco richiede sia il controllo del software privilegiato sia un accesso fisico, seppure breve e una tantum, al server bersaglio. Non è sfruttabile da remoto e non riguarda computer portatili o telefoni.

La valutazione end-to-end si appoggia a macchine con due socket, perché la memoria in genere non è distribuita fra nodi diversi e questo isola gli effetti dell’interposer. Su macchine a socket singolo, scrivono gli autori, servirebbe un controllo temporale molto più preciso dei guasti iniettati.

L’interposer usato è volutamente semplice e agisce su tutti i comandi diretti al modulo, comprese le letture. Scartare una lettura provoca un arresto del sistema, quindi l’attacco resta limitato alle operazioni che scrivono sulla zona interposta. Un dispositivo più sofisticato, basato su FPGA, supererebbe il limite a costo di complessità e spesa maggiori.

Va infine segnalato che non risultano casi di sfruttamento fuori dal laboratorio. Nessuna delle fonti primarie consultate riporta incidenti reali.

Dove la questione diventa giuridica

Da qui in avanti il testo propone una lettura. I riferimenti normativi sono verificati sui testi ufficiali; il collegamento fra DDRop e quei riferimenti è un’interpretazione della redazione.

Gli autori indicano tre vie realistiche per ottenere l’accesso fisico: personale interno al centro dati con accesso ai rack, manomissione lungo la filiera di fornitura durante trasporto o installazione, accesso imposto da autorità giudiziarie o governative. I primi due scenari appartengono al rischio operativo. Il terzo è il perno attorno a cui ruota da anni la valutazione dei trasferimenti verso paesi terzi.

La sentenza Schrems II della Corte di giustizia, del 16 luglio 2020, fissa il metodo. Le garanzie adeguate previste dall’articolo 46 del GDPR devono assicurare un livello di protezione sostanzialmente equivalente a quello garantito nell’Unione. La valutazione deve considerare due cose insieme: le clausole contrattuali fra esportatore e importatore, e gli elementi rilevanti dell’ordinamento del paese terzo quanto a un eventuale accesso delle autorità pubbliche ai dati trasferiti.

Al punto 134 la Corte assegna il compito al titolare o al responsabile del trattamento stabiliti nell’Unione, cioè all’esportatore. Spetta a lui verificare caso per caso, se del caso in collaborazione con il destinatario, se il diritto del paese di destinazione garantisca una protezione adeguata. Deve fornire, se occorre, garanzie supplementari rispetto a quelle offerte dalle clausole. Il punto 135 chiude il ragionamento: quando le misure supplementari non bastano, l’esportatore o, in subordine, l’autorità di controllo devono sospendere o far cessare il trasferimento. Il terzo punto del dispositivo lo ripete come obbligo dell’autorità, quando la protezione richiesta dal diritto dell’Unione non possa essere garantita «con altri mezzi».

Quello stesso punto del dispositivo contiene però una riserva, ed è decisiva per leggere il quadro di oggi: l’obbligo vale «a meno che esista una decisione di adeguatezza validamente adottata dalla Commissione». Dove si applica una decisione di adeguatezza, il trasferimento non richiede né lo strumento dell’articolo 46 né misure supplementari. Per gli Stati Uniti quella decisione esiste dal 10 luglio 2023, ed è il Data Privacy Framework. Il Tribunale dell’Unione europea lo ha confermato il 3 settembre 2025 nella causa Latombe; l’impugnazione davanti alla Corte di giustizia, depositata il 31 ottobre 2025, è tuttora pendente. Copre però solo i destinatari statunitensi certificati. Fuori da quel perimetro, cioè per gli importatori non aderenti e per gli altri paesi terzi, resta in piedi la valutazione caso per caso descritta sopra.

Le raccomandazioni 01/2020 del Comitato europeo per la protezione dei dati, adottate nella versione 2.0 il 18 giugno 2021 proprio per dare seguito a quella sentenza, contengono due passaggi decisivi.

Il primo è al punto 53: misure contrattuali e organizzative, da sole, in genere non impediscono l’accesso ai dati da parte delle autorità pubbliche di un paese terzo quando la legislazione applicabile è problematica. Solo misure tecniche correttamente attuate possono, in certe situazioni, rendere inefficace quell’accesso.

Il secondo è il caso d’uso 6 dell’allegato 2, ai punti 94 e 95. Riguarda il trasferimento verso fornitori cloud che devono accedere ai dati in chiaro per erogare il servizio. Lo scenario si applica quando i poteri di accesso delle autorità del paese di destinazione eccedono ciò che è necessario e proporzionato in una società democratica. In quel caso il Comitato dichiara di non riuscire a immaginare, allo stato dell’arte, una misura tecnica efficace a impedire che l’accesso leda i diritti fondamentali degli interessati. Aggiunge però che non esclude sviluppi tecnologici futuri capaci di raggiungere le finalità aziendali senza richiedere l’accesso in chiaro. Il punto 95 precisa che cifratura in transito e cifratura a riposo, anche combinate, non bastano se l’importatore possiede le chiavi.

Il confidential computing viene presentato proprio come la tecnologia che colma quella lacuna. Non è una lettura giornalistica.

I materiali con cui Intel ha presentato TDX alla conferenza OC3 del marzo 2023 elencano tre gruppi di motivazioni all’adozione. Il secondo riguarda i dati aziendali riservati o regolati, con richiamo esplicito al GDPR, e le collaborazioni fra più parti soggette a obblighi di conformità. Il terzo è intitolato al controllo del dato e alla sovranità. La sua prima voce è «get the cloud provider out of my trust boundary», cioè togliere il fornitore cloud dal proprio perimetro di fiducia.

Quella cornice non è invecchiata. Nell’intervento del marzo 2026 il confidential computing viene descritto come tecnologia fondativa, che protegge il dato in uso in ambienti cloud, sovrani e aziendali.

La presentazione del 2023 confronta i perimetri di fiducia con e senza TDX. Fuori dal perimetro finiscono lo stack cloud e i suoi amministratori, il BIOS, il firmware, il sistema operativo ospitante e l’ipervisore. Il livello fisico non compare nel confronto.

La documentazione di Azure confidential computing afferma che, quando la funzionalità è attiva e configurata correttamente, Microsoft non può accedere ai dati non cifrati del cliente. Lo stesso testo descrive un modello di minaccia che punta a togliere all’operatore del fornitore la possibilità di accedere a codice e dati durante l’esecuzione. Il sito degli autori elenca fra i contesti d’uso i servizi confidenziali di AWS, Google Cloud, Microsoft Azure e IBM Cloud, oltre alla scoperta privata dei contatti di Signal e all’elaborazione privata di WhatsApp.

DDRop non dimostra che quei servizi siano stati violati. Dimostra che la garanzia su cui poggiano ha un confine dichiarato, e che quel confine esclude proprio la categoria di avversario che la valutazione dei trasferimenti deve considerare. Gli «altri mezzi» richiamati dalla Corte, quando si parla di dato in elaborazione, sono in larga parte questi.

Il caso italiano: che cosa chiede davvero il regolamento ACN

Il regolamento per le infrastrutture digitali e per i servizi cloud per la pubblica amministrazione, adottato dall’Agenzia per la cybersicurezza nazionale con decreto direttoriale n. 21007/24 del 27 giugno 2024 e applicabile dal 1° agosto 2024, non impone il confidential computing. Impone però obblighi che presuppongono esattamente ciò che DDRop mette in discussione.

Per i dati e i servizi critici, l’allegato 3 chiede al punto 11_C un meccanismo di cifratura in cui l’amministrazione genera in autonomia almeno la chiave principale. Il modulo hardware di sicurezza che la custodisce può stare presso l’amministrazione stessa, presso il fornitore in modalità dedicata o presso una terza parte scelta dall’amministrazione.

Per il livello più alto di qualificazione, l’allegato 4 alza l’asticella. Il punto 18_SS chiede un meccanismo che consenta all’amministrazione di generare e gestire in autonomia tutte le chiavi. Il punto 19_SS chiede di garantire l’accesso esclusivo dell’amministrazione alle chiavi e ai propri dati in chiaro.

Qui sta il nodo. La gestione autonoma delle chiavi protegge il dato a riposo e in transito, non il dato in elaborazione: per essere elaborato, il dato viene decifrato nella memoria del fornitore. L’accesso esclusivo ai dati in chiaro, in quel momento, dipende da come la piattaforma isola la memoria. Il confidential computing è la risposta tecnica abituale a quel problema, e DDRop mostra che la risposta ha un limite dichiarato dai produttori stessi.

Il regolamento contiene altri due elementi che il caso rende attuali. Per i dati e i servizi strategici, il punto 15_S dell’allegato 3 obbliga il fornitore a segnalare ad ACN e all’amministrazione ogni richiesta di accesso a dati o metadati proveniente da entità extra-UE. L’accesso può essere concesso solo dopo un’autorizzazione esplicita dell’amministrazione. Sempre per il livello più alto, il fornitore deve rendere disponibili la metodologia di verifica del personale con accesso privilegiato e l’elenco dei dipendenti che ne dispongono. Da quell’elenco l’amministrazione può chiedere unilateralmente la rimozione di una o più persone.

Sono obblighi costruiti attorno all’accesso logico e alle persone. DDRop riguarda l’accesso fisico ai moduli di memoria, che nessuna di queste clausole intercetta.

Infine l’articolo 22, comma 5 riguarda i trasferimenti di dati personali fuori dallo Spazio economico europeo. In quei casi i responsabili del trattamento seguono le istruzioni dell’amministrazione e mettono a disposizione ogni informazione necessaria a valutare l’effettività delle misure adottate ai sensi del capo V del GDPR. È la cerniera fra il regolamento ACN e la valutazione descritta dalle raccomandazioni del Comitato europeo. Dopo il 14 settembre, l’informazione necessaria comprende anche il modello di minaccia coperto dalla piattaforma.

Domande da porre al fornitore

Anche questa sezione è una proposta della redazione, non una prescrizione normativa.

Quali tecnologie di confidential computing sono attive sui nodi che ospitano il servizio, e in quale modalità di integrità. La distinzione fra integrità logica e integrità crittografica su TDX cambia il quadro: la modalità crittografica avrebbe impedito i primi due casi di studio, ma non la falsificazione della misura di avvio sulla macchina dell’attaccante. Gli autori precisano di non aver potuto verificare quest’ultimo punto in laboratorio, perché il loro sistema non supportava la modalità crittografica.

Quali controlli esistono sull’accesso fisico ai rack e sulla catena di custodia dei moduli di memoria, e come vengono registrati. Sono esattamente le pratiche di difesa in profondità che Intel raccomanda nel proprio annuncio, e sono il livello su cui si sposta la protezione quando la cifratura della memoria non basta.

Quali interfacce di gestione della memoria restano attive. SEV-SNP prevede una politica che disabilita lo spostamento delle pagine dell’ospite; TDX non offre un’opzione equivalente, e l’interfaccia di gestione delle tabelle sicure è necessaria al funzionamento.

Come il fornitore intende dare seguito agli obblighi di trasparenza sui trasferimenti fuori dallo Spazio economico europeo. Se deve fornire ogni informazione utile a valutare l’effettività delle misure, il modello di minaccia della piattaforma rientra in quelle informazioni.

Che cosa afferma esattamente la documentazione contrattuale e di conformità già consegnata. Se un documento sostiene che il fornitore non può tecnicamente accedere ai dati, vale la pena verificare che l’affermazione sia circoscritta al modello di minaccia effettivamente coperto.

Le contromisure discusse nel paper

Gli autori valutano tre direzioni. Il rilevamento dell’interposer attraverso i tempi di addestramento della memoria all’avvio funziona in via di principio: l’esperimento mostra un aumento misurabile del ritardo sullo slot interposto. La sua adozione richiederebbe però una validazione estesa su schede madri, controllori e implementazioni di firmware diverse, e un modulo malevolo potrebbe integrare gli interruttori a bordo per ridurre il ritardo osservabile.

La verifica a tempo di esecuzione consiste nello scrivere un motivo noto in un’area riservata di ogni modulo e rileggerlo. È un’euristica, aggirabile da un interposer che scarti le scritture in modo più selettivo.

L’irrobustimento del software comprende la disattivazione delle interfacce non necessarie e la rilettura di controllo dopo le operazioni critiche. Nessuna di queste misure introduce la freschezza. Gli autori sono espliciti: una correzione duratura richiede motori di cifratura della memoria che offrano insieme integrità e freschezza, quindi una modifica dell’hardware.

Intel, dal canto suo, sta lavorando su cinque fronti, elencati nell’intervento di marzo: endorsement di proprietà della piattaforma, riduzione della superficie d’attacco delle enclave, attestazione radicata nell’hardware, ricerca sul rilevamento delle manomissioni fisiche e nuova generazione di cifratura della memoria.

L’ultimo punto è quello che tocca DDRop. La spinta, dichiara Intel, viene dalla scala dell’intelligenza artificiale confidenziale, che sta mettendo sotto pressione i limiti della cifratura basata su AES e il suo modello di costo. La direzione allo studio è una costruzione basata su ASCON, con blocchi più grandi e versionamento opzionale delle linee di cache. Intel la presenta come resistenza più forte alla manomissione fisica della memoria e agli attacchi di replay. Il paper osserva però che non è chiaro se quel disegno neutralizzerebbe la soppressione delle scritture.

In sintesi

DDRop non è una vulnerabilità da correggere con un aggiornamento. È la conferma sperimentale di un compromesso di progetto noto, portata al livello di costo e di praticabilità che rende il discorso concreto. La risposta dei due produttori conferma che quel compromesso è voluto.

Per chi scrive valutazioni d’impatto, contratti e dichiarazioni di conformità la conseguenza è più semplice di quanto appaia: le affermazioni sul confidential computing vanno formulate indicando il modello di minaccia coperto, non come garanzie assolute.