Затраты на ввод / вывод устройства с шифрованием дм?

Каковы будут издержки чтения / записи при использовании dm-crypt (LUKS) в качестве полного шифрования диска (включая корневой раздел) на рабочем столе Linux (Ubuntu)? Я планирую сделать это следующим образом: LUKS> LVM> ext4 Процессором, используемым в системе, будет Core2 Duo 2,1 ГГц с 4 ГБ ОЗУ.

Будет ли шифрование такой системы создавать большие / заметные накладные расходы?
Есть ли какие-либо недавние ориентиры, которые можно найти в сети? Каков твой личный опыт?
Могу ли я сделать какие-либо настройки для повышения производительности?

Спасибо за вашу помощь.

— jottr
источник

В dm-crypt не задействованы затраты ввода-вывода - только загрузка процессора ...;)

Например, в двухъядерной системе Athlon 64 с частотой 2,6 ГГц я могу копировать с одного dm-crypt-диска на другой со скоростью ~ 40 МБ / с (ядро 2.6.26, диски Seagate 1,5 ТБ SATA).

Для производительности убедитесь, что загружен оптимизированный для вашей архитектуры модуль aes, например:

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

Что касается безопасности данных, нет необходимости отключать кэш записи из-за dm-crypt. Старые версии не поддерживали барьеры записи, но с 2010 года (ядро 2.6.31 или около того) dm-crypt поддерживает их (соответственно force-unit-access - FUA).

Кстати, можно утверждать, что на самом деле не имеет смысла шифровать корневой раздел.

Однако шифрование подкачки имеет смысл.

— maxschlepzig
источник

Можно также утверждать, что возиться с hdparm, когда вы не знаете, что делаете (или только думаете, что знаете), может повредить ваши жесткие диски.

— амфетамина

Шифрование корневого раздела имеет смысл, если ваша модель угроз включает в себя возможность получения злоумышленником временного физического доступа и загрузки в однопользовательском режиме или с USB-накопителя и установки вредоносных программ, таких как клавиатурный шпион или руткит. Для обычных пользователей это также означает, что вам не нужно беспокоиться о том, что вы забыли зашифровать /tmp(если он не смонтирован с помощью `tmpfs) и любые другие каталоги, которые могут утечь личные данные.

— Энтони Геогеган,

@AnthonyGeoghegan, это возможно эффективно против некоторых противников. Но для защиты от модели угрозы, которую вы описываете, вы также должны защитить загрузчик (например, с помощью встроенного программного обеспечения, которое криптографически проверяет загрузчик перед его выполнением).

— maxschlepzig

@maxschlepzig Эта мысль пришла мне в голову, когда я писал комментарий ранее, но я не хотел зацикливаться на отказах и оговорках в небольшом поле для комментариев. Вторая причина, вероятно, более важна: я использую FDE (на своем 10-летнем ноутбуке), поэтому мне не нужно беспокоиться (столько) о учетных данных и закрытых ключах /etcили о некоторых других конфиденциальных данных, которые каким-либо образом регистрируются /var/(upvoted, BTW) ).

— Энтони Геогеган

Ext4 может быть плохим выбором файловой системы, если вы планируете делать снимки LVM. Я бы посоветовал сделать существенную проверку производительности диска перед началом работы, экспериментируя с размерами блоков как на FS, так и на LVM. Мой опыт был с Ext3, но другие статьи, которые я видел в то время, подразумевали, что у Ext4 были проблемы с симуляцией.

Я решил это, используя XFS в качестве файловой системы.

— Майкл Шоу
источник