¿Sobrecarga de E / S del dispositivo cifrado con dm?

¿Cuál sería la sobrecarga de lectura / escritura cuando se usa dm-crypt (LUKS) como cifrado de disco completo (incluida la partición raíz) en un escritorio Linux (Ubuntu)? Planeo apilarlo así: LUKS> LVM> ext4 La CPU en uso en el sistema sería un Core2 Duo 2.1 GHz con 4GB de RAM.

¿El cifrado de tal sistema crearía una sobrecarga notable / notable?
¿Hay algún punto de referencia reciente en la red? ¿Cuál es tu experiencia personal?
¿Hay alguna configuración que pueda hacer para mejorar el rendimiento?

Gracias por tu ayuda.

— jottr
fuente

No hay gastos generales de E / S involucrados en dm-crypt, solo gastos generales de CPU ...;)

En un sistema Athlon 64 de 2.6 GHz de doble núcleo, por ejemplo, puedo copiar de un disco dm-crypt a otro con ~ 40 MB / seg (2.6.26 Kernel, discos Seagate 1.5 TB SATA).

Para el rendimiento, asegúrese de que el módulo aes optimizado para su arquitectura esté cargado, por ejemplo

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

Con respecto a la seguridad de los datos, no es necesario deshabilitar la caché de escritura debido a dm-crypt. Las versiones anteriores no admitían barreras de escritura, pero desde 2010 (kernel 2.6.31 más o menos) dm-crypt sí las admite (respectivamente, force-unit-access - FUA).

Por cierto, uno puede argumentar que realmente no tiene sentido cifrar la partición raíz.

Sin embargo, el intercambio de cifrado tiene sentido.

— maxschlepzig
fuente

También se podría argumentar que jugar con hdparm cuando no sabes lo que estás haciendo (o solo crees que lo sabes) puede dañar tus discos duros.

— anfetamáquina

Cifrar la partición raíz tiene sentido si su modelo de amenaza incluye la posibilidad de que un adversario obtenga acceso físico temporal y arranque en modo de usuario único o desde una unidad USB e instale malware como un key-logger o rootkit. Para los usuarios habituales, también significa no tener que preocuparse por olvidar cifrar /tmp(si no está montado con `tmpfs) y cualquier otro directorio que pueda filtrar datos privados.

— Anthony Geoghegan

@AnthonyGeoghegan, esto quizás sea efectivo contra algunos adversarios. Pero para protegerse contra el modelo de amenaza que describe, también debe proteger el cargador de arranque (por ejemplo, con un firmware que verifica criptográficamente el cargador de arranque antes de ejecutarlo).

— maxschlepzig

@maxschlepzig Ese mismo pensamiento se me ocurrió cuando escribí el comentario antes, pero no quería exagerar con las renuncias y las condiciones en un pequeño cuadro de comentarios. La segunda razón es probablemente más importante: uso FDE (en mi computadora portátil de 10 años) para no tener que preocuparme (tanto) por las credenciales y las claves privadas /etcu otros datos confidenciales que de alguna manera se registran /var/(upvoted, BTW )

— Anthony Geoghegan el

Ext4 puede ser una mala elección del sistema de archivos si planea realizar instantáneas LVM. Aconsejaría realizar una comprobación sustancial del rendimiento del disco antes de ponerlo en funcionamiento, experimentar con tamaños de bloque en FS y LVM. Mi experiencia fue con Ext3, pero los otros artículos que vi en ese momento implicaban que Ext4 tenía problemas similares.

Lo resolví usando XFS como sistema de archivos.

— Michael Shaw
fuente