LINUX.ORG.RU

Перестала работать встроенная в ядро поддержка шифрования AES

 , ,


0

2

В самосборном ядре установлена поддержка шифрования AES

CONFIG_CRYPTO_AES=y
CONFIG_CRYPTO_AES_X86_64=y
Сначала всё работало нормально - приложения использовали встроенную в ядро поддержку. Но почему-то сломалось. Что можно посмотреть?

А как ты определил, что сломалось - и что раньше они именно ядро использовали, а не какую-нибудь библиотеку вроде libaes?

Если речь о truecrypt, может, там и «сломали»? может, это «не баг, а фича»?

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

А как ты определил, что сломалось

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

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

Уточню, что изменилось с системе. Нужно было дать доступ к машине другому пользователю. Причём, использует он установленную на другом жёстком диске win. Для его удобства сделал загрузку с win-диска по умолчанию. В /etc/fstab разделы прописаны через UUID, проблем с загрузкой и использованием всех разделов нет.

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

Может в конфиге эти опции включены, а на уровне загрузки где-то выключены? в загрузчике или в sysctl? Если такое вообще возможно.

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

Может в конфиге эти опции включены, а на уровне загрузки где-то выключены?

Нет, это невозможно. Потому, что всё работало до того, как в BIOS загрузочным устройством по умолчанию не был установлен другой жёсткий диск.

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

Там много чего есть... Но то, что меня интересует - тоже есть:

name         : aes
driver       : aes-asm
module       : kernel
priority     : 200
refcnt       : 1
selftest     : passed
internal     : no
type         : cipher
blocksize    : 16
min keysize  : 16
max keysize  : 32

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

Трукриптом не пользовался, у него свой ядерный модуль или работает через device-mapper?

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

у него свой ядерный модуль

Нет, truecrypt либо использует вкомпиленную в ядро функцию, либо внутренний программный алгоритм шифрования/дешифрования.

adamantan ()

Сначала всё работало нормально - приложения использовали встроенную в ядро поддержку

что за приложения? какие? (кроме truecrypt разумеется.. его не в счёт)

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

что за приложения? какие?

Да, допустил неточность. Только truecrypt. Хотя, полагаю, предположение, что и другие бы не работали - весьма вероятно. Что можно попробовать для сравнения?

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

Ну вот чтобы использовать вкомпиленную в ядро функцию, надо иметь свой ядерный модуль или использовать device mapper. Посмотри в /dev/mapper, есть что-то связанное?

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

В /dev/mapper пусто, за исключением файла символьного устройства control Cам truecrypt пишет при установке, что использует mapper

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

Ну тогда если твое ядро версии 3.10.97, 3.14.61, 3.18.27 или 4.1.18, то откатись/обновись на версию постарше/поновее.

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

3.10.97, 3.14.61, 3.18.27 или 4.1.18

Пересобрал дефолтное ядро 4.1.16 - проблем нет!

adamantan ()

А нахрена тебе ядерное шифрование в приложениях?

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

Потому что оно... Быстрее? Есть юзерспейсное апи для доступа к ядерному шифрованию. Ну там, меньше переключений контекста наверное.

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

Захотел, например, прочитать файл, доступ к которому через юзерспейсный демон:
1) дернул open();
2) open() дернул ядро;
3) ядро дернуло юзерспейсный демон;
4) демон дернул ядро для чтения данных с блочного устройства;
5) ядро вернуло данные демону;
6) демон декодировал (расшифровал) полученные данные (опционально);
7) GOTO 4, пока не будет прочитана вся требуемая инфа, т.е. разная метадата и содержимое нужного файла;
8) демон вернул данные ядру для open();
9) open() возвращает данные.

Это как я представляю себе этот процесс, в целом должно быть верно.

С ядерным же шифрованием переключений контекста заметно меньше - пункты с 3 по 8 убираются.

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