Re: Debian 10, SSD, full disk encryption

2020-06-02 Пенетрантность Артём Н .

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


On 26.05.2020 17:37, Maksim Dmitrichenko wrote:
Мне всё-таки кажется, что ZFS на лэптопе с одним диском - это overkill. Ейный драйвер и оперативки хавает больше, и не понятно какие ещё плюсы у данного решения, кроме нативной поддержки шифрования. С этим 
сталкиваешься только один раз - когда сетапишься. А жить потом с этим всю ноутбучную жизнь ) Поэтому, имхо, не так существенно через какое место там шифрование сделано, если только на перформансе это не сказывается.


сб, 23 мая 2020 г. в 13:04, Sergey Matveev mailto: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




Re: Debian 10, SSD, full disk encryption

2020-06-02 Пенетрантность Артём Н .

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.



Re: Debian 10, SSD, full disk encryption

2020-06-02 Пенетрантность Артём Н .

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.






Re: Debian 10, SSD, full disk encryption

2020-05-26 Пенетрантность Sergey Matveev
*** 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



Re: Debian 10, SSD, full disk encryption

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

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

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

-- 
Ihor Antonov


signature.asc
Description: This is a digitally signed message part.


Re: Debian 10, SSD, full disk encryption

2020-05-26 Пенетрантность Sergey Matveev
*** 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



Re: Debian 10, SSD, full disk encryption

2020-05-26 Пенетрантность sergio


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

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

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

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

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


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


-- 
sergio.



Re: Debian 10, SSD, full disk encryption

2020-05-26 Пенетрантность Sergey Matveev
*** 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



Re: Debian 10, SSD, full disk encryption

2020-05-26 Пенетрантность Maksim Dmitrichenko
Мне всё-таки кажется, что ZFS на лэптопе с одним диском - это overkill.
Ейный драйвер и оперативки хавает больше, и не понятно какие ещё плюсы у
данного решения, кроме нативной поддержки шифрования. С этим сталкиваешься
только один раз - когда сетапишься. А жить потом с этим всю ноутбучную
жизнь ) Поэтому, имхо, не так существенно через какое место там шифрование
сделано, если только на перформансе это не сказывается.

сб, 23 мая 2020 г. в 13:04, Sergey Matveev :

> *** 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


Re: Debian 10, SSD, full disk encryption

2020-05-25 Пенетрантность sergio
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.



Re: Debian 10, SSD, full disk encryption

2020-05-23 Пенетрантность Alexander Gerasiov
On Sat, 23 May 2020 01:47:12 +0300
Maksim Dmitrichenko  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:00   477G  0 disk  
├─nvme0n1p1   259:10   256M  0 part  /boot/efi
└─nvme0n1p2   259:20 476,7G  0 part  
  └─crypt 253:00 476,7G  0 crypt 
├─vgname-root 253:1016G  0 lvm   [SWAP]


-- 
Best regards,
 Alexander Gerasiov

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



Re: Debian 10, SSD, full disk encryption

2020-05-23 Пенетрантность Sergey Matveev
*** 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



Re: Debian 10, SSD, full disk encryption

2020-05-23 Пенетрантность Михаил Касаджиков

День добрый.

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

Maksim Dmitrichenko  писал(а) в своём письме 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/

Re: Debian 10, SSD, full disk encryption

2020-05-22 Пенетрантность 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[1] 


Никаих плясок с lvm, dm-crypt, LUKS и прочим зоопарком. Ну а про то, что это в 
целом 
отличная ФС - не стоит и речи. TRIM имеется.
Использую сам длительное время, из недостатков только одно могу назвать - не 
нужно 
торопится перепрыгивать на новые ядра (я на Sid) - так как модуль Zfs бывает 
немного 
запаздывает по совместимости. На 10ке проблем быть недолжно.


-- 
Ihor Antonov


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


signature.asc
Description: This is a digitally signed message part.