Ubuntu включит RANDOM_TRUST_CPU в ядре и каков был бы эффект?
Согласно этому статья Register с 28.08.2018 и другие статьи, версия 4.19 ядра Linux будет иметь флаг компиляции названным RANDOM_TRUST_CPU. Вот также ссылка на запись списка рассылки автором патча, включая фактические изменения кода. Из того, что я понял, это позволит системам ускорять процесс начальной загрузки при некоторых обстоятельствах, не ожидая, пока достаточно энтропии не будет собрано из различных источников для безопасного отбора генератора случайных чисел, но пропуска что часть и полагающийся только на встроенный генератор случайных чисел ЦП.
Это ослабило бы криптографическую безопасность системы, поскольку она будет (если я пойму, это правильно) не только полагаются просто на ЦП как на единственный энтропийный источник, но также и может полностью подорвать безопасность если, что реализация ЦП не защищена (ошибки, намеренные бэкдоры...).
Генератор случайных чисел ядра был бы затем инициализирован только от генератора ЦП в течение всего времени, или он просто сделает это во время ранних этапов начальной загрузки и добавит больше энтропии из "традиционных" источников в пул позже, увеличивая криптографическую безопасность со временем снова назад к текущему/старому уровню?
Поскольку это, по-видимому - флаг времени компиляции, будете, пакеты ядра, обеспеченные в репозиториях Ubuntu, идут с этим флагом, включил или отключил?
Мог бы быть способ подписаться или уклонение кроме компиляции ядер самостоятельно с этого времени?
Существует ли способ на самом деле протестировать, если это имело бы значение во время начальной загрузки? Есть ли в настоящее время какие-либо метрики, доступные во время, проведенное, ожидая энтропии во время начальной загрузки?
И какие релизы Ubuntu даже доберутся для выполнения 4.19 или более поздние версии ядра?
1 ответ
Во-первых, обоснованно, криптографическая безопасность системы - ее непредсказуемость - не будет измененным всегда, независимо от ли встроенный HWRNG ЦП (например. RDRAND в Intel), используется или нет, иначе, как Вы отметили, это неизбежно ослабит безопасность RNG (и что-либо, что зависит от него).
Кратко, просто таким образом, во время процесса начальной загрузки, после того, как ядро загрузило драйвер случайности, RNG Linux инициализирует все случайные пулы (энтропийные пулы, которые являются просто областями памяти, которые содержат случайные данные), включая основной пул (входной пул), путем заполнения их с энтропией, которая прибывает из HWRNG, если это доступно, иначе через random_get_entropy(), который является макросом для get_cycles(), чья реализация меняется в зависимости от архитектуры (например, в aarch64 чтение CNTVCT_EL0 регистр сделан, который является своего рода частотомером, не на самом деле тактовой частотой, которая вместо этого используется в x86-64 путем чтения TSC reg). Все эти данные даны основному состоянию шифра (primary_crng, объект типа struct crng_state, который является реализацией алгоритма ChaCha20), который содержит ключ 384 действительно случайных битов, которые в конечном счете предоставляются /dev/urandom интерфейс.
Теперь с этим contextualization, для ответа на вопрос, фактическую инициализацию ядра RNG через rand_initialize(), быть early_initcall, происходит очевидно только во время начальной загрузки (как весь *_initcall()), особенно, в самом конце start_kernel(), стандартная программа ядра rest_init() назван, где, одна из первых вещей, которые он делает, должен породить поток ядра (kernel_init) с целью, среди прочего, для запуска этого initcall (отмечают также это add_device_randomness() назван даже прежде, но на самом деле не добавляет энтропических данных); и следовательно да, на источник, состояние шифра ChaCha20, основного устройства и блокирующихся пулов было бы инициализировано с arch_get_random_long(), который использует RDRAND инструкция в x86 процессорах (снова, если это доступно, и если это, ядро предупреждает Вас об этом). Я не сказал бы, что это - единственный источник, используемый хотя (даже если RDRAND доступно), потому что, по крайней мере:
Микропрограммное время используется и смешано в пулы во время инициализации (возможно, не, что энтропический, все еще взломщик должен был бы вывести метку времени с чрезвычайно высокой точностью);
Существует еще небольшой пул (один на ЦП, названный быстро объединяют), который собирает энтропию из
add_interrupt_randomness(), который использует IRQs (и теоретически другие события ядра и даже некоторое семя, прибывающее из аппаратных средств ЦП RNG, если существует), как введено, все смешались, и затем это введено во входной пул. Это происходит как каждая секунда.
Таким образом, процесс сбора энтропии и от HWRNG и от других источников происходит все вместе; конечно, первый доминирует над сценой (потому что энтропийное качество определенно выше, это - истинный RNG), и происходит во время начальной загрузки, и, от пространства пользователя, каждый раз, когда псевдослучайные устройства (или getrandom() syscall), используются. Во втором случае, хотя, пулы уже инициализируются, и просто primary_crng (состояние шифра), пересеян. И да, поскольку Вы отметили, ЦП, встроенный RNG, конечно, улучшает полную случайность.
Я наконец добавил бы, что, особенно во встроенных системах, которым может недоставать некоторого исходного шума (как клавиатуры, жесткие диски, и т.д.), использование HWRNG оказало бы значительное влияние. И просто обратите внимание, что, всегда на документацию, Вы могли отключить использование ядра RDRAND путь перед введением RANDOM_TRUST_CPU, если Вы обеспокоены безопасностью.