Soporte TRIM a través de dm-crypt / device-mapper

9

Conseguir una nueva computadora portátil con SSD mañana. Necesito saber sobre el estado actual de dm-crypt y TRIM. He visto varios informes contradictorios y la mayor parte de la actividad en torno a esta pregunta parece tener más de 1 año. Algunos dicen que el paso a través de TRIM dm-crypt se ha incluido en varias versiones recientes del kernel (lo cual no es un problema para mí, ya que uso Arch). Algunos dicen que el soporte aún no existe. ¿Puedo obtener una respuesta clara y bien fundamentada sobre el estado del soporte de dm-crypt TRIM? git commits o anuncios de listas de correo que mencionan esta característica sería ideal.

La respuesta a esta pregunta tiene un gran potencial para influir en la forma en que diseño los discos de mi nueva computadora portátil. Esperemos que sea útil para otros tener una respuesta decente y actualizada.

ssd luks device-mapper jeffcook2150
fuente

Respuestas:

9

Para el registro, esta funcionalidad NO existía cuando publiqué esta pregunta por primera vez. Pregunté en la lista de correo y Milan Broz me informó que todavía no se había implementado el descarte para los objetivos de dm-crypt. Milan indicó que tenía la intención de implementar esto en algún momento, pero no dijo cuándo.

Después de hurgar un tiempo en dm-crypt.c y archivos relacionados por un tiempo, parecía que el soporte TRIM sería bastante trivial para agregar. Escribí la lista pidiendo su asesoramiento general sobre la tarea antes de saltar. Al día siguiente, Milán presentó un parche que implementa el paso TRIM en dm-crypt y esto se ha organizado en linux-next. Debe incluirse en el kernel de Linux 3.1.

El paso a través de TRIM debe habilitarse explícitamente. Existen posibles problemas de seguridad al usar TRIM en un dispositivo dm-crypt'd, porque TRIM envía información sobre el uso de bloques al firmware en el dispositivo que luego marca las áreas liberadas recientemente como utilizables (de todos modos, según entiendo). Esto significa que una parte interesada puede obtener información sobre los patrones de uso del disco. Por ejemplo, se postuló que un atacante podría casi definitivamente aprender qué sistema de archivos estaba en uso en el medio cifrado a través de estos datos. Un atacante también puede obtener información más útil, como que tenía muchos archivos grandes guardados hasta hace poco (grandes bloques contiguos TRIM).

Por favor vea estos hilos para referencia:

http://www.redhat.com/archives/dm-devel/2011-June/msg00093.html

http://www.redhat.com/archives/dm-devel/2011-July/msg00042.html

http://www.redhat.com/archives/dm-devel/2011-July/msg00088.html

tl; dr: el soporte de transferencia TRIM para dm-crypt objetivos existirá en Linux> = 3.1 pero debe habilitarse manualmente a través de cryptsetup y / o dmsetup debido a la fuga de datos que puede permitir la creación de perfiles según los patrones de uso del disco.

jeffcook2150
fuente
0

Según esta publicación ...

Mi pregunta es: ¿qué sucede si una capa dm-crypt se encuentra entre el sistema de archivos y el dispositivo de bloque real? ¿Se pasará la moldura o se descartará?

Supongo que se pasará. Estoy usando btrfs en un SSD que está encriptado con LUKS / dmcrypt, y funciona muy bien. Btrfs usa ata trim bastante tiempo.

También puede necesitar discarden las opciones de montaje del sistema de archivos.

usuario1686
fuente
Gracias, pero esa respuesta aún no es definitiva y tiene más de un año. Me gustaría una respuesta definitiva y reciente. Supongo que tendré que enviar la lista por correo, esperando que SU sea un atajo rápido: p
jeffcook2150
Bueno, si ya funcionó hace un año ...
user1686
"Supongo que funciona porque mi SSD no es lenta" no es realmente un indicador confiable de si el soporte TRIM es realmente funcional.
jeffcook2150
Que es exactamente lo que nunca he dicho.
user1686
Eso es lo que dice la publicación que has citado.
jeffcook2150