LINUX.ORG.RU

LVM volume group из двух LUKS томов

 , ,


0

1

Есть ноут с двумя дисками, планируется их зашифровать и было бы неплохо раскатать LVM поверх них, объединив LUKS тома в volume-group. Как бы это дело провернуть? Советуют /etc/crypttab, но используется ли он в Gentoo? Информации по этому поводу не нашел.

UPDATE. Сделал все по совету slamd64, отлично работает. Linear RAID из тех дисков, поверх него LUKS раздел. С LVM заморачиваться не стал.

P.S: Для тех, кто решит повторить — забейте на древний костыль под названием GRUB. Ядро давно можно грузить через EFI Stub, в целях безопасности initramfs можно вшить прямо в ядро, в довесок можно использовать SecureBoot, подписав ядро своим ключем.

★★

Как бы это дело провернуть?

используй вики арча. https://wiki.archlinux.org/index.php/Dm-crypt/System_configuration https://wiki.archlinux.org/index.php/Dm-crypt

Советуют /etc/crypttab, но используется ли он в Gentoo? Информации по этому поводу не нашел.

Это показалось мне абсурдным, но действительно, упоминания crypttab на вики gentoo нет! (Почти. Есть статья Sakaki's_EFI_Install_Guide но из названия не слишком понятно, следует ли её пользоваться в качестве официальной документации gentoo)

PtiCa ★★★★★ ()

Очевидно, сначала декриптуем блочные устройства, а затем собираем полученные виртуальные блочные устройства из /dev/mapper/... в единый LVM том.

Минусы этого дела фееричны: каждое блочное устройство будет криптоваться собственным ключом и будет деградация производительности (при том, что сам по себе LUKS - жестокая деградация производительности!) дисковой подсистемы.

Сделай «sudo cryptsetup benchmark» и посмотри. Вот LVM твой будет работать раза в 1.5-2 медленнее, чем бенч покажет.

IMHO, более правильное решение: объединить НЕКРИПТОВАННЫЕ винты в софтверный MD RAID, а уже поверх этого рейда сделать LUKS. Тогда данные будут криптоваться одним ключом один раз, а только потом отписываться на диски. У себя на хранилочке так и сделал. Реальные последовательные запись и чтение на такой криптованный рейд получились примерно на 1-2% меньше, чем бенч показывал (он только расчет показывает, без реальных записи-чтения).

slamd64 ★★★ ()
Последнее исправление: slamd64 (всего исправлений: 2)
Ответ на: комментарий от ving2

каким образом, где посмотреть, почитать?

При настройке ядра, в General есть соответствующая опция (Initramfs source file(s)). Нужен чистый cpio без сжатия. Необходимые параметры нужно прописать в built-in kernel command line.

Meyer ★★ ()
Последнее исправление: Meyer (всего исправлений: 1)
Ответ на: комментарий от slamd64

1.

каждое блочное устройство будет криптоваться собственным ключом и будет деградация производительности

2.

винты в софтверный MD RAID, а уже поверх этого рейда сделать LUKS. Тогда данные будут криптоваться одним ключом один раз, а только потом отписываться на диски

Не очень понятно, как выглядит то, о чем ты говоришь.

Вот есть HDD1 и HDD2. Откуда возьмутся преимущества п.2 перед п.1 ? (Я не вижу, где в п.1 будет шифрование данных больше одно раза, вот это мне не понятно)

PtiCa ★★★★★ ()
Ответ на: комментарий от PtiCa

Я не вижу, где в п.1 будет шифрование данных больше одно раза, вот это мне не понятно

Два LUKS раздела объединяются в LVM volume group. Каждый из них зашифрован со своим ключем.

Meyer ★★ ()
Ответ на: комментарий от PtiCa

Как работает LVM? LVM - не блочное устройство. Это именно хранилище.

Предположим в основе LVM два диска. Пишем два файла.

1-й файл запишется на 1-й диск 1-м ключем.

2-й файл запишется на 2-й диск 2-м ключом.

Поскольку диски независимые, файлы независимые, то писаться это всё будет параллельно. А, значит, вычислительные мощности процессора по шифрованию поделятся между двумя этими потоками. Да там ещё накладные расходы на две независимые файловые системы и прочее в том же духе.

При RAID-массиве LUKS-контейнер будет ОДИН: поверх самого массива. На аппаратный/софтверный RAID-контроллер уже приходит закриптованная информация и распределяется по дискам.

slamd64 ★★★ ()
Ответ на: комментарий от slamd64

Предположим в основе LVM два диска. Пишем два файла.

а, божечки боже, я до такого не додумался. Спасибо. Но я солидарен, надо применять mdadm для объединения блочных устройств.

PtiCa ★★★★★ ()