Назад | Перейти на главную страницу

Ошибка LUKS во время загрузки

alg: drbg: could not allocate DRNG handle for ...

Я вижу эту ошибку на консоли только во время процесса загрузки виртуальных машин, которые мы создаем. РЕДАКТИРОВАТЬ: 2/5/16 - Я тоже вижу это на некоторых установках без покрытия. (Он действительно загружается полностью.) Я предполагаю, что это как-то связано с виртуализированным оборудованием и отсутствием (совместимого) генератора случайных чисел. Проблема в том, что я не могу оценить серьезность. Нарушена ли надежность шифрования? (Должен ли я вообще беспокоиться об этой ошибке?) Как я могу это исправить?

Мы используем QEMU / KVM под CentOS 6.7. Я могу сделать virsh dumpxml примера системы, если вы действительно думаете, что это поможет. Мы используем Размер шифра / ключа по умолчанию Anaconda. (aes-xts-plain64 / 512)

Это самая ранняя ссылка Я нашел на список рассылки linux-crypto. К сожалению, это немного выше моей головы.

http://www.mail-archive.com/linux-crypto%40vger.kernel.org/msg10398.html

По сути, я не верю, что это влияет на надежность вашего шифрования.

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

Этот код принадлежит модулю stdrng. По крайней мере, в Fedora 23 он встроен в ядро, а не экспортируется как модуль ядра.

Когда stdrng инициализируется впервые, происходят следующие вызовы.

В crypto / drbg.c инициализация начинается здесь.

1997 module_init(drbg_init);

Это регистрирует все известные системе drbgs.

1985         for (j = 0; ARRAY_SIZE(drbg_cores) > j; j++, i++)
1986                 drbg_fill_array(&drbg_algs[i], &drbg_cores[j], 1);
1987         for (j = 0; ARRAY_SIZE(drbg_cores) > j; j++, i++)
1988                 drbg_fill_array(&drbg_algs[i], &drbg_cores[j], 0);

Затем он передает его вспомогательной функции, которая выполняет инициализацию:

1989         return crypto_register_rngs(drbg_algs, (ARRAY_SIZE(drbg_cores) * 2));

В crypto/rng.c это просто перебирает каждый rng, чтобы зарегистрировать его ..

210         for (i = 0; i < count; i++) {
211                 ret = crypto_register_rng(algs + i);
212                 if (ret)
213                         goto err;
214         }

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

196         return crypto_register_alg(base);

Что не так очевидно, так это то, что происходит во время регистрации.

Другой модуль называется tcrypt также встроенный в ядро ​​получает уведомления о добавлении новых алгоритмов. Как только он видит новый зарегистрированный алгоритм, он планирует его проверку. Это то, что вы видите на экране.

По окончании теста алгоритм переходит в состояние ТЕСТИРОВАНИЕ. Если тест не удался, я представить (Я не смог найти бит, который вызывает такое поведение), его нельзя выбрать для поиска, если вы передадите правильные флаги.

Пройдет ли тест или нет, определенно хранится внутри.

В дополнение к этому, вызов генератора случайных чисел псевдо-случайных чисел приводит к повторению списка алгоритмов, состоящих из prngs в порядке силы, как указано в этом примечании в crypto/drbg.c

107 /*
108  * The order of the DRBG definitions here matter: every DRBG is registered
109  * as stdrng. Each DRBG receives an increasing cra_priority values the later
110  * they are defined in this array (see drbg_fill_array).
111  *

Поскольку самый сильный из них не терпит неудачу (hmac sha256), маловероятно, что вы используете отказавшие, даже если их можно было бы выбрать.

Подвести итоги -

  • Это происходит, когда stdrng для чего-то требуется модуль.
  • Он загружает все известные ему алгоритмы.
  • Все загруженные алгоритмы проходят тестирование. Некоторые могут потерпеть неудачу (почему не рассматривается в этом ответе).
  • Неудачные алгоритмы тестирования не должен будет доступен для выбора позже.
  • PRNGS упорядочиваются по силе, и сильные PRNG, которые действительно проходят, проверяются первыми.
  • Вещи, на которые полагаются stdrng надеюсь, не следует использовать эти алгоритмы в качестве основы для их источника ГПСЧ.

Вы можете увидеть, какие алгоритмы были успешными и прошли тесты, используя следующую команду:

 grep -EC5 'selftest.*passed' /proc/crypto

Вы также можете увидеть приоритет выбора в поле «приоритет». По мнению автора модуля, чем выше значение, тем сильнее PRNG.

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

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

Таким образом, я считаю, что это не дополнительный риск для вас при использовании luks.

Как я могу это исправить?

Согласно базе знаний Red Hat, вы должны добавить модуль ядра 'ctr' в свой initrd. В их инструкциях также говорится, что нужно включить «ecb», хотя, похоже, проблема в том, что модуль «ctr» не загружается.

dracut -f -v --add-drivers "ctr ecb"

Подписчики могут видеть полную информацию. Я не уверен, что мне разрешено переиздать здесь остальное, поэтому я перефразировал полное решение.

https://access.redhat.com/solutions/2249181

Изменить 29/9/2016:

Вы также можете добавить эти драйверы в /etc/dracut.conf так что они добавляются в новые initramfs при обновлении ядра. В противном случае ваши симптомы загадочным образом снова появятся через много месяцев. ;)

add_drivers+="ctr ecb"