Мне всё-таки кажется, что ZFS на лэптопе с одним диском - это overkill. Ейный драйвер и оперативки хавает больше, и не понятно какие ещё плюсы у данного решения, кроме нативной поддержки шифрования. С этим сталкиваешься только один раз - когда сетапишься. А жить потом с этим всю ноутбучную жизнь ) Поэтому, имхо, не так существенно через какое место там шифрование сделано, если только на перформансе это не сказывается.
сб, 23 мая 2020 г. в 13:04, Sergey Matveev <stargr...@stargrave.org>: > *** Maksim Dmitrichenko [2020-05-23 01:47]: > >2) А что собственно с TRIM? Почитал какой-то flame war, что дескать TRIM > >уменьшает безопасность шифрования. Что, прям так сильно бьет? > > TRIM это просто утечка знаний/информации о том что вы там что-то у себя > удаляется, а также конкретные места где вы это что-то удалили. Если > злоумышленник, видя ваш зашифрованный диск (как? другой вопрос), > отправил вам файл по почте, файл к вам упал и сохранился на диске: он > видит изменение какого-то блока (+плюс блоки метаинформации). А когда вы > удалили файл, то он видит, что именно этот блок снова стал пустым и он с > высокой долей вероятностью может сказать что файл удалён (или переписан, > если это CoW ФС типа ZFS или btrfs). > > В общем, утечка метаинформации есть и тут уж каждый сам решает готов он > на такую жертву пойти или нет. Лично мне кажется, что преобладающему > большинству пользователей будет пофиг на подобное. Поэтому смело можно > (и нужно!) использовать TRIM. > > Кстати, в native ZFS шифровании точно такая же проблема: подобная > метаинформация тоже утекает злоумышленнику (как и кол-во используемого > места например). В этой рассылке уже как-то обсуждался native ZFS > encryption vs ZFS over LUKS/whatever. В принципе, LUKS/whatever (даже с > TRIM) более безопасен, но тоже из серии сильно гипотетически > теоретических атак на которые на практике даже внимания обращать не стоит. > > -- > Sergey Matveev (http://www.stargrave.org/) > OpenPGP: CF60 E89A 5923 1E76 E263 6422 AE1A 8109 E498 57EF > > -- With best regards Maksim Dmitrichenko
