Overhead I / O del dispositivo crittografato dm?

Quale sarebbe l'overhead di lettura / scrittura quando si utilizza dm-crypt (LUKS) come crittografia completa del disco (inclusa la partizione di root) su un desktop Linux (Ubuntu)? Ho intenzione di impilarlo in questo modo: LUKS> LVM> ext4 La CPU in uso sul sistema sarebbe un Core2 Duo 2.1 GHz con 4 GB di RAM.

La crittografia di un tale sistema creerebbe un sovraccarico notevole / evidente?
Esistono benchmark recenti da trovare in rete? Qual è la tua esperienza personale?
Ci sono delle impostazioni che posso effettuare per migliorare le prestazioni?

Grazie per il vostro aiuto.

— jottr
fonte

Non vi è alcun sovraccarico di I / O coinvolto in dm-crypt - solo un sovraccarico della CPU ...;)

Su un sistema dual core Athlon 64 da 2,6 GHz, ad esempio, posso copiare da un disco dm-crypt ad un altro con ~ 40 MB / sec (kernel 2.6.26, dischi SATA Seagate da 1,5 TB).

Per le prestazioni, assicurarsi che sia caricato il modulo aes ottimizzato per la propria architettura, ad es

$ lsmod | grep aes
aes_x86_64             12416  6 
aes_generic            32552  1 aes_x86_64

Per quanto riguarda la sicurezza dei dati, non è necessario disabilitare la cache di scrittura a causa di dm-crypt. Le vecchie versioni non supportavano le barriere di scrittura, ma dal 2010 (kernel 2.6.31 o giù di lì) dm-crypt le supporta (rispettivamente force-unit-access - FUA).

A proposito, si può sostenere che non ha davvero senso crittografare la partizione di root.

Tuttavia, lo scambio di crittografia ha senso.

— maxschlepzig
fonte

Si potrebbe anche obiettare che scherzare con hdparm quando non sai cosa stai facendo (o pensi solo di sapere) può danneggiare i tuoi dischi rigidi.

— anfetamachina,

La crittografia della partizione di root ha senso se il modello di minaccia include la possibilità che un avversario ottenga un accesso fisico temporaneo e si avvii in modalità utente singolo o da un'unità USB e installi malware come un key-logger o un rootkit. Per gli utenti regolari, significa anche non doversi preoccupare di dimenticare di crittografare /tmp(se non è montato con `tmpfs) e qualsiasi altra directory che potrebbe perdere dati privati.

— Anthony Geoghegan,

@AnthonyGeoghegan, questo è forse efficace contro alcuni avversari. Ma per proteggerti dal modello di minaccia che descrivi devi anche proteggere il bootloader (ad es. Con un firmware che controlla crittograficamente il bootloader prima di eseguirlo).

— maxschlepzig,

@maxschlepzig Mi è venuto in mente questo pensiero mentre scrivevo il commento prima, ma non volevo esagerare con dichiarazioni di non responsabilità e clausole in una piccola casella di commento. Il secondo motivo è probabilmente più importante: utilizzo FDE (sul mio laptop di 10 anni), quindi non devo preoccuparmi (tanto) delle credenziali e delle chiavi private /etco di altri dati sensibili in qualche modo su cui effettuare l'accesso /var/(votato, BTW ).

— Anthony Geoghegan,

Ext4 potrebbe essere una cattiva scelta del filesystem se stai pianificando di eseguire snapshot LVM. Consiglierei di fare un controllo sostanziale delle prestazioni del disco prima di andare in diretta, sperimentando con blocchi di dimensioni sia su FS che su LVM. La mia esperienza è stata con Ext3, ma gli altri articoli che ho visto in quel momento implicavano che Ext4 avesse problemi simili.

L'ho risolto usando XFS come filesystem.

— Michael Shaw
fonte