Debian 10, SSD, full disk encryption

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Debian 10, SSD, full disk encryption

Maksim Dmitrichenko
Привет всем!

На работе подогнали новый лэптоп с SSD. Требованием работодателя является работа на полностью шифрованном разделе. Собираюсь ставить на него десятый Дебиан. Вопросы:
1) Имеет ли смысл на разделе создавать LVM или сразу сделать dm-crypt поверх обычного раздела sdaX?
2) А что собственно с TRIM? Почитал какой-то flame war, что дескать TRIM уменьшает безопасность шифрования. Что, прям так сильно бьет? А вообще это реально, чтобы SSD жил долго и счастливо без TRIM?
3) Алсо, почитал, что TRIM может выполнять автомагически драйвер FS. А может запускаться по расписанию.

Что посоветуют многоуважаемые доны?

--
With best regards
  Maksim Dmitrichenko
Reply | Threaded
Open this post in threaded view
|

Re: Debian 10, SSD, full disk encryption

Ihor Antonov

On Friday, 22 May 2020 15:47:12 PDT Maksim Dmitrichenko wrote:

> Привет всем!

>

> На работе подогнали новый лэптоп с SSD. Требованием работодателя является

> работа на полностью шифрованном разделе. Собираюсь ставить на него десятый

> Дебиан. Вопросы:

> 1) Имеет ли смысл на разделе создавать LVM или сразу сделать dm-crypt

> поверх обычного раздела sdaX?

> 2) А что собственно с TRIM? Почитал какой-то flame war, что дескать TRIM

> уменьшает безопасность шифрования. Что, прям так сильно бьет? А вообще это

> реально, чтобы SSD жил долго и счастливо без TRIM?

> 3) Алсо, почитал, что TRIM может выполнять автомагически драйвер FS. А

> может запускаться по расписанию.

>

> Что посоветуют многоуважаемые доны?

>

> --

> With best regards

> Maksim Dmitrichenko

 

Здравствия и Вам.

 

Настоятельно рекомендую ZFS on Root with native encryption

https://openzfs.github.io/openzfs-docs/Getting%20Started/Debian/index.html

 

 

Никаих плясок с lvm, dm-crypt, LUKS и прочим зоопарком. Ну а про то, что это в целом отличная ФС - не стоит и речи. TRIM имеется.

Использую сам длительное время, из недостатков только одно могу назвать - не нужно торопится перепрыгивать на новые ядра (я на Sid) - так как модуль Zfs бывает немного запаздывает по совместимости. На 10ке проблем быть недолжно.

 

 

--

Ihor Antonov


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Debian 10, SSD, full disk encryption

Михаил Касаджиков
In reply to this post by Maksim Dmitrichenko
День добрый.

Уже 10 лет использую в ноуте полнодисковое шифрование. Сам диск разбит на два раздела: загрузочный и всё остальное. На шифрованном разделе использую LVM. TRIM поддерживается на всех уровнях, но в LVM его в то время нужно было специально включать в конфиге. Параметр монтирования «discard» не использую, вместо него ночью по выходным запускается fstrim. Работает вся связка прекрасно, есть не просит.

Maksim Dmitrichenko <[hidden email]> писал(а) в своём письме Sat, 23 May 2020 01:47:12 +0300:

Привет всем!

На работе подогнали новый лэптоп с SSD. Требованием работодателя является работа на полностью шифрованном разделе. Собираюсь ставить на него десятый Дебиан. Вопросы:
1) Имеет ли смысл на разделе создавать LVM или сразу сделать dm-crypt поверх обычного раздела sdaX?
2) А что собственно с TRIM? Почитал какой-то flame war, что дескать TRIM уменьшает безопасность шифрования. Что, прям так сильно бьет? А вообще это реально, чтобы SSD жил долго и счастливо без TRIM?
3) Алсо, почитал, что TRIM может выполнять автомагически драйвер FS. А может запускаться по расписанию.

Что посоветуют многоуважаемые доны?

--
With best regards
  Maksim Dmitrichenko



--
Написано с помощью почтового клиента Opera: http://www.opera.com/mail/
Reply | Threaded
Open this post in threaded view
|

Re: Debian 10, SSD, full disk encryption

Sergey Matveev-2
In reply to this post by Maksim Dmitrichenko
*** 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

Reply | Threaded
Open this post in threaded view
|

Re: Debian 10, SSD, full disk encryption

Alexander Gerasiov-3
In reply to this post by Maksim Dmitrichenko
On Sat, 23 May 2020 01:47:12 +0300
Maksim Dmitrichenko <[hidden email]> wrote:

> Привет всем!
>
> На работе подогнали новый лэптоп с SSD. Требованием работодателя
> является работа на полностью шифрованном разделе. Собираюсь ставить
> на него десятый Дебиан. Вопросы:
> 1) Имеет ли смысл на разделе создавать LVM или сразу сделать dm-crypt
> поверх обычного раздела sdaX?
> 2) А что собственно с TRIM? Почитал какой-то flame war, что дескать
> TRIM уменьшает безопасность шифрования. Что, прям так сильно бьет? А
> вообще это реально, чтобы SSD жил долго и счастливо без TRIM?
> 3) Алсо, почитал, что TRIM может выполнять автомагически драйвер FS. А
> может запускаться по расписанию.
>
> Что посоветуют многоуважаемые доны?
>

Я еще заморочился с secure boot, чтобы потенциально нельзя было
заинжектить в initramfs или загрузчик malware, который сохранит
вводимый пароль.
Использую вот такую конфигурацию, загрузчик bootd, который грузит
подписанное ядро с инитрамсф прям из efi раздела.
Для автоматизации использую sicherboot.

nvme0n1           259:0    0   477G  0 disk  
├─nvme0n1p1       259:1    0   256M  0 part  /boot/efi
└─nvme0n1p2       259:2    0 476,7G  0 part  
  └─crypt         253:0    0 476,7G  0 crypt
    ├─vgname-root 253:1    0    16G  0 lvm   [SWAP]


--
Best regards,
 Alexander Gerasiov

 Contacts:
 e-mail: [hidden email]  WWW: https://gerasiov.net  TG/Skype: gerasiov
 PGP fingerprint: 04B5 9D90 DF7C C2AB CD49  BAEA CA87 E9E8 2AAC 33F1

Reply | Threaded
Open this post in threaded view
|

Re: Debian 10, SSD, full disk encryption

sergio-3
In reply to this post by Maksim Dmitrichenko
On 23/05/2020 01:47, Maksim Dmitrichenko wrote:


> SSD жил долго ... без TRIM

А это как-то связано?

Я рекомендую поиграть с fio и SSD. Скажем взять и последовательно влить
объёмов 10. Потом повторить эксперимент но не всём объёме а на разделе
чуть меньшего размера. А потом ещё чуть меньшего.

У меня SSD, c ext4 на LUKS, без LVM, без TRIM или discard, БЕЗ каких
бы-то ни было проблем в течении уже больше 5 лет. (Кстати ssd надо брать
ТОЛЬКО с гарантией от 5 лет, ну как и HDD.)


--
sergio.

Reply | Threaded
Open this post in threaded view
|

Re: Debian 10, SSD, full disk encryption

Maksim Dmitrichenko
In reply to this post by Sergey Matveev-2
Мне всё-таки кажется, что ZFS на лэптопе с одним диском - это overkill. Ейный драйвер и оперативки хавает больше, и не понятно какие ещё плюсы у данного решения, кроме нативной поддержки шифрования. С этим сталкиваешься только один раз - когда сетапишься. А жить потом с этим всю ноутбучную жизнь ) Поэтому, имхо, не так существенно через какое место там шифрование сделано, если только на перформансе это не сказывается.

сб, 23 мая 2020 г. в 13:04, Sergey Matveev <[hidden email]>:
*** 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
Reply | Threaded
Open this post in threaded view
|

Re: Debian 10, SSD, full disk encryption

Sergey Matveev-2
*** Maksim Dmitrichenko [2020-05-26 17:37]:
>Мне всё-таки кажется, что ZFS на лэптопе с одним диском - это overkill.

А я уверен что нет. Живу с ZFS-ом уже много лет на ноутбуке (сначала 4GB
RAM, теперь 8GB) и не соглашусь по другому.
http://www.stargrave.org/ZFS-proscons.html

>Ейный драйвер и оперативки хавает больше

Для кэширования, всё верно, ибо оно эффективно. Когда надо, то память
оно освобождает (ну как минимум в FreeBSD).

--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Reply | Threaded
Open this post in threaded view
|

Re: Debian 10, SSD, full disk encryption

sergio-3
In reply to this post by sergio-3

>>> SSD жил долго ... без TRIM

>> А это как-то связано?

> Я так понимаю, что когда контроллеру диска говорят TRIM на тот или
> иной блок, то он имеет возможность его перемапить на менее поюзанный,
> или наоборот заменить им другой блок, который уже хорошенько поюзан.

Нет, ТRIМ говорят исключительно для облегчения работы GC, а на Wear
leveling влиять возможности нет.

https://ru.wikipedia.org/wiki/Trim_(команда_для_накопителей)


А что бы SSD жил долго у меня /tmp, /var/cache/apt и пользовательский
кэш в tmpfs.


--
sergio.

Reply | Threaded
Open this post in threaded view
|

Re: Debian 10, SSD, full disk encryption

Sergey Matveev-2
*** sergio [2020-05-26 17:51]:
>Нет, ТRIМ говорят исключительно для облегчения работы GC, а на Wear
>leveling влиять возможности нет.

Тут я не силён, но считал что: на wear leveling оно не влияет -- это
безусловно, однако знания о неиспользуемых страницах SSD (те, которые ОС
пометила TRIM-ом как "свободное место") может быть использовано
контроллером SSD для их переиспользования вместо уже изношенных страниц.
SSD, опять же, насколько слышал, имеют какой-то запас резервных блоков,
которые заменят изношенные. Когда их запас подойдёт к концу, то при
попытке записи в изношенных (а других же и нет) -- будет выдаваться
ошибка. В случае же, когда резервные иссякли, но ещё есть штатно
доступные свободные -- они прозрачно могут быть использованы. Свободное
место на диске (помеченное TRIM-ом) как-бы приравнивается к доступным
резервным блокам, что существенно может продлить работу с накопителем,
если он не забивается битком. Именно поэтому и есть же рекомендация о
том, что можно оставлять неиспользуемым место на SSD для резерва (хоть
партицию выделить для резервивания места и не трогать её вообще).

--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Reply | Threaded
Open this post in threaded view
|

Re: Debian 10, SSD, full disk encryption

Ihor Antonov
In reply to this post by Maksim Dmitrichenko
On Tuesday, 26 May 2020 07:37:00 PDT Maksim Dmitrichenko wrote:
> Мне всё-таки кажется, что ZFS на лэптопе с одним диском - это overkill.
> Ейный драйвер и оперативки хавает больше, и не понятно какие ещё плюсы у
> данного решения, кроме нативной поддержки шифрования. С этим сталкиваешься
> только один раз - когда сетапишься. А жить потом с этим всю ноутбучную
> жизнь ) Поэтому, имхо, не так существенно через какое место там шифрование
> сделано, если только на перформансе это не сказывается.

Я скажу что совсем наоборот. Помимо шифрования еще есть мнгновенные снапшоты.
Единожды попробовав все остальное (включая btrfs) кажется детскими поделками.
Снапшоты не раз спасали меня от поломаных обновлений, и бекапить данные
на другую машину одно удовольствие - zfs send | ssh

Оперативку жрет только на бумаге, свободная память часто занята кешом, но кеш
вытесняется очень быстро когда есть необходимость. Иными словами ситуаций
с недостатком оперативки небыло. В догонку - у меня есть пара серверов с
1 Гб оперативки, на них ZFS, все работает хорошо уже больше двух лет.

--
Ihor Antonov

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Debian 10, SSD, full disk encryption

Sergey Matveev-2
*** Ihor Antonov [2020-05-26 11:54]:
>В догонку - у меня есть пара серверов с
>1 Гб оперативки, на них ZFS, все работает хорошо уже больше двух лет.

Подтверждаю! И у меня тоже есть машины с 1GB RAM с ZFS-ом везде
(хранилища и root), которым по 3-4 года -- работают без нареканий и
проблем.

--
Sergey Matveev (http://www.stargrave.org/)
OpenPGP: CF60 E89A 5923 1E76 E263  6422 AE1A 8109 E498 57EF

Reply | Threaded
Open this post in threaded view
|

Re: Debian 10, SSD, full disk encryption

artiom
In reply to this post by Maksim Dmitrichenko
On 23.05.2020 01:47, Maksim Dmitrichenko wrote:

> Привет всем!
>
> На работе подогнали новый лэптоп с SSD. Требованием работодателя является работа на полностью шифрованном разделе. Собираюсь ставить на него десятый Дебиан. Вопросы:
> 1) Имеет ли смысл на разделе создавать LVM или сразу сделать dm-crypt поверх обычного раздела sdaX?
> 2) А что собственно с TRIM? Почитал какой-то flame war, что дескать TRIM уменьшает безопасность шифрования. Что, прям так сильно бьет? А вообще это реально, чтобы SSD жил долго и счастливо без TRIM?
> 3) Алсо, почитал, что TRIM может выполнять автомагически драйвер FS. А может запускаться по расписанию.
>
> Что посоветуют многоуважаемые доны?
>
> --
> With best regards
>    Maksim Dmitrichenko


1. Сразу шифрование: так проще эксплуатация и безопаснее. Но лучше /boot выделить отдельным разделом без LVM.
   Ибо меня раздражает, как grub из EFI спрашивает и переспрашивает для раздела пароль.
2. Бьёт кто? Нарушитель - Агентство или Вася, попёрший ноут?
   Раз у вас есть такой вопрос: не имеет значения TRIM, - смело включайте.
3. Не столь важно, когда будет делаться TRIM, пока есть место, но "долго и счастливо" SSD без него жить не будет,
   а конкретика зависит от технологии SSD.

Reply | Threaded
Open this post in threaded view
|

Re: Debian 10, SSD, full disk encryption

artiom
In reply to this post by Maksim Dmitrichenko
С 2018 использую ZFS в NAS/сервере.
Корень, на ZFS, систему разворачивал вручную.
Почти всё делаю вручную через консоль.
Её команд не помню, мне приходится лезть в справочник.
Потому что, это решение типа "поставил и забыл" - за время использования пока особых претензий нет и проблем тоже.


On 26.05.2020 17:37, Maksim Dmitrichenko wrote:

> Мне всё-таки кажется, что ZFS на лэптопе с одним диском - это overkill. Ейный драйвер и оперативки хавает больше, и не понятно какие ещё плюсы у данного решения, кроме нативной поддержки шифрования. С этим
> сталкиваешься только один раз - когда сетапишься. А жить потом с этим всю ноутбучную жизнь ) Поэтому, имхо, не так существенно через какое место там шифрование сделано, если только на перформансе это не сказывается.
>
> сб, 23 мая 2020 г. в 13:04, Sergey Matveev <[hidden email] <mailto:[hidden email]>>:
>
>     *** 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

Reply | Threaded
Open this post in threaded view
|

Re: Debian 10, SSD, full disk encryption

artiom
In reply to this post by sergio-3
On 26.05.2020 17:51, sergio wrote:

>
>>>> SSD жил долго ... без TRIM
>
>>> А это как-то связано?
>
>> Я так понимаю, что когда контроллеру диска говорят TRIM на тот или
>> иной блок, то он имеет возможность его перемапить на менее поюзанный,
>> или наоборот заменить им другой блок, который уже хорошенько поюзан.
>
> Нет, ТRIМ говорят исключительно для облегчения работы GC, а на Wear
> leveling влиять возможности нет.
>
> https://ru.wikipedia.org/wiki/Trim_(команда_для_накопителей)
>

Любопытно, я почему-то думал, что влияет...


>
> А что бы SSD жил долго у меня /tmp, /var/cache/apt и пользовательский
> кэш в tmpfs.
>
>