Додаткові ПЗУ - це вбудоване ПО, що запускається BIOS комп'ютера під час ініціалізації платформи. Зазвичай вони зберігаються на вставляється карті, хоча можуть також знаходитися на системній платі.
Єдиний інтерфейс EFI (UEFI) підтримує застарілий режим додаткових ПЗУ.
Згідно з останньою специфікації UEFI (в даний час - 2.3.1 з поправкою C - розділ 2.5.1.2) додаткові ПЗУ ISA (застарілих типів) не є частиною специфікації UEFI. В рамках цього обговорення будуть розглядатися тільки UEF-сумісні додаткові ПЗУ на основі PCI.
Додаткові ПЗУ можна використовувати, коли неможливо впровадити вбудованого ПО пристрою під вбудоване ПО комп'ютера. Якщо додаткове ПЗУ використовує драйвер, незалежні постачальники обладнання можуть також використовувати цей драйвер і зберігати драйвер і пристрій в одному розташуванні.
В даному документі пояснюється, навіщо потрібно перевіряти додаткові ПЗУ, і описуються деякі методи виконання перевірки.
Підтримка і BIOS UEFI, і BIOS колишніх версій
Багато виробників створюють пристрої, які включають додаткові ПЗУ і вбудоване ПО для багатьох типів комп'ютерів. Основні поєднання включають наступне.
Тільки застарілі ПЗУ
Власні додаткові ПЗУ UEFI
Застарілі ПЗУ + додаткові ПЗУ EBC UEFI
Застарілі ПЗУ + 64-розрядні додаткові ПЗУ UEFI
Застарілі ПЗУ + 64-розрядні UEFI + UEFI IA32
Застарілі ПЗУ + 64-розрядні UEFI + UEFI IA32 + додаткові ПЗУ EBC UEFI
BIOS UEFI може завантажити і запустити традиційні драйвери вбудованого ПО, якщо модуль підтримки сумісності (CSM) включений. Зверніть увагу, що, якщо безпечна завантаження включена, робота модуля підтримки сумісності і застарілих ПЗУ забороняється, оскільки традиційні драйвери вбудованого ПЗ не підтримують перевірку справжності. Якщо формат додаткового ПЗУ в конфігурації BIOS налаштований на застаріле ПЗУ, то на пристрої завжди буде використовуватися традиційні ПЗУ.
Якщо формат додаткового ПЗУ встановлено як сумісний з UEFI. буде використовуватися більш нове ПЗУ EFI при його наявності або старе ПЗУ при відсутності нового.
Драйвери UEFI потрібні для багатьох компонентів безпеки нового вбудованого ПО, а також для включення послідовності завантаження UEFI. Наприклад, установка Windows з оптичного диска, приєднаного до UEFI-несумісного контролера запам'ятовуючих пристроїв, неможлива, якщо система завантажується в режимі UEFI з включеною безпечної завантаженням.
1. UEFI і додаткові ПЗУ
Малюнок 2. Безпека драйверів UEFI (джерело: UEFI 2.3.1 з поправкою C)
З розділу 31.1.4 в 2.3.1 з поправкою C UEFI:
Так як профіль користувача UEFI містить ряд пов'язаних з безпекою привілеїв, важливо, щоб диспетчер посвідчень користувача і постачальники облікових даних користувача, як і середовище, в якому вони виконуються, були довіреними.
Це включає в себе наступне.
Захист області зберігання драйверів.
Захист коштів вибору драйверів.
Захист середовища виконання цих драйверів від неперевірених драйверів.
Компоненти, такі як диспетчер посвідчень, драйвери облікових даних користувача і вбудовані драйвери можуть розміщуватися в надійному розташуванні, наприклад, на захищеному від запису флеш-пам'ять, якому довіряє політика платформи.
Деякі інші драйвери можуть перебувати в незахищених місцях зберігання, таких як додаткові ПЗУ або розділ диска, і можуть бути легко замінені. Такі драйвери необхідно перевірити.
Наприклад, чи політика платформи, яка використовується за замовчуванням, повинна мати можливість успішно перевірити драйвери, перераховані в параметрах завантаження драйвера Driver ####, або необхідно перевірити користувача, перш ніж він буде обробляти ці драйвери. Інакше виконання драйвера повинен бути відкладено. Якщо профіль користувача змінюється за допомогою подальшого виклику команди ідентифікації або за допомогою динамічної перевірки автентичності, то параметри драйвера Driver ####, можливо, не будуть оброблятися знову.
База даних профілів користувачів закривається за допомогою різні події сигналу UEFI на основі того, чи можна її захистити.
Драйвери UEFI і додаткових ПЗУ UEFI будуть виконуватися тільки для пристроїв в шляху завантаження.
Специфікація PCI допускає використання декількох образів додаткових ПЗУ на одному пристрої. Ці додаткові ПЗУ можуть виявитися застарілими 86-розрядними і UEFI. Вбудоване ПО UEFI встановлює політику платформи для вибору додаткових ПЗУ. Завдяки цьому додаткове ПЗУ адаптера може виконуватися як його власний пристрій управління.
Вбудоване ПО перевіряє підписи на етапах BDS і DXE. Послідовність подій виглядає наступним чином.
Ініціалізація PCI і диференціація шин
Проба пристроїв PCI для додаткових ПЗУ
Зіставлення знайдених додаткових ПЗУ в пам'яті
Етап DXE: завантаження драйверів UEFI в ПЗУ
Додаткові ПЗУ UEFI можуть перебувати в будь-якому місці в пам'яті. Значення за замовчуванням дозволяє ПЗУ на платі управляти пристроєм. UEFI дозволяє платформі управляти політикою щодо того, яке додаткове ПЗУ буде керувати тим або іншим пристроєм, за допомогою EFI_PLATFORM_DRIVER_OVERRIDE. UEFI підтримує реєстрацію конфігурації інтерфейсу додатковими ПЗУ.
На ПК, де включена безпечна завантаження, драйвери додаткового ПЗУ представляють загрозу безпеці, якщо не мають підпису або не пройшли перевірку. Перевірка підпису для додаткових ПЗУ є вимогою WHCK. Це ж справедливо при обслуговуванні додаткових ПЗУ, коли необхідно переконатися, що оновлення було перевірено до установки.
З специфікації UEFI 2.3.1 Eratta C:
2. Опис проблеми
Певні збірки BIOS UEFI з підтримкою безпечного завантаження, включаючи Tiano Core, за замовчуванням не виконували перевірку справжності додаткових ПЗУ UEFI, оскільки підписані додаткові ПЗУ UEFI були недоступні під час розробки безпечного завантаження. Це являє можливі напрямки атак і вразливість безпечного завантаження UEFI.
2.1. уразливість
Вихідний код для уразливості TianoCore - файл SecurityPkg \ SecurityPkg.dec:
Перевизначення PCD має бути розміщено в розділі [PcdsFixedAtBuild] файлу DSC. Точний механізм перевизначення параметрів може відрізнятися в залежності від коштів постачальника BIOS.
Ця вразливість може існувати в більш ранніх реалізаціях безпечного завантаження UEFI в BIOS від незалежних постачальників BIOS. Зв'яжіться з вашим постачальником BIOS, щоб дізнатися, чи може ваша версія BIOS бути вразливою.
3. Кого це стосується?
Комп'ютер UEFI, на якому реалізується безпечна завантаження і який використовує додаткове ПЗУ UEFI без підпису. Більш того, вбудоване ПО для сумісності для забезпечення роботи існуючих плат може бути уразливим, не виконуючи перевірку додаткових ПЗУ.
Нетбуки, ноутбуки, ультрабуки і планшети: велика частина не зачіпається Додаткові ПЗУ зазвичай використовуються в шинах об'єднавчої панелі як PCI / e, ISA і їх похідні (ExpressCard, miniPCI, CardBus, PCCard, LPC, ThunderBolt і т.д.). Якщо перераховане вище не використовується в ноутбуці, кількість можливих напрямків атак значно зменшується. Крім того, драйвери UEFI для паралельних компонентів ноутбука інтегруються в тому ядра вбудованого ПО BIOS ядра, розташованого нема на окремому додатковому ПЗУ. Тому більшість ноутбуків не перебувають в групі ризику. Також, якщо застарілі додаткові ПЗУ відключені, UEFI, схоже, підтримує тільки додаткові ПЗУ на основі PCI.
Однак, якщо ваш настільний комп'ютер, системна плата або сервер використовує BIOS UEFI і на ньому реалізується безпечна завантаження, можливо, ваш пристрій вразливе. На виділеному контролері RAID сервера, контролері запам'ятовуючих пристроїв надбудов для SATA, FC і т.д. або мережеві адаптери Ethernet PCIe можуть використовуватися додаткові ПЗУ. Контролери надбудов, що підтримують широкий набір функцій на серверах, широко використовуються, тому це особливо стосується простору сервера.
Це може також стосуватися 32- і 64-розрядні комп'ютери і класу 2 і класу 3.
Якщо платформа безпечного завантаження підтримує додаткові ПЗУ пристроїв, які не підключені до платформи постійно, і можливість перевірити такі додаткові ПЗУ, вона також повинна підтримувати методи перевірки додаткових ПЗУ, описані в мережевих протоколах UDP і MTFTP, і змінні перевірених EFI, описані в розділі 7.2 специфікації UEFI 2.3.1 з поправкою C.
4. Як виконати перевірку?
Якщо ви розробляєте вбудоване ПО на основі Tiano Core, виконайте перевірку на вразливість, згадану в розділі 2.1. Якщо ви використовуєте вбудованого ПО іншого незалежного постачальника BIOS (IBV), зверніться з цим питанням до нього. Або ви також можете виконати перевірку самостійно, як описано нижче.
Вам буде потрібно наступне.
ПК для перевірки з вбудованим ПО UEFI
Переконайтеся, що безпечна завантаження включена
Дії для виконання перевірки
Вставте плату PCI надбудови UEFI з додатковим ПЗУ UEFI в ПК для перевірки.
Увімкніть функцію безпечного завантаження, налаштувавши такі параметри.
PK - ваш PK або самозаверяющій тестовий PK
KEK - Microsoft KEK, тестовий KEK Fabrikam, підписаний з використанням PK, або інший KEK
DB - NULL. (Цей параметр мати значення «NULL»).
SecureBoot - ця змінна UEFI повинна мати значення «true»
Очікується наступний результат.
Незалежно від того, підписаний драйвер додаткового ПЗУ UEFI чи ні, додаткове ПЗУ не завантажується, якщо для параметра DB встановлено значення «NULL», а параметр SB включений (PK і KEK реєструються).
Див. Також інший варіант проведення описаної вище перевірки в Додатку A. Цей підхід не вимагає установки для параметра DB значення «Null», але для виконання перевірки буде потрібно драйвер додаткового ПЗУ UEFI без підпису, придбаний у незалежного постачальника устаткування.
5. Як виправити це?
Якщо описана вище перевірка не пройдена, зверніться до IBV, щоб отримати необхідні версії і налаштувати їх для перевірки додаткових ПЗУ. Переконайтеся, що вбудоване ПО успішно проходить перевірку. Для розповсюджуваних комп'ютерів необхідно буде виконати безпечне оновлення вбудованого ПЗ. Див. Публікацію NIST 800-147 і Керівництво по створенню ключів безпечного завантаження і управління ними в Windows 8.1.
Можна перевірити ПК і використовувати Windows HCK як засіб перевірки (але не засіб сертифікації) для перевірки безпечного оновлення вбудованого ПЗ.
5.1. підписання драйвера
У разі якщо є непідписані драйвери на додаткових ПЗУ UEFI, прочитайте нижче інформацію про те, як це виправити.
Окремо підпишіть кожен драйвер додаткового ПЗУ. Це порушить формат додаткового ПЗУ PCI. Підписати драйвер UEFI потрібно тільки перед створенням об'єднаного додаткового ПЗУ.
Перед введенням драйвера UEFI в додаткове ПЗУ підпишіть образ UEFI і перевірте його при включеною і вимкненою безпечної завантаженні в оболонці UEFI (завантаження і вивантаження файлу драйверів). Потім додайте підписаний драйвер в об'єднане додаткове ПЗУ.
Ваш IHV може звернутися в центр SysDev Microsoft, щоб підписати додаткові ПЗУ UEFI через служби, доступні в центрі SysDev.
5.2. Підтвердження оновлення
Виконайте перевірку, описану вище, щоб переконатися, що відновлення не вразливе. Використовуйте перевірку HCK, щоб переконатися, що функціональні регресії відсутні.
6. Ресурси
Важлива інформація з специфікації UEFI 2.3.1.
2.5.1. Традиційні проблеми додаткового ПЗУ
10. Протоколи - модель драйвера UEFI
13.4.2. Додаткові ПЗУ PCI
20. Віртуальна машина коду байт-коду EFI
28. Загальні відомості про HII
29. Протоколи HII
30. Обробка конфігурації HII і протокол браузера
Додаток A. Альтернативний підхід до тестування за допомогою непідписаних драйверів додаткового ПЗУ
Цей підхід ґрунтується на отриманні коштів від IHV для перевірки того, чи підписаний драйвер додаткового ПЗУ UEFI.
Вам буде потрібно наступне.
ПК для перевірки з вбудованим ПО UEFI
Переконайтеся, що безпечна завантаження включена
Засоби від IHV для виявлення підпису драйвера додаткового ПЗУ, якщо не очевидно - підписаний драйвер додаткового ПЗУ чи ні
Якщо вбудоване ПО реалізовано неправильно, перевірка покаже це.
Додаток B. Сценарії для включення безпечного завантаження за допомогою NULL db
Ви можете або скористатися поточним набором змінних безпечного завантаження (PK і KEK) або згенерувати тестові змінні для цілей перевірки.
Нижче описані дії для створення тестових PK, KEK і установка параметра DB в значення «NULL». Переконайтеся, що безпечна завантаження не включена; в іншому випадку для виконання цих кроків потрібно підписані bin-файли UEFI.
Змінні безпечного завантаження - DB, KEK і PK - встановлюються в зворотному порядку, тому підписувати bin-файли UEFI не обов'язково.
До цього етапу комп'ютер повинен знаходитися в режимі установки.
Створення сертифікатів KEK і PK
Для цього кроку потрібна наявність кошти makecert.exe, доступного в Windows SDK.