Sobrecarga de E / S do dispositivo criptografado por dm?

Qual seria a sobrecarga de leitura / gravação ao usar o dm-crypt (LUKS) como criptografia de disco completa (incluindo partição raiz) em um desktop Linux (Ubuntu)? Eu pretendo empilhá-lo da seguinte forma: LUKS> LVM> ext4 A CPU em uso no sistema seria um Core2 Duo 2.1 GHz com 4 GB de RAM.

A criptografia desse sistema criaria uma sobrecarga excelente / perceptível?
Existem benchmarks recentes encontrados na rede? Qual é a sua experiência pessoal?
Existem configurações que eu possa fazer para melhorar o desempenho?

Obrigado pela sua ajuda.

— jottr
fonte

Não há sobrecarga de E / S envolvida no dm-crypt - apenas sobrecarga da CPU ...;)

Em um sistema de núcleo duplo Athlon 64 de 2,6 GHz, por exemplo, posso copiar de um disco dm-crypt para outro com ~ 40 MB / s (2.6.26 Kernel, discos SATA de Seagate de 1,5 TB).

Para obter desempenho, verifique se o módulo aes otimizado para sua arquitetura está carregado, por exemplo

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

Em relação à segurança dos dados, não há necessidade de desativar o cache de gravação devido ao dm-crypt. As versões antigas não suportavam barreiras de gravação, mas desde 2010 (kernel 2.6.31 ou mais) o dm-crypt as suporta (respectivamente force-unit-access - FUA).

Btw, pode-se argumentar que realmente não faz sentido criptografar a partição raiz.

No entanto, a troca criptografada faz sentido.

— maxschlepzig
fonte

Pode-se argumentar também que mexer com o hdparm quando você não sabe o que está fazendo (ou apenas pensa que sabe) pode danificar seus discos rígidos.

— Amphetamachine

Criptografar a partição raiz faz sentido se o modelo de ameaça incluir a possibilidade de um adversário obter acesso físico temporário e inicializar no modo de usuário único ou a partir de uma unidade USB e instalar malware como um key-logger ou rootkit. Para usuários regulares, isso também significa não ter que se preocupar em esquecer de criptografar /tmp(se não estiver montado com `tmpfs) e outros diretórios que possam vazar dados privados.

— Anthony Geoghegan

@AnthonyGeoghegan, isso talvez seja eficaz contra alguns adversários. Mas para se proteger contra o modelo de ameaça que você descreve, também é necessário proteger o carregador de inicialização (por exemplo, com um firmware que verifica criptograficamente o carregador de inicialização antes de executá-lo).

— maxschlepzig

@maxschlepzig Esse pensamento me ocorreu quando escrevi o comentário, mas não queria exagerar com isenções de responsabilidade e ressalvas em uma pequena caixa de comentários. A segunda razão é provavelmente mais importante: eu uso o FDE (no meu laptop de 10 anos) para não precisar me preocupar tanto com credenciais e chaves privadas /etcou com outros dados confidenciais de alguma forma sendo registrados /var/(votados, BTW )

— Anthony Geoghegan 11/10

O Ext4 pode ser uma má escolha do sistema de arquivos se você planeja executar instantâneos do LVM. Eu recomendaria a verificação substancial do desempenho do disco antes de entrar em operação, experimentando tamanhos de bloco no FS e no LVM. Minha experiência foi com o Ext3, mas os outros artigos que vi na época implicavam que o Ext4 tinha problemas semelhantes.

Eu o resolvi usando o XFS como sistema de arquivos.

— Michael Shaw
fonte