Linux та безпечне завантаження. Помилка, яку ми не можемо повторити

В попередня стаття Я нагадав прецедент вимоги Microsoft вимагати, щоб модуль TPM версії 2 міг використовувати Windows 11. Я маю на увазі вимогу, що комп’ютери з попередньо встановленою Windows 8 використовують UEFI замість BIOS для завантажувача та що модуль Secure Boot був попередньо встановлений.  Тепер я збираюся розповісти про, на мою думку, неправильний спосіб вирішення проблеми Linux.

Linux та безпечне завантаження

Безпечне завантаження вимагає, щоб кожна запущена програма мала підпис, що гарантує її достовірність, що зберігається в базі даних енергонезалежної пам'яті материнської плати. Існує два способи відображення в цій базі даних. Включається він виробником чи Microsoft.

Рішення, досягнуте деякими дистрибутивами Linux з Microsoft що ця компанія прийняла підпис бінарного файлу, який відповідав би за завантаження завантажувача кожного дистрибутива. Ці двійкові файли були надані спільноті.

Згодом Linux Foundation запустить загальне рішення, яке може бути прийняте усіма дистрибутивами.

У пошуках кращого рішення розробник Red Hat запропонував Лінусу Торвальдсу наступне:

Привіт Лінусе,

Чи можете ви включити цей набір патчів, будь ласка?

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

Тепер "keyctl add" вже буде обробляти сертифікати X.509, підписані таким чином, але служба підписання Microsoft підписуватиме лише виконувані двійкові файли EFI PE.

Ми можемо вимагати, щоб користувач перезавантажився в BIOS, додав ключ, а потім повернувся, але за деяких обставин ми хочемо мати можливість це робити під час роботи ядра.

Ми вирішили це виправити - вставити сертифікат X.509, що містить ключ у розділі під назвою ".keylist", у двійковий файл EFI PE, а потім отримати двійковий файл із підписом Microsoft.

Слово Лінус

Відповідь Лінуса (згадаймо, що до його духовного відступу, щоб переглянути своє ставлення у стосунках з іншими людьми), була така:

УВАГА: Наступний текст містить ненормативну лексику

Хлопці, це не конкурс смоктання півня.

Якщо ви хочете використовувати двійкові файли PE, продовжуйте. Якщо Red Hat хоче поглибити свої відносини з Microsoft, це * ваша * проблема. Це не має нічого спільного з ядром, яке я підтримую. Вам легко мати механізм підписів, який аналізує двійковий файл PE, перевіряє підписи та підписує отримані ключі власним ключем. Код, для Бога, вже написаний, він у цьому клятому запиті на включення.

Чому я повинен дбати? Чому ядро ​​має піклуватися про якісь ідіотські "ми лише підписуємо двійкові файли PE" дурних? Ми підтримуємо X.509, який є стандартом для підписання.

Це можна зробити на рівні користувача. У ядрі немає виправдань.

Лінус

Я вважаю, що Лінус колись мав рацію. Фактично ані Linux Foundation, ані дистрибутиви не мали шантажувати Microsoft.  Це правда, що користувачі могли бути втрачені. Але, як виявилося пізніше, Windows 8 виявилася невдалою, і XP продовжувала панувати набагато довше.

Реальність така, що коли Microsoft стикається з битвою, вона змушена дотримуватися стандартів. Це сталося, коли вона зазнала невдачі з SIlverlight і була змушена прийняти веб -стандарт HTML 5. Це сталося, коли їй довелося відмовитися від розробки двигуна веб -рендеринга і базувати Edge на Chromium.

Також не слід забувати, що для залучення програмістів вона мала включати не що інше, як можливість запускати Linux під Windows.

Дистрибутиви Linux, як ніколи, пропонують користувачам альтернативу продовжувати використовувати ідеально функціональне обладнання.