Вони пропонують модернізувати процес завантаження Linux

Нове завантаження Linux працюватиме й у майбутньому з акцентом на надійність і простоту.

Леннарт Поетинг (творець Systemd) дав про це знати нещодавно пропозиція щодо модернізації процесу завантаження розподілів Linux, з метою вирішення існуючих проблем і спростити організацію повного перевіреного завантаження, підтверджуючи автентичність ядра та основного системного середовища.

Пропоновані зміни зводяться до створення єдиного універсального образу УКІ (Уніфікований образ ядра) який об’єднує образ ядра Драйвер Linux для завантаження ядра з UEFI (завантажувальна заглушка UEFI) і системне середовище initrd завантажується в пам'ять, що використовується для початкової ініціалізації на етапі перед монтуванням ФС.

Замість образу ramdisk initrd, вся система може бути упакована в UKI, що дозволяє створювати повністю перевірені системні середовища, які завантажуються в оперативну пам’ять. Образ UKI упаковано як виконуваний файл у форматі PE, який можна не лише завантажити за допомогою традиційних завантажувачів, але й викликати безпосередньо з мікропрограми UEFI.

Можливість дзвонити з UEFI дозволяє використовувати дійсність цифрового підпису та перевірку цілісності який охоплює не лише ядро, але й вміст initrd. У той же час підтримка викликів від традиційних завантажувачів дозволяє зберегти такі функції, як доставка кількох версій ядра та автоматичний відкат до робочого ядра, якщо після встановлення останньої версії виявлено проблеми з новим ядром.

В даний час, використовують більшість дистрибутивів Linux ланцюжок "мікропрограмне забезпечення → шар прокладки Microsoft із цифровим підписом → завантажувач дистрибутива GRUB із цифровим підписом → ядро ​​дистрибутива Linux із цифровим підписом → середовище initrd без підпису → корінь FS" у процесі ініціалізації. Відсутня перевірка initrd у традиційних розподілах створює проблеми безпеки, оскільки серед іншого це середовище витягує ключі для розшифровки кореня FS.

Перевірка зображення initrd не підтримується, оскільки цей файл генерується в локальній системі користувача і не може бути засвідчений цифровим підписом дистрибутива, що дуже ускладнює організацію перевірки в режимі SecureBoot (для перевірки initrd користувачеві потрібно згенерувати ваші ключі та завантажити їх у прошивку UEFI).

Крім того, існуюча організація завантаження не дозволяє використовувати інформацію з регістрів TPM PCR (Реєстр конфігурації платформи), щоб контролювати цілісність компонентів простору користувача, крім shim, grub і ядра. Серед існуючих проблем також називають складність оновлення завантажувача і неможливість обмежити доступ до ключів в TPM для старих версій операційної системи, які стали неактуальними після установки оновлення.

Основні цілі реалізації нова архітектура завантаження:

• Забезпечте повністю перевірений процес завантаження, що охоплює всі етапи від вбудованого програмного забезпечення до простору користувача та підтверджує дійсність і цілісність завантажених компонентів.
• Прив’язка контрольованих ресурсів до реєстрів TPM PCR з поділом за власниками.
• Можливість попереднього обчислення значень PCR на основі завантаження ядра, initrd, конфігурації та ідентифікатора локальної системи.
• Захист від атак відкату, пов’язаних із поверненням до попередньої вразливої ​​версії системи.
• Спростіть і підвищте надійність оновлень.
• Підтримка оновлень ОС, які не потребують повторного застосування або локального надання ресурсів, захищених TPM.
• Підготовка системи до віддаленої сертифікації для підтвердження коректності операційної системи та конфігурації завантаження.
• Можливість додавати конфіденційні дані до певних етапів завантаження, наприклад, шляхом вилучення ключів шифрування для кореня FS із TPM.
• Забезпечте безпечний, автоматичний і тихий процес розблокування ключів для розшифровки диска з кореневим розділом.
• Використання мікросхем, які підтримують специфікацію TPM 2.0, із можливістю повернення до систем без TPM.

Необхідні зміни реалізувати нову архітектуру вже включені в кодову базу systemd і впливають на такі компоненти, як systemd-stub, systemd-measure, systemd-cryptenroll, systemd-cryptsetup, systemd-pcrphase та systemd-creds.

В кінці кінців якщо вам цікаво дізнатись більше про це, ви можете перевірити деталі в наступне посилання.