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

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

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

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

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

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

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

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

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

Что в /proc/crypto?

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

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

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

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

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

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

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

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

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

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

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

https://bugzilla.kernel.org/show_bug.cgi?id=112631 - не это?

Вполне возможно, что у этих проблем общая причина.

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

3.10.97, 3.14.61, 3.18.27 или 4.1.18

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

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

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

А бенчмарки есть?

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

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

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