Prise en charge de TRIM via dm-crypt / device-mapper

Obtenir un nouvel ordinateur portable avec SSD demain. J'ai besoin de connaître l'état actuel de dm-crypt et TRIM. J'ai vu plusieurs rapports contradictoires et la plupart des activités autour de cette question semblent avoir plus d'un an. Certains disent que le passthrough dm-crypt TRIM a été inclus dans plusieurs versions récentes du noyau (ce qui n'est pas un problème pour moi, car j'utilise Arch). Certains disent que le soutien n'existe toujours pas. Puis-je obtenir une réponse claire et bien fournie sur l'état de la prise en charge de dm-crypt TRIM? git s'engage ou annonce de liste de diffusion qui mentionne cette fonctionnalité serait idéale.

La réponse à cette question a un grand potentiel pour influencer la façon dont j'architecte les disques de mon nouvel ordinateur portable. J'espère qu'il sera utile à d'autres d'avoir une réponse décente et à jour.

Pour mémoire, cette fonctionnalité n'existait PAS lorsque j'ai publié cette question pour la première fois. J'ai demandé sur la liste de diffusion et j'ai été informé par Milan Broz que le transfert de rejet pour les cibles dm-crypt n'avait toujours pas été mis en œuvre. Milan a indiqué qu'il avait l'intention de mettre cela en œuvre à un moment donné, mais n'a pas précisé quand.

Après avoir fouillé dans dm-crypt.c et les fichiers associés pendant un certain temps, il est apparu que la prise en charge de TRIM serait assez triviale à ajouter. J'ai écrit la liste en demandant leur avis général sur la tâche avant de me lancer. Le lendemain, Milan a soumis un correctif qui implémente le passage TRIM sur dm-crypt et cela a été mis en scène dans linux-next. Il devrait être inclus dans le noyau Linux 3.1.

Le passthrough TRIM doit être activé explicitement. Il y a des problèmes de sécurité potentiels dans l'utilisation de TRIM sur un appareil dm-crypté, car TRIM envoie des informations sur l'utilisation des blocs au micrologiciel sur l'appareil qui marque ensuite les zones récemment libérées comme utilisables (si je comprends bien, de toute façon). Cela signifie qu'une partie intéressée peut obtenir des informations sur les modèles d'utilisation du disque. Par exemple, il a été postulé qu'un attaquant pourrait presque certainement savoir quel système de fichiers était utilisé sur le support chiffré grâce à ces données. Un attaquant peut également être en mesure d'apprendre des informations plus utiles, comme le fait que vous aviez beaucoup de gros fichiers enregistrés jusqu'à récemment (gros blocs contigus TRIM).

Veuillez consulter ces fils pour référence:

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: la prise en charge du relais TRIM pour les cibles dm-crypt existera sous Linux> = 3.1 mais doit être activée manuellement via cryptsetup et / ou dmsetup en raison d'une fuite de données qui peut permettre un profilage basé sur les modèles d'utilisation du disque.

Depuis le noyau 3.2.x, dm-crypt + brtfs est censé être sûr. Voir la réponse à ma question de Chris Mason:

http://permalink.gmane.org/gmane.comp.file-systems.btrfs/15554 et http://permalink.gmane.org/gmane.comp.file-systems.btrfs/15564

Selon ce post ...

Ma question est la suivante: que se passe-t-il si une couche dm-crypt est entre le système de fichiers et le véritable bloc-périphérique? La garniture sera-t-elle passée ou sera-t-elle jetée?

Il suppose qu'il sera transmis. J'utilise btrfs sur un SSD qui est crypté avec LUKS / dmcrypt, et cela fonctionne très bien. Btrfs utilise ata trim depuis un bon moment.

Vous pourriez également avoir besoin discarddans les options de montage du système de fichiers.

il y a bien ce fil

https://bbs.archlinux.org/viewtopic.php?id=114924

et cet outil

http://sourceforge.net/tracker/index.php?func=detail&aid=2997551&group_id=136732&atid=736684

Je ne l'ai pas encore utilisé, mais je suis également intéressé par ce problème.