Suporte TRIM via dm-crypt / device-mapper

Conseguir um novo laptop com SSD amanhã. Eu preciso saber sobre o status atual do dm-crypt e TRIM. Vi vários relatórios conflitantes e a maioria das atividades em torno dessa questão parece ter mais de um ano. Alguns dizem que a passagem TRIM do dm-crypt foi incluída em várias versões recentes do kernel (o que não é um problema para mim, pois eu uso o Arch). Alguns dizem que o apoio ainda não existe. Posso obter uma resposta clara e bem fundamentada sobre o status do suporte ao TRIM dm-crypt? confirmações do git ou anúncios da lista de discussão que mencionam esse recurso seriam ideais.

A resposta a essa pergunta tem grande potencial para influenciar a maneira como eu arquiteto os discos do meu novo laptop. Espero que seja útil para outros ter uma resposta decente e atualizada.

Para o registro, essa funcionalidade NÃO existia quando publiquei esta pergunta pela primeira vez. Eu perguntei na lista de discussão e fui informado por Milan Broz que descartar a passagem para alvos dm-crypt ainda não havia sido implementada. Milan indicou que pretendia implementar isso em algum momento, mas não afirmou quando.

Depois de pesquisar um pouco no dm-crypt.c e nos arquivos relacionados por um tempo, parecia que o suporte ao TRIM seria bastante simples de adicionar. Escrevi a lista pedindo conselhos gerais sobre a tarefa antes de começar. No dia seguinte, o Milan enviou um patch que implementa a passagem TRIM no dm-crypt e isso foi apresentado no linux-next. Ele deve ser incluído no kernel do Linux 3.1.

A passagem do TRIM deve ser ativada explicitamente. Existem possíveis problemas de segurança no uso do TRIM em um dispositivo dm-crypt'd, porque o TRIM envia informações sobre o uso do bloco para o firmware no dispositivo, que marca as áreas liberadas recentemente como utilizáveis ​​(pelo que entendi). Isso significa que uma parte interessada pode obter informações sobre os padrões de uso do disco. Por exemplo, foi postulado que um invasor poderia quase definitivamente aprender qual sistema de arquivos estava em uso na mídia criptografada através desses dados. Um invasor também pode aprender informações mais úteis, como se você tivesse muitos arquivos grandes salvos até recentemente (grandes blocos contíguos do TRIM).

Por favor, veja estes tópicos para referência:

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: TRIM O suporte de passagem para destinos dm-crypt existirá no Linux> = 3.1, mas deve ser ativado manualmente via cryptsetup e / ou dmsetup devido ao vazamento de dados que pode permitir a criação de perfil com base nos padrões de uso do disco.

A partir do kernel 3.2.x, o dm-crypt + brtfs deveria ser seguro. Veja a resposta à minha pergunta de Chris Mason:

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

De acordo com este post ...

Minha pergunta é: O que acontece se uma camada dm-crypt estiver entre o sistema de arquivos e o dispositivo de bloco real? A guarnição será passada ou será descartada?

Supõe que será passado. Estou usando o btrfs em um SSD criptografado com LUKS / dmcrypt, e funciona muito bem. O Btrfs usa um trim bastante tempo.

Você também pode precisar de discardopções de montagem do sistema de arquivos.

Bem, há esta discussão

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

e essa ferramenta

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

Ainda não o usei, mas também estou interessado neste problema.