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
для чего-то требуется модуль.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"