LINUX.ORG.RU

SED OPAL S3 (сон)

 , ,


0

1

Добрый день. Прошу помощи, уже окончательно запутался. Есть комп с NVME SSD, поддерживающим TCG OPAL 2.0. Включил шифрование, в целом все работает предсказуемо, в том числе диск становится недоступен после пробуждения компьютера из S3 (режим сна). Нашел на эту тему ветку https://github.com/Drive-Trust-Alliance/sedutil/issues/90, где как раз идет обсуждение этой проблемы. Судя по комментариям, некоторым участникам обсуждения удалось решить проблему при помощи заплаток, которые они опубликовали там же. Но я новичок на github и не смог разобраться, в какой последовательности что нужно скачивать. Попробовал выполнить по вот этому комментарию: https://github.com/Drive-Trust-Alliance/sedutil/issues/90#issuecomment-386932471, но на этапе make получаю ошибки:

/usr/bin/ld: build/Release_x86_64/GNU-Linux/_ext/5c0/DtaDevOS.o: in function `DtaDevOS::prepareForS3Sleep(unsigned char, char*)':
DtaDevOS.cpp:(.text+0xf33): undefined reference to `DtaDevLinuxDrive::prepareForS3Sleep(unsigned char, std::vector<unsigned char, std::allocator<unsigned char> > const&)'
collect2: ошибка: выполнение ld завершилось с кодом возврата 1
make[2]: *** [nbproject/Makefile-Release_x86_64.mk:84: dist/Release_x86_64/GNU-Linux/sedutil-cli] Ошибка 1
make[2]: выход из каталога «/tmp/sedutil/linux/CLI»
make[1]: *** [nbproject/Makefile-Release_x86_64.mk:80: .build-conf] Ошибка 2
make[1]: выход из каталога «/tmp/sedutil/linux/CLI»
make: *** [nbproject/Makefile-impl.mk:40: .build-impl] Ошибка 2

Подозреваю, что гитом забрал не все\не то или что какие-то заплатки уже были применены в ветке (если я правильно понимаю логику работы). Прошу помощи по сборке САБЖа, который описан на гите..
# uname -a
Linux 4.19.5-300.fc29.x86_64 #1 SMP Tue Nov 27 19:29:23 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
# cat /boot/config-4.19.5-300.fc29.x86_64 | grep "CONFIG_BLK_SED_OPAL"
CONFIG_BLK_SED_OPAL=y
Fedora 29



Последнее исправление: Shadow2091 (всего исправлений: 1)

Hi, since Kubuntu 18.04 finally has a default kernel that should have this change (4.15)

так-то почти 4.20 на дворе. проверь, может уже has. если да, то просто поставь с mainline ppa

mos ★★☆☆☆
()

Воспользуюсь тем, что это русский форум, и скажу. Ты всё делаешь неправильно!

Во-первых, встроенные средства шифрования в дисках всегда были говном; что в HDD, что, теперь, в SSD (https://latesthackingnews.com/2018/11/08/vulnerabilities-in-major-self-encryp...)

Во-вторых, юзай для шифрования дисков LUKS - штатная фича Linux. Что бы это сделать, просто во время установки любого современного дистрибутива выбери Атоматическую разметку диска и отметь пункт «Шифровать диск» (Понятное дело, что в общем случае он почистит все твои диски, вставленные в этот момент в комп, учти это). Все без проблем будет работать, просто запомни этот пароль хорошо.

В-третьих, еще раз - не используй встроенное шифрование на дисках. А также: встроенные в материнские платы рейды и всякие intel speed storage. Это все оттестировано и работает только под виндой. Linux имеет собственные средства для этого.

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

Даже не сомневался, что большая часть комментариев будет не по существу, а «ты все делаешь не так» - это же ЛОР! LUKS у меня используется сейчас, причем я реализовал даже шифрованный /boot, но производительность на моем CPU совсем низкая:

PBKDF2-sha1      1042322 iterations per second for 256-bit key
PBKDF2-sha256    1274089 iterations per second for 256-bit key
PBKDF2-sha512     910222 iterations per second for 256-bit key
PBKDF2-ripemd160  515017 iterations per second for 256-bit key
PBKDF2-whirlpool  395987 iterations per second for 256-bit key
argon2i       4 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id      5 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b       694,8 MiB/s      2228,8 MiB/s
    serpent-cbc        128b        45,5 MiB/s       430,1 MiB/s
    twofish-cbc        128b       106,9 MiB/s       214,2 MiB/s
        aes-cbc        256b       477,4 MiB/s      1576,2 MiB/s
    serpent-cbc        256b        47,4 MiB/s       405,8 MiB/s
    twofish-cbc        256b       100,7 MiB/s       176,4 MiB/s
        aes-xts        256b      1194,6 MiB/s       557,6 MiB/s
    serpent-xts        256b       209,9 MiB/s       226,3 MiB/s
    twofish-xts        256b       150,8 MiB/s       212,6 MiB/s
        aes-xts        512b      1168,3 MiB/s      1154,9 MiB/s
    serpent-xts        512b       426,0 MiB/s       415,4 MiB/s

Галка «Шифровать диск» - как правило не имеет отношение к LUKS, а включает cryptfs. SSD - 970PRO, конкретно он не упоминается в уязвимостях.

Shadow2091
() автор топика
Ответ на: комментарий от Shadow2091

Это был самый полезный совет, на самом деле: ищите помощь на англоязычных сайтах. Здесь нравоучениями замучают.)

С Птицей не согласен: в нормальных SSD шифрование раализовано хорошо. C OPAL игрался, но до описанной проблемы не дошел. На рабочих компах пользуюсь ATA шифрованием, ибо Intel DCS Series не поддерживает OPAL (что, кстати, намекает).

anonymous
()
Ответ на: комментарий от Deleted

не используй встроенное шифрование на дисках.

Это представляет некоторую сложность на дисках с поддержкой TCG OPAL 2.0, просто потому что там оно неотключаемо и работает всегда.

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

Слушай, а в чем проблема-то заключается? Ты так написал, что не очень понятно. Хочу проверить - у меня есть или нет.

Я пока понял что после саспенда у тебя диск не расшифрованный оказывается, а ты ожидаешь что он будет расшифрован - так?

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

Шифрование неотключаемо на всех дисках. ATA encryption тоже работает всегда.=)

Возможно - не пользовался и не интересовался, но в целом это разумно и удобно. Я бы удивился если бы встроенное средство работало как-то иначе.

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

Да, так. Народ написал маленькую тулзу, которая после саспенда расшифровывает диск хэшем ключа, который вписывается в конфиг. Вот мне и нужно собрать эту тулзу, но не выходит.

Shadow2091
() автор топика
Ответ на: комментарий от Suntechnic

Ну во первых - не ключ, а хэш. Во вторых - конфиг то лежит на зашифрованном диске и в оперативной памяти. После выключения питания ключ вводится вручную.

Shadow2091
() автор топика
Ответ на: комментарий от Shadow2091

Хочется осторожно поинтересоваться, как вы предлагаете читать хэш для расшифровки диска с зашифрованного раздела.

anonymous
()

И вы действительно думаете что ОНИ дадут вам аппаратное шифрование без бекдорчиков? Наивные ;)

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

Согласно сообщениям, он читается один раз при запуске ОС, после чего находится в оперативной памяти. Архитектурно решение повторяет логику работы LUKS.

Shadow2091
() автор топика
Ответ на: комментарий от Shadow2091

На «современных» (i5-2400, семилетней давности):

$ sudo cryptsetup benchmark --cipher aes-xts
# Tests are approximate using memory only (no storage IO).
#  Algorithm | Key |  Encryption |  Decryption
     aes-xts   256b  1120.2 MiB/s  1204.4 MiB/s

На современных (i7-9700K, актуальный):

$ /sbin/cryptsetup benchmark --cipher aes-xts
# Tests are approximate using memory only (no storage IO).
#     Algorithm |       Key |      Encryption |      Decryption
        aes-xts        256b      2331.8 MiB/s      2308.1 MiB/s
t184256 ★★★★★
()
Ответ на: комментарий от t184256

Если переключить в режим производительности:

PBKDF2-sha1      1440351 iterations per second for 256-bit key
PBKDF2-sha256    1879168 iterations per second for 256-bit key
PBKDF2-sha512    1342606 iterations per second for 256-bit key
PBKDF2-ripemd160  760940 iterations per second for 256-bit key
PBKDF2-whirlpool  577409 iterations per second for 256-bit key
argon2i       8 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
argon2id      8 iterations, 1048576 memory, 4 parallel threads (CPUs) for 256-bit key (requested 2000 ms time)
#     Algorithm |       Key |      Encryption |      Decryption
        aes-cbc        128b      1039,0 MiB/s      3139,9 MiB/s
    serpent-cbc        128b        84,1 MiB/s       657,5 MiB/s
    twofish-cbc        128b       184,5 MiB/s       351,4 MiB/s
        aes-cbc        256b       785,0 MiB/s      2542,4 MiB/s
    serpent-cbc        256b        87,1 MiB/s       657,0 MiB/s
    twofish-cbc        256b       190,3 MiB/s       351,2 MiB/s
        aes-xts        256b      1972,0 MiB/s      1952,1 MiB/s
    serpent-xts        256b       632,1 MiB/s       625,5 MiB/s
    twofish-xts        256b       346,1 MiB/s       346,7 MiB/s
        aes-xts        512b      1764,2 MiB/s      1747,6 MiB/s
    serpent-xts        512b       635,6 MiB/s       624,3 MiB/s
    twofish-xts        512b       345,7 MiB/s       346,2 MiB/s


Intel(R) Core(TM) i5-8250U CPU

Shadow2091
() автор топика
Ответ на: комментарий от anonymous

С Птицей не согласен: в нормальных SSD шифрование раализовано хорошо.

Не может оно работать хорошо, если это проприетарщина. Скорее всего, у производителя есть мастер-ключ. Или другие способы облегчить взлом.

te111011010
()

Сам спросил, сам ответил...

Как обычно на ЛОРе, сам же отвечаю...

git clone https://github.com/badicsalex/sedutil.git
cd sedutil
git checkout s3-sleep-support
cd linux/CLI
wget https://github.com/Drive-Trust-Alliance/sedutil/files/2527269/patch.txt
patch nbproject/Makefile-Release_x84_64.mk < patch.txt
make CONF="Release_x86_64"
cp dist/Release_x84_64/GNU-Linux/sedutil-cli $(which sedutil-cli)
sedutil-cli --printPasswordHash <PASSWORD> </dev/nvme0n1>

На выходе последней команды получаем хэш пароля, используемого для разблокировки диска. Чтобы обеспечить нормальную работоспособность после пробуждения, необходимо один раз при загрузке сказать sedutil-cli -n -x --prepareForS3Sleep 0 HASH /dev/nvme0n1 , где «HASH» заменить на требуемый.

Чтобы не вводить команду вручную каждый раз, отдаем это systemd

cat << EOF > /etc/systemd/system/opalReadyS3.service
[Service]
Type=oneshot
ExecStart=sedutil-cli -n -x --prepareForS3Sleep 0 HASH /dev/nvme0n1

[Install]
WantedBy=multi-user.target

EOF
и не забываем включить автозагрузку systemctl daemon-reload&&systemctl enable --now opalReadyS3

Магия работает только на ядрах новее 4.11 с включенным параметром CONFIG_BLK_SED_OPAL. После выполнения вышеуказанных действий система успешно дешифрует диск при пробуждении.

Хэш (а не пароль) хранится на зашифрованном диске, так что в целом - достаточно секьюрно.

Shadow2091
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.