Поддержка TRIM через dm-crypt/device-mapper
Завтра получим новый ноутбук с SSD. Мне нужно знать о текущем статусе dm-crypt и TRIM. Я видел несколько противоречивых сообщений, и большая часть активности вокруг этого вопроса, кажется, старше 1 года. Некоторые говорят, что TRIM-пропуск dm-crypt был включен в несколько последних версий ядра (для меня это не проблема, так как я использую Arch). Некоторые говорят, что поддержки до сих пор не существует. Могу ли я получить четкий и точный ответ о состоянии поддержки TRIM в dm-crypt? Git коммитов или рассылки объявлений, которые упоминают эту функцию, было бы идеально.
Ответ на этот вопрос имеет большой потенциал, чтобы повлиять на то, как я создаю диски для моего нового ноутбука. Надеюсь, кому-то будет полезно получить достойный, актуальный ответ.
4 ответа
Для записи, эта функциональность НЕ существовала, когда я впервые опубликовал этот вопрос. Я спросил в списке рассылки, и Милан Броз сообщил мне, что отмена передачи для целей dm-crypt до сих пор не реализована. Милан указал, что намерен реализовать это в какой-то момент, но не уточнил, когда.
Некоторое время копаясь в dm-crypt.c и связанных с ним файлах, оказалось, что добавить поддержку TRIM будет довольно тривиально. Я написал список с просьбой дать им общие рекомендации по этой задаче, прежде чем приступить к работе. На следующий день Милан представил патч, который реализует сквозную передачу TRIM на dm-crypt, и он был встроен в linux-next. Он должен быть включен в ядро Linux 3.1.
TRIM passthrough должен быть включен явно. Существуют потенциальные проблемы безопасности при использовании TRIM на устройстве dm-crypt'd, потому что TRIM отправляет информацию об использовании блока встроенному программному обеспечению на устройстве, которое затем помечает недавно освобожденные области как пригодные для использования (в любом случае, насколько я понимаю). Это означает, что заинтересованная сторона может получить информацию о моделях использования диска. Например, постулировалось, что злоумышленник может почти точно узнать, какая файловая система использовалась на зашифрованном носителе, используя эти данные. Злоумышленник также может узнать больше полезной информации, например, что до недавнего времени у вас было сохранено много больших файлов (большие смежные блоки TRIM).
Пожалуйста, смотрите эти темы для справки:
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 сквозная поддержка для целей dm-crypt будет существовать в Linux> = 3.1, но должна быть включена вручную через cryptsetup и / или dmsetup из-за утечки данных, которая может позволить профилирование на основе шаблонов использования диска.
Начиная с ядра 3.2.x, dm-crypt + brtfs считается безопасным. Смотрите ответ на мой вопрос от Криса Мейсона:
http://permalink.gmane.org/gmane.comp.file-systems.btrfs/15554 и http://permalink.gmane.org/gmane.comp.file-systems.btrfs/15564
Ну есть эта тема
https://bbs.archlinux.org/viewtopic.php?id=114924
и этот инструмент
http://sourceforge.net/tracker/index.php?func=detail&aid=2997551&group_id=136732&atid=736684
Я еще не использовал это, но я также заинтересован в этой проблеме.
Согласно этому посту...
Мой вопрос: что произойдет, если между файловой системой и реальным блочным устройством находится слой dm-crypt? Будет ли отделка пропущена или она будет отброшена?
Думаю, это будет пройдено. Я использую btrfs на SSD, который зашифрован с помощью LUKS/dmcrypt, и он прекрасно работает. Btrfs довольно долго использует ata trim.
Вам также может понадобиться discard в опциях монтирования файловой системы.