Questo è stato cross-postato su electronics.stackexchange. La risposta breve è che non è possibile rilevare tutto questo tipo di attacco hardware ostile nel software.
Se sul bus era presente un dispositivo di rilevamento che richiedeva attivamente letture della memoria, sarebbe possibile rilevarlo osservando i ritardi nella lettura della memoria. Dovresti andare a cercarlo specificatamente impostando una lettura senza cache con misure temporali prima e dopo, ma puoi rilevarla.
Tuttavia, se costruissi questo tipo di sistema di attacco avrei semplicemente una RAM a doppia porta shadow connessa alle stesse linee di scrittura, memorizzando una copia di tutto l'accesso alla memoria sin dall'avvio. Potrei quindi leggere dalla copia senza interrompere i tempi dell'accesso alla memoria principale. Non è banale costruire una cosa del genere - richiede un'attenta attenzione per evitare di interrompere i segnali elettrici nella RAM - ma è abbastanza fattibile contro la DRAM presa o saldata. Non è fattibile contro la RAM interna di un SoC, o una RAM di stack in pila come nel Raspberry Pi.
(Questo non deve essere confuso con "snooping della cache", che è una parte normale di un sistema multiprocessore)
Modifica in risposta al commento: non è particolarmente diverso su un sistema multiprocessore; su un sistema NUMA è necessaria una sonda di snooping per bus di memoria. È sicuramente qualcosa che richiede molto impegno e accesso fisico, quindi è principalmente utilizzato per penetrare in dispositivi di tua proprietà come console di gioco e telefoni cellulari. Non è qualcosa che mi aspetterei di vedere in un datacenter; è probabile che le macchine target ad alto valore siano bloccate in casi di allarme anti-manomissione per difendersi da questo tipo di cose.
(Riferimenti? Questo SE ha un divieto in stile Wikipedia sulla ricerca originale?)