{"id":182443,"date":"2026-07-02T22:53:28","date_gmt":"2026-07-02T20:53:29","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/problemy-s-ochistkoj-klyuchej-shifrovaniya-diska-iz-ozu-pri-perehode-linux-v-zhdushhij-rezhim"},"modified":"2026-07-02T22:53:28","modified_gmt":"2026-07-02T20:53:29","slug":"problemy-s-ochistkoj-klyuchej-shifrovaniya-diska-iz-ozu-pri-perehode-linux-v-zhdushhij-rezhim","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/news\/problemy-s-ochistkoj-klyuchej-shifrovaniya-diska-iz-ozu-pri-perehode-linux-v-zhdushhij-rezhim","title":{"rendered":"Problemi con la cancellazione delle chiavi di crittografia del disco dalla RAM durante il passaggio di Linux alla modalit\u00e0 sospensione","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Durante il porting per NixOS dello strumento cryptsetup-suspend \u00e8 stato scoperto un errore nel sottosistema di crittografia del disco LUKS (Linux Unified Key Setup), a causa del quale, a partire dal kernel Linux 6.9 (commit problematico), rilasciato a maggio 2024, la pulizia delle chiavi di crittografia dalla memoria RAM ha smesso di funzionare quando il sistema va in modalit\u00e0 sospensione. <\/p>\n
Lo strumento cryptsetup-suspend \u00e8 utilizzato in Debian per il blocco automatico delle partizioni LUKS prima di entrare in modalit\u00e0 sospensione. Si presume che, in caso di furto di un laptop messo in modalit\u00e0 sospensione, il malintenzionato non possa accedere ai dati, poich\u00e9 al risveglio sar\u00e0 necessario inserire una password per ripristinare l'accesso ai dati crittografati. A causa di un errore nel kernel Linux, dopo il blocco della partizione LUKS con il comando \u00abcryptsetup luksSuspend\u00bb, le chiavi non venivano cancellate dalla memoria RAM e rimanevano visibili attraverso \/proc\/keys, consentendo all'attaccante di estrarle, ad esempio, tramite un \u00abcold reboot\u00bb e utilizzarle per accedere ai dati. <\/p>\n
L'assenza di pulizia delle chiavi \u00e8 stata scoperta durante il debug di una condizione di race, che causava problemi nel passaggio alla modalit\u00e0 sospensione. L'errore \u00e8 emerso dopo un rifactoring nel kernel 6.9, che legava le chiavi al thread chiamante, il quale avrebbe dovuto essere eliminato al termine della sua esecuzione, ma in realt\u00e0 rimaneva in memoria. \u00c8 stata proposta una patch in un'unica riga per il kernel Linux, che risolve l'errore riscontrato. <\/p>\n
Questo patch non \u00e8 stata accettata nel kernel, poich\u00e9 presenta un difetto: il patch funziona solo per i dispositivi di archiviazione fisici, mentre non funziona per i dispositivi virtuali loop. Invece di correggere il problema a livello di kernel, gli sviluppatori dello strumento cryptsetup hanno proposto una soluzione temporanea per la cancellazione delle chiavi. Questa modifica \u00e8 gi\u00e0 stata accettata e sar\u00e0 inclusa nella versione di cryptsetup 2.8.7. <\/p>\n