Данные обещания надо выполнять, тем более, если они сделаны сначала в заключительной части опуса о безопасности UEFI, а потом повторены со сцены ZeroNights 2015, поэтому сегодня поговорим о том, как заставить UEFI SecureBoot работать не на благо Microsoft, как это чаще всего настроено по умолчанию, а на благо нас с вами. Если вам интересно, как сгенерировать свои обственные ключи для SecureBoot, как установить их вместо стандартных (или вместе с ними), как подписать ваш любимый EFI-загрузчик, как запретить загрузку неподписанного или подписанного чужими ключами кода, как выглядит интерфейс для настройки SecureBoot у AMI, Insyde и Phoenix и почему это, по большому счету, совершенно не важно — добро пожаловать под кат, но опасайтесь большого количества картинок и длинных консольных команд.
Введение
О том, как устроен и работает SecureBoot, я уже рассказывал в начале пятой части вышеупомянутого опуса, повторяться смысла не вижу. Если вы не в курсе, о чем весь этот UEFI SecureBoot вообще, кто такие PK, KEK, db и dbx, и почему с точки зрения SecureBoot по умолчанию хозяином вашей системы является производитель UEFI, а единственным авторизованным пользователем является Microsoft — смело проследуйте туда, мы вас тут пока подождем.
С ликбезом закончили, теперь к делу. Несмотря на то, что про создание своих ключей и настройку SecureBoot написано за три последних года с десяток отличных статей (ссылки на часть из которых приведены в разделе Литература), воз и ныне там. Основная проблема с информацией о настройке SecureBoot даже в англоязычном сегменте сети (не говоря уже о рунете) — большая часть статей, текстов и постов обрывается на «вот у нас теперь есть ключи в формате EFI Signature List, добавьте их зависимым от вашего вендора прошивки способом и готово». При этом сами вендоры не торопятся описывать меню настройки SecureBoot ни в документации на свои платформы для OEM'ов, ни в мануалах на конечные системы, в результате пользователь теряется на незнакомой местности и либо отключает SecureBoot, мешающий загружать его любимую OpenBSD (или что там у него), либо оставляет его на настройках по умолчанию (а чего, Windows грузится же). Именно этот последний шаг я и попытаюсь описать более подробно, но не в ущерб остальным необходимым шагам.
Тестовая конфигурация
Специально для этой статьи я достал из закромов пару не самых новых ноутбуков с прошивками на платформах Phoenix SCT и Insyde H2O, а также совершенно новую плату congatec (разработкой прошивки для которой я занят в данный момент) на платформе AMI AptioV. Встречайте, наши тестовые стенды:
1. AMI, они же "треугольные": congatec conga-TR3 @ conga-TEVAL, AMD RX-216GD (Merlin Falcon), AMI AptioV (UEFI 2.4)
2. Insyde, они же "квадратные": Acer Aspire R14 R3-471T (Quanta ZQX), Intel Core i3-4030U (Ivy Bridge), Insyde H2O (UEFI 2.3.1C)
3. Phoenix, они же "полукруглые": Dell Vostro 3360 (Quanta V07), Intel Core i7-3537U (Ivy Bridge), Phoenix SCT (UEFI 2.3.1C)
Об интерфейсах для настройки SecureBoot
На всех вышеперечисленных системах производитель заявляет о поддержке технологии UEFI SecureBoot, но интерфейс для ее настройки сильно отличается между системами. К счастью, это не очень большая проблема, поскольку для настройки SecureBoot на совместимых со спецификацией UEFI 2.3.1C (и более новых) прошивках никакого интерфейса в Setup, кроме возможности удаления текущего PK (т.е. перевода SecureBoot в так называемый Setup Mode) не требуется, а после этого можно использовать любое EFI-приложение, способное вызвать UEFI-сервис gRS->SetVariable с предоставленными пользователем данными, в том числе утилиту KeyTool.efi из пакета efitools, которая специально для управления ключами и предназначена, осталось только научиться ей пользоваться.
Тем не менее, если удобный интерфейс для настройки присутствует (у AMI он, на мой взгляд, даже удобнее KeyTool'а) — можно воспользоваться им, так что рассказывать про эти самые интерфейсы все равно придется.
Готовим плацдарм
Начнем с лирического отступления о наличии нужного софта для разных ОС. Несмотря на то, что Microsoft является одним из разработчиков технологии, в открытом доступе до сих пор отсутствуют нормальные средства для работы с ней из Windows (ключи можно сгенерировать утилитой MakeCert из Windows SDK, а для всего остального предлагается использовать HSM третьих лиц за большие деньги). Я подумывал сначала взять и написать нужную утилиту на Qt, но потому решил, что ключи и подписи каждый день генерировать не нужно, а на пару раз хватит и существующих решений. Можете попробовать переубедить меня в комментариях, если хотите.
В общем, для всего нижеперечисленного вам понадобится Linux (который можно запустить с LiveUSB, если он у вас не установлен). Для него существует целых два набора утилит для работы с SecureBoot: efitools/sbsigntool и EFIKeyGen/pesign. У меня есть положительный опыт работы с первым набором, поэтому речь пойдет именно о нем.
В итоге, кроме Linux, нам понадобятся несколько вещей:
1. Пакет openssl и одноименная утилита из него для генерирования ключевых пар и преобразования сертификатов из DER в PEM.
2. Пакет efitools, а точнее утилиты cert-to-efi-sig-list, sign-efi-sig-list для преобразования сертификатов в формат ESL и подписи файлов в этом формате, и KeyTool.efi для управления ключами системы, находящейся в SetupMode.
3. Пакет sbsigntool, а точнее утилита sbsign для подписи исполняемых файлов UEFI (т.е. загрузчиков, DXE-драйверов, OptionROM'ов и приложений для UEFI Shell) вашим ключом.
Загрузите Linux, установите вышеуказанные пакеты, откройте терминал в домашней директории и переходите к следующему шагу.
Генерируем собственные ключи для SecureBoot
Как обычно, есть несколько способов сделать что-либо, и чем мощнее используемый инструмент, тем таких способов больше. OpenSSL же как инструмент развит настолько, что кажется, что он умеет делать вообще всё, а если почитать к нему man — то и абсолютно всё остальное. Поэтому в этой статье я ограничусь непосредственной генерацией ключевых файлов, а танцы вокруг создания собственного CA оставлю на самостоятельное изучение.
Генерируем ключевые пары
Ключей понадобится сгенерировать три штуки: PK, KEK и ISK.Начнем с PK, для генерации которого нужно выполнить следующее
openssl req -new -x509 -newkey rsa:2048 -sha256 -days 365 -subj "/CN=Platform Key" -keyout PK.key -out PK.pemКомандой выше мы просим OpenSSL сгенерировать нам ключевую пару RSA2048/SHA256 со сроком действия на один год, под названием Platform Key, с выводом закрытого ключа в файл PK.key, а открытого — в файл PK.pem. Если добавить -nodes, то для подписи этой ключевой парой не нужен будет пароль, но здесь мы этого делать не станем — с паролем хоть ненамного, но безопаснее.
Таким же образом генерируем ключевые пары для KEK и ISK, пароли при этом советую вводить разные:
openssl req -new -x509 -newkey rsa:2048 -sha256 -days 365 -subj "/CN=Key Exchange Key" -keyout KEK.key -out KEK.pemopenssl req -new -x509 -newkey rsa:2048 -sha256 -days 365 -subj "/CN=Image Signing Key" -keyout ISK.key -out ISK.pemКонвертируем открытые ключи в формат ESL
Теперь нужно сконвертировать открытые ключи из формата PEM в понятный UEFI SecureBoot формат ESL. Этот бинарный формат описан в спецификации UEFI (раздел 30.4.1 в текущей версии 2.5) и интересен тем, что файлы в нем можно соединять друг с другом конкатенацией, и этот факт нам еще пригодится.cert-to-efi-sig-list -g "$(uuidgen)" PK.pem PK.eslcert-to-efi-sig-list -g "$(uuidgen)" KEK.pem KEK.eslcert-to-efi-sig-list -g "$(uuidgen)" ISK.pem ISK.eslПодписываем ESL-файлы
Для правильно работы SecureBoot необходимо, чтобы PK был подписан сам собой, KEK подписан PK, а хранилища db и dbx — сответственно KEK. При этом PK не может быть несколько, а вот ситуация с несколькими KEK хоть и встречается в дикой природе, но я все же настоятельно рекомендую удалить предустановленный ключ Microsoft из KEK по простой причине — db и dbx могут быть подписаны любым ключом из хранилища KEK, т.е. если ключ MS оттуда не удалить, то у MS будет возможность управлять содержимым db и dbx, т.е. добавлять любые новые ключи или хеши в список доверенной загрузки и удалять из него существующие. На мой взгляд, это немного слишком, и если мы берем управление ключами в свои руки, то нужно делать это до конца.openssl x509 -in MicCorKEKCA2011_2011-06-24.crt -inform DER -out MsKEK.pem -outform PEMcert-to-efi-sig-list -g "$(uuidgen)" MsKEK.pem MsKEK.eslcat KEK.esl MsKEK.esl > NewKEK.eslmv -f NewKEK.esl KEK.eslПоследовательность та же, что и под спойлером выше. Конвертируем из DER в PEM, затем из PEM в ESL, затем добавляем к db.esl, который в конце концов надо будет подписать любым ключом из KEK:
openssl x509 -in MicWinProPCA2011_2011-10-19.crt -inform DER -out MsWin.pem -outform PEMopenssl x509 -in MicCorUEFCA2011_2011-06-27.crt -inform DER -out UEFI.pem -outform PEMcert-to-efi-sig-list -g "$(uuidgen)" MsWin.pem MsWin.eslcert-to-efi-sig-list -g "$(uuidgen)" UEFI.pem UEFI.eslcat ISK.esl MsWin.esl UEFI.esl > db.eslТеперь подписываем PK самим собой:
sign-efi-sig-list -k PK.key -c PK.pem PK PK.esl PK.authsign-efi-sig-list -k PK.key -c PK.pem KEK KEK.esl KEK.authsign-efi-sig-list -k KEK.key -c KEK.pem db db.esl db.authЕсли еще не надоело, можно добавить чего-нибудь еще в db или создать хранилище dbx, нужные команды вы теперь знаете, все дальнейшее — на ваше усмотрение.
Подписываем загрузчик
Осталось подписать какой-нибудь исполняемый файл ключом ISK, чтобы проверить работу SecureBoot после добавления ваших ключей. Для тестов я советую подписать утилиту RU.efi, она графическая и яркая, и даже издалека видно, запустилась она или нет. На самом деле, утилита эта чрезвычайно мощная и ей можно натворить немало добрых и не очень дел, поэтому после тестов лучше всего будет её удалить, и в дальнейшем подписывать только загрузчики.В любом случае, подписываются исполняемые файлы вот такой командой:
sbsign --key ISK.key --cert ISK.pem --output bootx64.efi RU.efiВ результате вот этого всего у вас получились три файла .auth, которые нужно будет записать «как есть» в NVRAM-переменные db, KEK и PK, причем именно в таком порядке. Скопируйте все три файла в корень другого USB-носителя с ФС FAT32, на котором в качестве /EFI/BOOT/bootx64.efi выступит /use/share/efitools/efi/KeyTool.efi (скопируйте его еще и в корень, на всякий случай) и ваш «набор укротителя SecureBoot» готов.
Укрощение строптивого
Начинается все одинаково: вставляем нашу флешку с ключами и KeyTool'ом в свободный USB-порт, включаем машину, заходим в BIOS Setup. Здесь, прежде чем заниматься настройкой SecureBoot, нужно отключить CSM, а с ним — и легаси-загрузку, с которыми наша технология не совместима. Также обязательно поставьте на вход в BIOS Setup пароль подлиннее, иначе можно будет обойти SecureBoot просто отключив его, для чего на некоторых системах с IPMI и/или AMT даже физическое присутсвие не потребуется.
AMI AptioV
У большинства прошивок, основанных на коде AMI, управление технологией SecureBoot находится на вкладке Security, у меня это управление выглядит так:
Заходим в меню Key Management (раньше оно было на той же вкладке, сейчас его выделили в отдельное) и видим там следующее:
Выбираем нужную нам переменную, после чего сначала предлагают выбрать между установкой нового ключа и добавлением к уже имеющимся, выбираем первое:
Теперь предлагается либо установить значение по умолчанию, либо загрузить собственное из файла, выбираем последнее:
Далее нужно устройство и файл на нем, а затем выбрать формат этого файла, в нашем случае это Authenticated Variable:
Затем нужно подтвердить обновление файла, и если все до этого шло хорошо, в результате получим лаконичное сообщение:
Повторяем то же самое для KEK и PK, и получам на выходе вот такое состояние:
Все верно, у нас есть единственный PK, всего один ключ в KEK и три ключа в db, возвращаемся в предыдущее меню кнопкой Esc и включаем SecureBoot:
Готово, сохраняем настройки и выходим с перезагрузкой, после чего пытаемся загрузиться с нашей флешки и видим вот такую картину:
Отлично, неподписанные загрузчики идут лесом, осталось проверить подписанный. Вставляем другую флешку, перезагружаемся и видим что-то такое:
Вот теперь можно сказать, что SecureBoot работает как надо.
Если у вашего AMI UEFI такого интерфейса для добавления ключей нет, то вам подойдет другой способ, о котором далее.
Insyde H2O
Здесь все несколько хуже, чем в предыдущем случае. Никакого интерфейса для добавления собственных ключей нет, и возможностей настройки SecureBoot предлагается всего три: либо удалить все переменные разом, переведя SecureBoot в Setup Mode, либо выбрать исполняемый файл, хеш которого будет добавлен в db, и его можно будет запускать даже в том случае, если он не подписан вообще, либо вернуться к стандартным ключам, в качестве которых на этой машине выступают PK от Acer, по ключу от Acer и MS в KEK и куча всякого от Acer и MS в db.Впрочем, нет интерфейса — ну и черт с ним, у нас для этого KeyTool есть, главное, что в Setup Mode перейти можно. Интересно, что BIOS Setup не дает включить SecureBoot, если пароль Supervisor Password не установлен, поэтому устанавливаем сначала его, затем выполняем стирание ключей:
После чего на соседней вкладке Boot выбираем режим загрузки UEFI и включаем SecureBoot:
Т.к. фотографии у меня посреди ночи получаются невыносимо отвратительными, то скриншоты KeyTool'а я сделаю на предыдущей системе, и придется вам поверить в то, что на этой все выглядит точно также (мамой клянусь!).
Загружаемся с нашего носителя в KeyTool, и видим примерно следующее:
Выбираем Edit Keys, попадаем в меню выбора хранилища:
Там сначала выбираем db, затем Replace Keys, затем наше USB-устройство, а затем и файл:
Нажимаем Enter и без всяких сообщений об успехе нам снова показывают меню выбора хранилища. Повторяем то же самое сначала для KEK, а затем и для PK, после выходим в главное меню двойным нажатием на Esc. Выключаем машину, включаем заново, пытаемся загрузить KeyTool снова и видим такую картину (которую я утащил из дампа прошивки, ее фото на глянцевом экране еще кошмарнее, чем предыдущие):
Ну вот, одна часть SecureBoot'а работает, другая проверяется запуском подписанной нами RU.efi и тоже работает. У меня на этой системе Windows 8 установлена в UEFI-режиме, так вот — работает и она, Microsoft с сертификатом не подвели.
Phoenix SCT
Здесь возможностей еще меньше, и во всем меню Secure Boot Configuration на вкладке Security всего два пункта: возврат к стандартным ключам и удаление всех ключей с переводом системы в SetupMode, нам нужно как раз второе:
Затем на вкладке Boot нужно выбрать тип загрузки UEFI, включить SecureBoot, и создать загрузочную запись для KeyTool'а, иначе на этой платформе его запустить не получится:
Нажимаем Yes, выходим с сохранением изменений, перезагружаемся, нажимаем при загрузке F12, чтобы попасть в загрузочное меню, оттуда выбираем KeyTool, работа с которым описана выше. После добавления ключей и перезагрузки попытка повторного запуска KeyTool'а заканчивается вот так:
При этом установленный на той же машине Linux продолжает исправно загружаться, как и подписанная нами RU.efi, так что SecureBoot можно признать работоспособным.
Заключение
В итоге, благодаря утилитам с открытым кодом, удалось завести SecureBoot на системах с UEFI трех различных вендоров, сгенерировать свои собственные ключи и подписать ими нужные нам исполняемые файлы. Теперь загрузка платформы целиком в наших руках, но только в случае, если пароль на BIOS стойкий и не хранится открытым текстом, как у некоторых, а в реализации SecureBoot нет каких-либо известных (или еще неизвестных) дыр. Сам по себе SecureBoot — не панацея от буткитов, но с ним ситуация с безопасной загрузкой все равно намного лучше, чем без него.
Надеюсь, что материал вам поможет, и спасибо за то, что прочитали эту портянку.
Литература
Managing EFI Bootloaders for Linux: Controlling SecureBoot.
AltLinux UEFI SecureBoot mini-HOWTO.
Booting a self-signed Linux kernel.
Sakaki's EFI Install Guide: Configuring SecureBoot.
Ubuntu Security Team: SecureBoot.
Owning your Windows 8 UEFI Platform.
MinnowBoard Max: Quickstart UEFI Secure Boot.
Windows 8.1 Secure Boot Key Creation and Management Guidance.
Комментарии (45)
en1gma
19.12.2015 15:25+1а без входа в конфиг сбросить ключи можно? если, не дай Б-же, пароль на вход в конфиг забыли. али только через дырки в «обработчиках» nvram?
istui
19.12.2015 15:46+1тоже интересно. Есть ли какие-то способы обхода? перебор пароля/замена микросхемы?
CodeRush
19.12.2015 16:04Стирание NVRAM при помощи программатора, либо подсистемой Crisis Recovery прошивки — два стандартных способа, которые помогают в случае, если PKpriv или пароль утеряны. Если доступ к PKpriv есть, отключить SecureBoot можно удалением переменной PK вызовом SetVariable с нужными параметрами из любой загруженной ОС.
CodeRush
20.12.2015 00:52+2Добавлю еще, что на некоторых системах (на вот этом Acer тестовом, к примеру) есть возможность сброса пароля звонком в Acer Support, где нужно будет доказать, что машина не украдена, а затем назвать набор цыфр, которые отображаются на экране после 3 неудачных попыток ввода пароля. В ответ они пришлют другой набор, и если ответ правильный, то драйвер UnlockPwd этот самый пароль сотрет.
evg_krsk
19.12.2015 18:38+5Спасибо, Хабр торт :-)
Одно замечание. Мне кажется, что упомянутая во врезке (и слайдах ZN) команда:
cat KEK.esl MsKEK.esl > KEK.esl
— потенциально очень вредная. Обычно оболочка открывает на запись файл вывода до того как выполнять собственно команду (говорю за B-шеллы, проверил на bash/zsh). В результате выполнения данной команды мы делаем так, что в KEK оказывается только ключ MS, но не наш. Лучше было бы как-то так:
cat KEK.esl MsKEK.esl > newKEK.esl
mv -f newKEK.esl KEK.esl
PsyHaSTe
23.12.2015 13:41+1Спасибо за статью. Задам наверное глупый вопрос, но все же: эти уязвимости эксплуатируются удаленно или при физическом контакте с машиной? Ну например у меня компьютер стоит в комнате, куда попасть могу только я, но безопасность я всё же уважаю. Стоит ли мне проделывать все эти шаги, или если грубо говоря комната закрыта — то компьютеру ничего не угражает? Потому что после прочтения статьи сложилось впечатление что мы «получаем всё то же, что и раньше, но теперь некоторый софт может отваливаться, рассчитывая на стандартные ключи от МС». Поправьте, пожалуйста, если не прав.
CodeRush
23.12.2015 15:04Уязвимости в процессе загрузки системы могут эксплуатироваться и локально, и удаленно, но для этого нужно повышение провилегий до возможности монтирования ESP и переписывания загрузчика на нем (обычного LPE до System хватит за глаза). Дальше при отсутвии SecureBoot малварь может подменить загрузчик системы на собственный, и дальше рулить системой как ей заблагорассудится (т.к. она контролирует загрузку ядра и имеет возможность патчить его на лету), а в случае с включенным SecureBoot придется обходить сначала его, иначе вместо перехвата управления получится банальный DoS.
evg_krsk
23.12.2015 15:46+1Может быть, не по адресу вопрос, но нет ли какой-то информации, планируется ли в UEFI как-то реализовать избыточность/отказоустойчивость ESP? Сейчас приходится или класть его на аппаратный RAID или работать в CSM, программный RAID в пролёте. Как и SecureBoot.
Или же где лучше поискать подобную информацию?CodeRush
23.12.2015 15:56Не видел таких планов, но это не значит, что их нет.
ESP, на самом деле, не является обязательным, проблема только в отсутсвии драйвера для вашего Software RAID в прошивке. Если его написать и добавить, то можно будет спокойно загружаться с этого самого RAIDа не хуже, чем с ESP.
Пример похожего решения: добавление драйвера NVMe в прошивку старых плат решает проблему UEFI-загрузки с NVMe-устройств.evg_krsk
23.12.2015 16:15+1Признаюсь, я не очень хорошо понимаю, как вообще загружается EUFI-система. Могу пороть чушь.
Я так понимаю, драйвер и не нужен. Сейчас у меня несколько систем с CSM вполне себе загружаются с любого из дисков в массиве, а там уже ядро собирает логический RAID. Т.е. ядро (в данном случае говорю про Linux) само себе «драйвер». Останавливает от перехода на UEFI то, что если откажет диск, на котором лежит ESP — система загрузиться не сможет. Т.е. сделать то ESP на каждом диске несложно, как и нагородить костылей с регулярной синхронизацией «главного» ESP с «подчинёнными», но хочется более прямого решения.
Загрузка без ESP — это интересный вариант. Есть что-то почитать на эту тему?
CodeRush
23.12.2015 16:33Загружаются эти системы с CSM исключительно потому, что на каждом диске есть MBR, в которую записан нужный код. Код этот передает управление на PBR раздела /boot или напрямую загрузчику, а он дальше загружает ядро. Если бы MBR была только на одном диске — сисема загружалась бы только с него. Поэтому и ESP нужно на все диски положить. Другой вопрос, что драйверу Software RAID может не понравится ФС FAT на ESP, но она и не обязательна в том случае, если в прошивке имеется драйвер Ext2/3/4.
По поводу загрузки без ESP — почитайте исходники Intel Quark BSP (это открытая прошивка для Intel Galileo, я он ней писал в прошлом году), там система загружается с образа, который прошит непосредственно в микросхему SPI.
Eklykti
23.12.2015 16:52+1Софтрейду (через mdadm) в принципе без разницы, какая ФС на устройстве. Разве что стоит делать массив с метаданными в конце, а не в начале (-e 0.9 или 1.0), чтоб прошивка, не умеющая md, могла его читать как обычный раздел.
CodeRush
23.12.2015 17:01+1Ну тогда ничего не мешает сделать ESP на каждом диске, и пусть за их дупликацию и целостность отвечает тот же програмный RAID, что и за остальное.
dmitrmax
23.12.2015 23:39+2Софтрейду в Linux действительно всё равно на счёт ФС. Потому что в линуксе есть абстракция под названием «блочное устройство», а есть куча файловых систем, которые могут работать поверх любого блочного устройства. Есть ли такое разделение в UEFI я не знаю. Так что очень может статься, что если пилить Softraid для UEFI, то придется его делать filesystem aware.
CodeRush
24.12.2015 00:05+1Есть такая абстракция и в UEFI, и драйверы дисков, к примеру, побликуют их не как ФС или разделы, а как блочные устройства, доступные для чтения и\или записи через протоколы EFI_BLOCK_IO_PROTOCOL и EFI_DISK_IO_PROTOCOL, по штуке на каждое найденное устройство. Обнаружив наличие этих протоколов, драйвер PartitionDxe пытается найти всех дисках разделы, если они нашлись, публикуется EFI_DEVICE_PATH для этих разделов, а его в свою очередь получают драйверы FilesystemDxe, Ntfs, Ext2Dxe, HfsPlusDxe и так далее.
Если пилить программный рейд, то достаточно пояснить, как с него считать загрузчик, дальнейшее — дело ядра Linux, которое этим загрузчиком запустится (или является в случае использования EFI_STUB).
dmitrmax
23.12.2015 23:32+1Статья интересная, но возвращает нас к вопросу о том, что ненормальные вендоры вот-вот запретят шить левый биос, если уже не запретили. Нет ли планов сделать добавление драйверов по ходу пьесы без перепрошивки биоса? Тот же SecureBoot мог бы обеспечить защиту от левака. Сегодня появился NVMe, завтра ещё что-нибудь появится…
PS: С ностальгией вспоминаю OpenFirmware, где прямо в консоли «биоса» можно было наваять дровинку на Fort'е и сохранить её в NVRAM.CodeRush
23.12.2015 23:53Есть такая функция у нас на новых платах, называется MPFA, куда сам пользователь без перепрошивки остального БИОСа может добавить кучу разного, в том числе и целый новый Firmware Volume, который при следующей загрузке будет передан диспетчеру DXE, и оттуда будет исполнено все, что нужно. Понятно, что это — даже не дыра в безопасности, а открытые ворота в прошивку, но для того, чтобы сохранить что-то в MPFA, нужно сначала ввести пароль на BIOS, и после 3 неудачных попыток ввод блокируется до перезагрузки, т.е. авторизованный пользователь модифицирует то, что ему нужно, а удаленный атакующий идет лесом.
Собираются ли внедрить что-то похожее в стандартные реализации UEFI — не знаю, я об этом ничего не слышал, но тенденция, как верно подмечено, совершенно противоположная — «закрыть и не пущать». Меня это не устраивает, и начальника моего тоже, поэтому у congatec весь этот Hardware Verified Boot и прочие схемы защиты платформы от её же покупателя будут включены только для клиентов, которые требуют этого в обязательном порядке.dmitrmax
24.12.2015 00:05+1E — Extensible. Во истину корпоративный маразм крепчает. Придумать такой стэк, предусмотреть в нём возможность расширяемости, чтобы потом придумать как костылями эту расширямость ограничить до compile time — ради этого нужно придумать антипремию Тьюринга и вручить! )
Жалко, что ваша линейка продуктов такая узкоспециализированная.CodeRush
24.12.2015 00:09Ну так Extensible же во все поля, буквально, только не для конечного пользователя. Для него есть ESP и переменные DriverXXXX и KeyXXXX, расширяй функциональность — не хочу, но только после окончания фазы BDS.
Пусть делают что хотят, пока BootGuard не включают. Все остальное при желании может быть (обязательно будет) отломано энтузиастами.
thatsme
Очень интересная статья, и поучительная. Особенно относительно того, что касается безопасности.
CodeRush
Про безопасность SecureBoot и атаки на него я уже ранее писал, здесь больше про то, как им взять и начать пользоваться.
Безопасность SecureBoot держится на безопасности NVRAM, т.е. для нее необходимо, чтобы к содержимому NVRAM нельзя было получить доступ каким-то обходным способом, а не стандартными GetVariable/SetVariable, и по умолчанию на обеих ноутбуках это не так (прошивки уязвимы к атакам на S3 BootScript, что позволяет записать свой код в микросхему, что позволяет стартовать раньше SecureBoot, т.е. толку от него без защиты остального — ноль без палочки).
Безопасность любой системы определяется по самому слабому звену, поэтому вместе с SecureBoot нужно использовать и другие способы защиты прошивки, теорию о которых я описывал в вышеупомянутом цикле, а практику показывал на ZeroNights 2015.
Если вы простой пользователь и хотите, чтобы о безопасности вашей прошивки подумал вендор — покупайте системы HP или Dell, несмотря на все их недостатки, конкретно с защитой прошивок там все намного лучше, чем у конкурентов.
dmitrmax
> Если вы простой пользователь и хотите, чтобы о безопасности вашей прошивки подумал вендор
Простые пользователи, дошедшие до использования SecureBoot хотят, чтобы безопасность могла обеспечиваться не вендором, а своими руками. Читай
legalize weed!open firmware! ))) В сущности вся проприетарщина в этой области ПО выглядит ужасно смешной и при этом жутко бесит.CodeRush
Основная проблема открытых прошивок — Intel и AMD не горят желанием открывать MRC для новых систем даже своим же IBV, тем более сообществу. Взамен предлагается использовать Intel FSP / AMD AGESA binary, которые, по факту — мегабайтные BLOBы, реализующие 90% фазы PEI. В итоге что закрытый UEFI, что открытый coreboot + SeaBIOS/TianoCore/Linux — разницы с точки зрения любящего свободу пользователя почти никакой. А реверсить код MRC — дело не на один год, к тому времени целевая платформа уже устаревает до грани полной непривлекательности.
Решать эту проблему нужно с открытия железа и спецификаций к нему, за открытым софтом к таким системам дело не станет.
Добавлю также, эталонная что реализация SecureBoot открыта под лицензией BSD и является частью проекта TianoCore, и мой опыт показывает, что реализации IBV отличаются от нее очень мало, но, конечно, это все равно не тот открытый код, который нам нужен.
dmitrmax
Я в курсе, что Intel и AMD ломаются как девствиницы. Моя претензия не к вам лично, а по большому счёту просто в эфир )
Кстати, тут на фоне громкого «выхода» полностью свободных ноутбуков почитал, что якобы в новых платформах невозможно вырезать MEI, так как если автономный котроллер ME не получает за 30 секунд после старта подписанную прошивку, то он ребутит систему. Это реально всё так плохо?
CodeRush
Да я это все слишком близко к сердцу и не принимаю, просто сейчас оно все именно вот так, и каких-то тенденций к изменению ситуации пока не видно. Единственная плата с открытой реализацией UEFI — Intel Galileo, там тоже не обошлось без блобов.
Про «все так плохо» — нет, это зависит от настроек, которые установил производитель ПК. Если он захочет, у вас современная машина с чипсетом/СнК Intel даже до ResetVector'а не дойдет, если хеш прошивки не сойдется с эталонным, но так настраивают систему только полные мудаки, и у таких я советую просто ничего не покупать.
JerleShannara
Хотите 100% открытое — Lenovo T500/X200 последнее что вы можете. Хотите чтоб минимум блобов (видеобиос остаётся только) — чтонить на Amd kabini.
Из топового интелового — сейчас в coreboot человек делает гигабайтовскую плату на G41 чипсете. Про Core iX и открытость — забудьте навсегда. Хотите что-то открытое на AMD с PSP — опять забудьте навсегда.
CodeRush
Вот слова не мальчика, но мужа.
Переписать GOP-драйвер и SMU firmware для eKabini — и можно жить, все более новое — сразу в лес.
JerleShannara
Вот именно, что более свежее 100% в лес — амд нивкакую не хочет делиться с opensource сообществом данными по PSP, акромя того, что оный есть ARM ядро и что он проверит вашу прошивку перед снятием ресета с x86. Ну а интел сами сказали всё, внеся в железную часть AMT/ME сторожевой таймер, отключающий систему через 30 минут, если код AMT/ME не выполнился. И если с PSP я ещё не слышал громких интриг и скандалов, то про старые реализации ME их уже было достаточно.
П.С. Если в переписывание видеобиоса я ещё верю, то вот в SMU верится очень слабо, т.к. оный везде (включая BKDG что открытые, что закрытые) описан как черный ящик.
dmitrmax
Скорее бы с этой проприетарщиной случилась какая-нибудь ерунда, типа всплывшей залепухи от Volkswagen. И тогда была бы надежда, что какая-нибудь еврокомиссия нагнёт их раком, чтобы либо выпилили, либо открыли.
Что касается леса, то в лесу вы долго не проживете. Тупо сломается когда-нибудь (
JerleShannara
Ну когда в лесу умрёт последний кабини (а умрёт он не ранее 2024 года, если верить АМД, если при этом включить режим «как правило ещё пару лет можно купить без проблем», то 2026 год) — тогда и будем думать, может к тому времени будет что-то от других игроков (ну а вдруг VIA оживёт на плацу х86, либо АРМ будет цвести и пахнуть на рынке десктопов (хотя сейчас и с армом на поле opensource не всё радужно))
dmitrmax
Мы о чем сейчас говорим? О том, что вы сейчас купите компьютер и он проработает до 2026 года, или о том, что у некоего вендора будет возможность купить комплектуху в 2026 и сделать комп, который он сможет без стыда поставить на витрину и продать в 2026?
CodeRush
О втором. Для вендоров из Embedded и Industrial AMD гарантирует десятилетний срок поддержки и выпуска чипов, пусть и не очень крупными партиями. eKabini вышел в 2014, соответственно EOL он получит в 2024, и еще пару лет можно жить на старых запасах.
Этот процессор — последний x86, у которого нет «ядра обеспечения безопасности» с подписанным БЛОБом в качестве прошивки и полным отсутсвием документации на него в открытом доступе.
dmitrmax
Про второе я даже и не спорю, такая возможность у вендора будет. Вот только будет ли актуальна такая железка в 2026 году — вопрос. Но я-то имел ввиду первое: обычного юзера-анонимуса. Ему-то как быть? ) Даже если он сегодня возмет Lenovo T500, то этот лэптом сдохнет гораздо раньше 2026. Не говоря о том, что он устареет морально гораздо раньше.
CodeRush
Обычный юзер-анонимус никому не интересен — денег с него взять не получится, т.к. свобода продается очень плохо, а пока ты занимаешься открытием свой платформы, согласованием открытия документации с производителями процессоров, памяти и контролера клавиатуры, конкуренты успевают выпустить две-три линейки продуктов и оставить тебя наедине с устаревшим уже на старте продаж железом и двумя с половиной потенциальными покупателями из числа фанатов свободы и всего такого. Обычный же пользователь и сам добровольно идет в walled garden, и друзей туда тащит, постоянные рекорды продаж Apple — тому ярчайший пример.
dmitrmax
Свобода не продаётся. Свобода только завоёвывается )
JerleShannara
Скажем так. В роли печатной машинки под линуксом, которая может ещё и кино в FullHD показать и музыку послушать даст — оно и в 2026 году будет актуально. Я к примеру условно-терпимо использую hammerhead xrt (P3 900Mhz, 512Mb SDRAM) для просмотра интернета в гараже/на бездорожье. Железке уже более десяти лет, и её условно хватает. Думаю что в 26 году кабини будет примерно такимже
В особо критичных местах (с потолка — контроль чего-нить не сильно жизненно важного на АЭС (да, я в курсе, что все вендоры железа пишут, что низя АЭС/Медецина + наши компоненты)) — тоже актуально будет. Для справки — АМД до сих пор продаёт Geode LX800 пачками — а это пардон что-то уровня первого-второго пентиума по производительности (и с отсутствием пары ассемблерных команд). И оно широко используется в промавтоматике.
CodeRush
И не такое переписывали, и если сильно захотеть — можно в космос полететь, так что за SMU я сильно не переживаю, особенно после вот этой презентации (она же на видео).
С PSP я воюю прямо сейчас на Merlin Falcon, и он меня уже достал. Не могу ничего рассказать толком, NDA, но по сравнению с eKabini, где никаких танцев вокруг PSP не было — жизнь простого инженера стала с ним значительно сложнее, особенно если в его firmware виден баг, а ты даже сделать с этим ничего не можешь, кроме как репортить в AMD и ждать неизвестно сколько, пока в очередном обновлении AGASE/PI это баг не починят.
JerleShannara
Хмм, за ссылочку по SMU спасибо.
dmitrmax
Молодцы ребята. Протолили AMD )