Именно так, проблема никуда не делась, и скорее всего никуда уже не денется. Жизненный цикл продуктов для массовго рынка — полгода, потом к ним перестают выпускать обновления, ведь нужно разработывать новое поколение продуктов, у которых еще больше фич и еще короче время выхода на рынок. Большая часть ИТ (как и всей остальной индустрии) — пример широко известной в узких кругах экономики говна, исключений там два с половиной и все они работают на индустрию, а не на конечного пользователя.
Системники не понесут, там AMI Aptio, который от разваливания NVRAM намертво не ломается (ну подумаешь настройки перестают сохранятся, но в них все равно ведь никто не лезет...), а вот ноутбуки — еще как, так что без хорошего программатора (рекомендую Dediprog SF-600, но можно взять и MiniPro TL866A, он подешевле) восстаналивать эту гору ноутбуков будет весьма непросто.
Можно, и уже ваяют. Я пока не слышал об успешных атаках, устроенных вредоносным кодом, но это вовсе не означает, что их не было или не будет. Обязательно будут. В данный момент безопасность прошивок большинства находящихся на рынке машин — околонулевая, а некоторые вендоры до сих пор позволяют прошивать любые образы БИОСа без валидации прямо из ОС (привет Asrock и EVGA), а это даже не дыра в безопасности — это просто открытая дверь для кода, который хочет добавить себя в БИОС. По моей скромной оценке, примерно на 98% ПК с UEFI на данный момент существует минимум одна незакрытая уязвимость, позволяющая добавить свой код в БИОС и получить управление до загрузки ОС. Остальные два — системы с включенным BootGuard, на которых вместо этого получится DoS, т.е. после прошивки система просто перестанет рабоать.
«Please, please, please, go apply patches!» Xeno Kovah @ CanSecWest2015
Концепция там нормальная, как раз, но как всегда, «гладко было на бумаге».
BIOS изнутри устроен еще хуже, и под занавес его разработка стала настолько сложной и дорогой, а требования настолько противоречивыми, что без UEFI (а другого стандарта такого уровня просто не было) все равно было не обойтись.
Проблема там в основном в том, что внедрение UEFI и PI (Platform Interface, стандарт нижнего уровня прошивки) упростило разработку компонентов прошивки примерно на порядок засчет перехода с ассемблера на С и использования стандартных компиляторов/сборщиков/отладчиков/утилит вместо специализированных. А это, в свою очередь, резко упростило и удешевило добавление в прошивку компонентов, которые раньше пихать туда было дорого и велик был риск не вылезти из отладки. В результате имеем половину OpenSSL в составе CryptoPkg, половину сетевого стека из FreeBSD в составе NetworkPkg, поддержку PNG и OpenGL в BIOS Setup и прочий цирк с конями. А т.к. цирк и кони хорошо продаются простому пользователю, то все силы IBV и конечные вендоры бросили именно на них, в итоге фичи уже не влезают в 16 Мб флеша, а баги висят незакрытыми годами. Хуже всего еще и то, что про безопасность задумались более или менее серьезно только в этом году, и до сих пор 95% процентов прошивок — решето такое, что можно вермишель просеивать, но про это я не имею права рассказывать, читайте сами вот тут.
Емкости, зачастую, хватило бы и так, тут не хватает мотивации одним и умения другим.
Дело в том, что PC firmware (BIOS или UEFI — не важно) разрабатывался и разрабатывается по следующей схеме:
CPU Vendor -> BIOS Vendor -> System Vendor. Разработчик процессора (в нашем UEFI'шном случае это Intel, AMD или ARM) пишет код низкоуровневой инициализации поставляемых им компонентов — процессора, чипсета, контролера памяти, контролера PCI(e), контролера USB и т.п. и предоставляет этот «скелет» разработчику платформы (обычно таких разработчиков называют IBV aka Independent BIOS Vendor, самые известные — AMI, Phoenix, Insyde). Затем IBV наращивает на «скелете» разного рода «мясо» (т.е. фичи вроде CSM, BIOS Setup, загрузчик, ACPI, и т.д.) и предоставляет так называемый full-featured reference platform BIOS, работающий на референсной же плате от разработчика процессора, называемой CRB aka Customer Reference Board. Затем производители железа вроде ASUS и Gigabyte покупают вот эту самую CRB у производителя CPU и вот этот самый BIOS у IBV и адаптируют и то, и другое под свои условия, добавляя драйверы для собственных устройств, свой AML-код и свои картинки на фон в BIOS Setup.
В результате получается, что производитель CPU отвечает только за свои собственные низкоуровневые компоненты и ему вообще не важно, как устроен NVRAM, если ли баги в работе с ним или нет и где он физически находится. Код инициализации либо не использует NVRAM вообще, либо использует только для чтения/записи временных (non-volatile) или мелких, доступных только коду UEFI, BS-переменных, и если БИОС дошел до загрузки ОС вообще, то эта часть кода работы с NVRAM отлажена и функционирует нормально.
IVB тоже не слишком важно, что там устроено и как, их задача — выкатить работающий референсный BIOS. Никто его толком не тестирует, и многого от него тоже никто не ждет, т.к. CRB сама по себе работает нестабильно и нагрузочного тестирования на ней никто не проводит — это задача конечного вендора. Часть кода берется из TianoCore, часть дописыватся тут же, часть наскивается из других похожих проектов, в итоге получается лоскутное одеяло, которое криво-косо, но работает на CRB, а больше от него ничего и не надо — вендоры сами разбируться, это их работа.
Конечный же вендор стремится минимизировать издержки и ускорить выход продукта на рынок, а потому вообще не лезет в код, написаный на предыдущих этапах, если этот код хоть как-то работает, у него хватает проблем с адаптацией тех кусков кода, которые работать упрямо отказываются, а должны еще вчера. В результате такого подхода куча решений из серии «это костыль, уберем в следующем коммите» и «работает и хай так» не только оказываются в продакшене, но и живут там до самой смерти платы. Архитектуру менять некому и некогда, т.к. никто в дополнительной работе без каких-либо дивидендов не заинтересован.
Все проблемы от того, что опять смешали код и данные.
NVRAM не место в той же микросхеме, в которой находится исполняемый код, и важнейшим системным приложениям вроде BIOS Setup и BIOS Update не место среди переменных BootXXXX. Неработоспособность их вызвана тем, что в реализациях Phoenix SCT и Insyde H2O все функции, вызываемые с POST-экрана горячими клавишами — всего лишь очередные «загрузочные устройства», прописанные в NVRAM, и потому при нарушении работы NVRAM они тоже перестают работать. Этому багу почти 5 лет и на некоторых новых ноутбуках он по прежнему присуствует. И повезло еще, что хоть что-то загрузочное осталось, иногда бывает так, что какой-нибудь efibootmgr сносит вообще все переменные BootXXXX, и система после перезагрузки показывает только черный экран.
Самая правильная реализация работы с NVRAM в данный момент у AMI. У них отдельно хранится слепок настроек по умолчанию, которые будут скопированны поверх NVRAM в случае, если с ним случилось что-то непоправимое, а системные функции вроде BIOS Setup вызываются из приложения, которое стартует всегда и запуск которого не зависит от состояния NVRAM вообще.
Тем не менее, сама идея NVRAM на той же микросхеме, что и исполняемый код — порочна по сути. Постараюсь в одном из проектов вместо установки одного чипа на 16 мб поставить два по 8 и на первый перенести все регионы, запись в которые нужна при работе системы (GbE, ME, NVRAM), а на вторую записать прошивку и защитить весь чип от записи переключателем SPI_WP. Нужно обновлять прошивку — выключил защиту, обновил из BIOS Setup, включил назад. И никаких танцев с криптографией и защитой пользователя от самого себя. Да, это больше работы по адаптации, но овчинка стоит выделки, на мой взгляд.
Так говорят все, а те, кто специально старается так не говорить, все равно иногда говорят случайно, просто потому, что некоторые немецкие слова ёмче, чем соотвествующие русские. Будь ты хоть дважды доктор и трижды профессор, но слово Termin ты сразу заберешь в свой русский язык, просто потому, что оно очень емкое и удобное. Я стараюсь держать русский язык в чистоте, но все равно немецкие слова проскакивают без моего участия, а для некоторых слов я уже не могу подобрать подходящее русское вообще, Drachenfutter, к примеру, или Stubenhocker.
Если такие еще есть, то покупать у них системы я крайне не советую.
Если вы пока не слышали о случаях заражения открытого на запись БИОСа — я уверен на 500%, что еще услышите.
Могу ответить за Lenovo: никогда, никогда.
Проверенные и перепроверенные сообществом реализации работают нормально (хотя бы на уровне full hardware support, а это вовсе не главное требование к BIOS'у, но и его силами сообщества реализовать очень сложно) на двух с половиной платах, и потому для коммерческого (а тем более серверного) использования они непригодны. У нас был внутренний проект по использованию coreboot в качестве прошивки и закончился он полным отказом от дальнейших планов. Пока за coreboot не будет стоять кто-то вроде RedHat или IBM с возможностью купить support plan и не оставаться наедине с исходниками, написанными сообществом — желающих окунуться в мир отрытых прошивок будет примерно столько же, сколько и сейчас.
Возможность прошиваться flashrom'ом автоматически означает открытость прошивки на запись средствами ОС без какой-либо проверки, что позволяет получившему рута коду прошить себя в БИОС, обосноваться в SMM и управлять оттуда всей системой. Даже на десктопах уже года два как перестали БИОС на запись открывать, а на сервере делать так — преступление.
В стандарт UEFI 2.5, который выйдет в следующем месяце, внесены изменения, позволяющие ОС запросить у прошивки версии ее компонентов и обновить их во время загрузки системы. Файлы с обновлениями должны быть подписаны вендорской ЭЦП, а сама прошивка выполняется в изолированном pre-boot-окружении и не зависит от ОС и тех, кто получил в ней рута. Этот же механизм может использоваться системами patch management (MS обещает добавить поддержку в Windows Update), чтобы обновлять прошивку своевременно и как можно быстрее закрывать обнаруженные уязвимости. Поддержка этой новой технологии в Linux уже добавлена ребятами из проекта Fedora, я работал с тестовой версией и остался вполне доволен и реализацией, и подходом. Это в разы лучше, чем кривые вендорские WIN/DOS-only утилиты, которые используются для обновления прошивков на большинстве плат в данный момент.
Кардинальные изменения тоже не помогут, т.к. в Lenovo прошивку не разрабатывают, а дорабатывают.
Насколько мне не изменяет память, код UEFI они покупают у Insyde, которая, в свою очеред покупает у Intel код инициализации платформы (процессора и чипсета), добавляет туда свою реализацию Setup и свои фичи, адаптирует под одну из версий Customer Reference Board. Lenovo покупает у Intel вышеупомяную CRB, а у Insyde — референсный BIOS для нее, который и адаптирует для своих конкретныъ плат с теми же процессором и чипсетом, что и на CRB.
В итоге, чтобы открыть хоть какой-то код кроме пары никому не нужных DXE-драйверов для SuperIO, Lenovo понадобится громадное количество работы с юристами Insyde и Intel, неизвестное количество денег (несколько десятков миллионов долларов, по моей грубой оценке) и масса работы, чтобы на выходе получить открытый BIOS, который устареет через полгода с выходом новых CPU.
На данный момент открыть UEFI могут себе позволить только Intel и AMD, и это тоже будет стоить очень дорого и при непонтяной для них выгоде. Единственный способ иметь полностью открытые прошивки — разрабатывать полностью открытое оборудование, не требующее для инициализации никакой хитрой магии и для запуска которого достаточно coreboot или uBoot. Понятно, Windows на таком не запустится, да и от Intel/AMD отставание технологическое будет на 10-15 лет, но пока никакой другой альтернативы проприетарным прошивкам я не вижу.
Как разработчик UEFI скажу прямо: открытие кода прошивки ведет только к его улучшению, но никто, кроме Intel и AMD позволить себе этото самое открытие не может — слишком много информации о железе нужно будет выводить из под NDA.
Ребята из coreboot/libreboot проделывают кучу работы по реверс-инженирингу инициализации чипсета (которая не очень сложна и довольно просто устроена), но даже они используют блобы ME и VideoBIOS из оригинальной прошивки, т.к. без них система просто не работает и сделать с этим без помощи Intel ничего нельзя.
Наиболее открытый UEFI сейчас у Intel Galileo, но и там имеется пара блобов, а в так называемом «открытом» UEFI для Minnowboard Max на «нормальном» процессоре Intel Atom уже блобов больше, чем отрытого кода.
Пока Lenovo не начнет делать свои собственные процессоры, никакого открытия кода от них можно не ждать.
У AMD только на SoC'ах, да, а у Intel давно уже по паре UART'ов имееся в чипсете (даташит, 2.17).
Я писал без кэша на ассемблере (в том числе и для x86-64) и тоже скажу, что веселого там мало, но у меня хотя-бы код полностью контролируется мной и не нужно вызывать ничего внешнего.
С тезисом про ржание согласен как никто. Иногда приходится биться неделями над проблемами, о которых большинство авторов подобных статей типа «компьютеры и ОС — это очень просто» даже не слышало никогда, и потому утверждает, что их не существует.
Про процесс загрузки UEFI обзорно я писал уже однажды, но без деталей.
Если писать на С, а не на ассемблере, то нужен стек и сколько-то памяти еще до инициализации RAM. В таком качестве можно использовать кэш L2, переключив его в No-Eviction Mode и запретив компилятору его сбрасывать.
У современных чипсетов есть собственные UART, поэтому можно обойтись без LPC и SuperIO на данном этапе, загружаться можно попробовать с чего-то попроще, чем SATA, с SD-карты, к примеру, несколько каналов SPI тоже есть у почти всех современных чипсетов. Вот тут несколько интеловских инженеров показывают, как можно ценой выбрасывания почти всего добиться UEFI-загрузки Yocto Linux на Intel Quark прошивкой размером в 64 кб.
Intel'овские документы серии Platform BIOS Writer's Guide, в которых описываются последовательности инициализации процессора и чипсета, редко бывают меньше 600 страниц. Плюс даташиты на CPU, PCH, EC, HWM, LAN, HDA, TPM и SuperIO, плюс схема платы с пояснениями, там только чтения документации на несколько недель вообще без какого-либо кода, если с нуля все писать.
BIOS, который найдет диск и загрузит 512 байт в память прост. Если бы я знал спецификацию на мою материнскую плату я бы написал его за несколько часов.
Если это так, то я могу прямо тут расписаться в полной свой профнепригодности и ехать собирать бананы в Африку, ибо по всему выходит, что как разработчик прошивок я никуда не годен.
Если серьезно, на средний по сложности проект адаптации BIOSа для CRB под конкретную плату уходит в среднем от 3 до 6 месяцев, и первые пару недель не грузится вообще ничего дальше начальной инициализации RAM, а иногда перестает работать еще раньше. Когда плата смогла загрузить хотя бы DOS — устраевается Boot-Party с шампанским и сладостями во всем отделе RnD, ибо это результат огромного количества работы практически всего отдела. А тут обещают управиться за несколько часов, блин.
Нет в современных ПК вообще ничего простого, даже чтобы UART завести нужна математика с пределителями, а чтобы завести RAM или PEG Gen3 нужна либо куча кода от производителя платформы, либо документация и несколько месяцев работы на полный день.
Более того, кто-то их реально сканировал хоть раз с рекламной площади?
QR-код — это ярчайший представитель M2M-интерфейсов, а вы предлагаете его постить крупно вместо ссылок. Кодируйте тогда уже все содержимое рекламы в QR-код, чего мелочиться то, заодно и города от вычурной рекламы избавите, пока не появятся терминаторы, способные распознавать коды находу. Вот на них, видимо, продукт и рассчитан.
Нужна ли конечному пользователю интернационализация, которая в UEFI из коробки? Возможность запуска ОС без загрузчика? Нормально реализованные Option ROMы, которым не приходится сражаться за место в legacy region C-F? GOP в конце концов, позволяющий использовать UEFI-драйвер графической подсистемы в любой даже самой примитивной ОС?
Если считать обычным пользователем человека, которому от БИОСа требуется, чтобы его ОС загрузилась и побыстрее — вообще никакой разницы между legacy BIOS, UEFI, FSP, OpenBIOS, coreboot, libreboot и остальными нет. Но дьявол прячется в деталях, как всегда.
Я не согласен с тем, что UEFI — это «рефакторинг» BIOSа, от которого там не осталось вообще ничего. Это новая реализация на основе новых идей, своего рода «вторая система». Да, теперь приходится эмулировать старое поведение при помощи некоторого числа хаков, но переходный период закончится через 5-7 лет, и можно будет начать пользоваться преимуществами UEFI без постоянной оглядки на совместимость.
Меня поражает такое отношение к UEFI. Разработчики умудрились унифицировать интерфейс прошивки, выпустить почти 70% от нее в открытом виде (проект TianoCore), выпустить открытую же спецификацию и средства разработки, и саму разработку упростить примерно впятеро, а простой пользователь все еще думает, что это рассадник вирусов и в нем нет ничего хорошего, кроме GPT.
Как избежать заражения — использовать SecureBoot и HW root-of-trust вроде Intel BootGuard и AMD/ARM TrustZone, которые уже сейчас вполне готовы к применению и два года не надо ждать. Есть, конечно, и обратная сторона — никаких больше модификаций оригинального БИОСа не сделать, и белый список оборудования не открутить, и расширенное меню не открыть, и прошивку на coreboot не сменить, свободу конечного пользователя снова ограничили ради безопасности теми самыми code signing и vendor lock-in.
Могу еще порекомендовать HT editor, который намного попроще, зато радует знакомым с детства интерфейсом.
Меня на radare2 навел один из его разработчиков, xvilka, и проект мне понравился, и хотя его интерфейс по умолчанию писали любители vim, но это его не портит. Очень жду, когда допилят Bokken до приличного состояния, и можно понемногу уходить с IDA в сторону открытых решений, а то уж больно дорого стоит нынче ее лицензия.
Системники не понесут, там AMI Aptio, который от разваливания NVRAM намертво не ломается (ну подумаешь настройки перестают сохранятся, но в них все равно ведь никто не лезет...), а вот ноутбуки — еще как, так что без хорошего программатора (рекомендую Dediprog SF-600, но можно взять и MiniPro TL866A, он подешевле) восстаналивать эту гору ноутбуков будет весьма непросто.
«Please, please, please, go apply patches!» Xeno Kovah @ CanSecWest2015
BIOS изнутри устроен еще хуже, и под занавес его разработка стала настолько сложной и дорогой, а требования настолько противоречивыми, что без UEFI (а другого стандарта такого уровня просто не было) все равно было не обойтись.
Проблема там в основном в том, что внедрение UEFI и PI (Platform Interface, стандарт нижнего уровня прошивки) упростило разработку компонентов прошивки примерно на порядок засчет перехода с ассемблера на С и использования стандартных компиляторов/сборщиков/отладчиков/утилит вместо специализированных. А это, в свою очередь, резко упростило и удешевило добавление в прошивку компонентов, которые раньше пихать туда было дорого и велик был риск не вылезти из отладки. В результате имеем половину OpenSSL в составе CryptoPkg, половину сетевого стека из FreeBSD в составе NetworkPkg, поддержку PNG и OpenGL в BIOS Setup и прочий цирк с конями. А т.к. цирк и кони хорошо продаются простому пользователю, то все силы IBV и конечные вендоры бросили именно на них, в итоге фичи уже не влезают в 16 Мб флеша, а баги висят незакрытыми годами. Хуже всего еще и то, что про безопасность задумались более или менее серьезно только в этом году, и до сих пор 95% процентов прошивок — решето такое, что можно вермишель просеивать, но про это я не имею права рассказывать, читайте сами вот тут.
Дело в том, что PC firmware (BIOS или UEFI — не важно) разрабатывался и разрабатывается по следующей схеме:
CPU Vendor -> BIOS Vendor -> System Vendor. Разработчик процессора (в нашем UEFI'шном случае это Intel, AMD или ARM) пишет код низкоуровневой инициализации поставляемых им компонентов — процессора, чипсета, контролера памяти, контролера PCI(e), контролера USB и т.п. и предоставляет этот «скелет» разработчику платформы (обычно таких разработчиков называют IBV aka Independent BIOS Vendor, самые известные — AMI, Phoenix, Insyde). Затем IBV наращивает на «скелете» разного рода «мясо» (т.е. фичи вроде CSM, BIOS Setup, загрузчик, ACPI, и т.д.) и предоставляет так называемый full-featured reference platform BIOS, работающий на референсной же плате от разработчика процессора, называемой CRB aka Customer Reference Board. Затем производители железа вроде ASUS и Gigabyte покупают вот эту самую CRB у производителя CPU и вот этот самый BIOS у IBV и адаптируют и то, и другое под свои условия, добавляя драйверы для собственных устройств, свой AML-код и свои картинки на фон в BIOS Setup.
В результате получается, что производитель CPU отвечает только за свои собственные низкоуровневые компоненты и ему вообще не важно, как устроен NVRAM, если ли баги в работе с ним или нет и где он физически находится. Код инициализации либо не использует NVRAM вообще, либо использует только для чтения/записи временных (non-volatile) или мелких, доступных только коду UEFI, BS-переменных, и если БИОС дошел до загрузки ОС вообще, то эта часть кода работы с NVRAM отлажена и функционирует нормально.
IVB тоже не слишком важно, что там устроено и как, их задача — выкатить работающий референсный BIOS. Никто его толком не тестирует, и многого от него тоже никто не ждет, т.к. CRB сама по себе работает нестабильно и нагрузочного тестирования на ней никто не проводит — это задача конечного вендора. Часть кода берется из TianoCore, часть дописыватся тут же, часть наскивается из других похожих проектов, в итоге получается лоскутное одеяло, которое криво-косо, но работает на CRB, а больше от него ничего и не надо — вендоры сами разбируться, это их работа.
Конечный же вендор стремится минимизировать издержки и ускорить выход продукта на рынок, а потому вообще не лезет в код, написаный на предыдущих этапах, если этот код хоть как-то работает, у него хватает проблем с адаптацией тех кусков кода, которые работать упрямо отказываются, а должны еще вчера. В результате такого подхода куча решений из серии «это костыль, уберем в следующем коммите» и «работает и хай так» не только оказываются в продакшене, но и живут там до самой смерти платы. Архитектуру менять некому и некогда, т.к. никто в дополнительной работе без каких-либо дивидендов не заинтересован.
NVRAM не место в той же микросхеме, в которой находится исполняемый код, и важнейшим системным приложениям вроде BIOS Setup и BIOS Update не место среди переменных BootXXXX. Неработоспособность их вызвана тем, что в реализациях Phoenix SCT и Insyde H2O все функции, вызываемые с POST-экрана горячими клавишами — всего лишь очередные «загрузочные устройства», прописанные в NVRAM, и потому при нарушении работы NVRAM они тоже перестают работать. Этому багу почти 5 лет и на некоторых новых ноутбуках он по прежнему присуствует. И повезло еще, что хоть что-то загрузочное осталось, иногда бывает так, что какой-нибудь efibootmgr сносит вообще все переменные BootXXXX, и система после перезагрузки показывает только черный экран.
Самая правильная реализация работы с NVRAM в данный момент у AMI. У них отдельно хранится слепок настроек по умолчанию, которые будут скопированны поверх NVRAM в случае, если с ним случилось что-то непоправимое, а системные функции вроде BIOS Setup вызываются из приложения, которое стартует всегда и запуск которого не зависит от состояния NVRAM вообще.
Тем не менее, сама идея NVRAM на той же микросхеме, что и исполняемый код — порочна по сути. Постараюсь в одном из проектов вместо установки одного чипа на 16 мб поставить два по 8 и на первый перенести все регионы, запись в которые нужна при работе системы (GbE, ME, NVRAM), а на вторую записать прошивку и защитить весь чип от записи переключателем SPI_WP. Нужно обновлять прошивку — выключил защиту, обновил из BIOS Setup, включил назад. И никаких танцев с криптографией и защитой пользователя от самого себя. Да, это больше работы по адаптации, но овчинка стоит выделки, на мой взгляд.
Если вы пока не слышали о случаях заражения открытого на запись БИОСа — я уверен на 500%, что еще услышите.
Проверенные и перепроверенные сообществом реализации работают нормально (хотя бы на уровне full hardware support, а это вовсе не главное требование к BIOS'у, но и его силами сообщества реализовать очень сложно) на двух с половиной платах, и потому для коммерческого (а тем более серверного) использования они непригодны. У нас был внутренний проект по использованию coreboot в качестве прошивки и закончился он полным отказом от дальнейших планов. Пока за coreboot не будет стоять кто-то вроде RedHat или IBM с возможностью купить support plan и не оставаться наедине с исходниками, написанными сообществом — желающих окунуться в мир отрытых прошивок будет примерно столько же, сколько и сейчас.
Возможность прошиваться flashrom'ом автоматически означает открытость прошивки на запись средствами ОС без какой-либо проверки, что позволяет получившему рута коду прошить себя в БИОС, обосноваться в SMM и управлять оттуда всей системой. Даже на десктопах уже года два как перестали БИОС на запись открывать, а на сервере делать так — преступление.
В стандарт UEFI 2.5, который выйдет в следующем месяце, внесены изменения, позволяющие ОС запросить у прошивки версии ее компонентов и обновить их во время загрузки системы. Файлы с обновлениями должны быть подписаны вендорской ЭЦП, а сама прошивка выполняется в изолированном pre-boot-окружении и не зависит от ОС и тех, кто получил в ней рута. Этот же механизм может использоваться системами patch management (MS обещает добавить поддержку в Windows Update), чтобы обновлять прошивку своевременно и как можно быстрее закрывать обнаруженные уязвимости. Поддержка этой новой технологии в Linux уже добавлена ребятами из проекта Fedora, я работал с тестовой версией и остался вполне доволен и реализацией, и подходом. Это в разы лучше, чем кривые вендорские WIN/DOS-only утилиты, которые используются для обновления прошивков на большинстве плат в данный момент.
Насколько мне не изменяет память, код UEFI они покупают у Insyde, которая, в свою очеред покупает у Intel код инициализации платформы (процессора и чипсета), добавляет туда свою реализацию Setup и свои фичи, адаптирует под одну из версий Customer Reference Board. Lenovo покупает у Intel вышеупомяную CRB, а у Insyde — референсный BIOS для нее, который и адаптирует для своих конкретныъ плат с теми же процессором и чипсетом, что и на CRB.
В итоге, чтобы открыть хоть какой-то код кроме пары никому не нужных DXE-драйверов для SuperIO, Lenovo понадобится громадное количество работы с юристами Insyde и Intel, неизвестное количество денег (несколько десятков миллионов долларов, по моей грубой оценке) и масса работы, чтобы на выходе получить открытый BIOS, который устареет через полгода с выходом новых CPU.
На данный момент открыть UEFI могут себе позволить только Intel и AMD, и это тоже будет стоить очень дорого и при непонтяной для них выгоде. Единственный способ иметь полностью открытые прошивки — разрабатывать полностью открытое оборудование, не требующее для инициализации никакой хитрой магии и для запуска которого достаточно coreboot или uBoot. Понятно, Windows на таком не запустится, да и от Intel/AMD отставание технологическое будет на 10-15 лет, но пока никакой другой альтернативы проприетарным прошивкам я не вижу.
Ребята из coreboot/libreboot проделывают кучу работы по реверс-инженирингу инициализации чипсета (которая не очень сложна и довольно просто устроена), но даже они используют блобы ME и VideoBIOS из оригинальной прошивки, т.к. без них система просто не работает и сделать с этим без помощи Intel ничего нельзя.
Наиболее открытый UEFI сейчас у Intel Galileo, но и там имеется пара блобов, а в так называемом «открытом» UEFI для Minnowboard Max на «нормальном» процессоре Intel Atom уже блобов больше, чем отрытого кода.
Пока Lenovo не начнет делать свои собственные процессоры, никакого открытия кода от них можно не ждать.
Я писал без кэша на ассемблере (в том числе и для x86-64) и тоже скажу, что веселого там мало, но у меня хотя-бы код полностью контролируется мной и не нужно вызывать ничего внешнего.
С тезисом про ржание согласен как никто. Иногда приходится биться неделями над проблемами, о которых большинство авторов подобных статей типа «компьютеры и ОС — это очень просто» даже не слышало никогда, и потому утверждает, что их не существует.
Если писать на С, а не на ассемблере, то нужен стек и сколько-то памяти еще до инициализации RAM. В таком качестве можно использовать кэш L2, переключив его в No-Eviction Mode и запретив компилятору его сбрасывать.
У современных чипсетов есть собственные UART, поэтому можно обойтись без LPC и SuperIO на данном этапе, загружаться можно попробовать с чего-то попроще, чем SATA, с SD-карты, к примеру, несколько каналов SPI тоже есть у почти всех современных чипсетов.
Вот тут несколько интеловских инженеров показывают, как можно ценой выбрасывания почти всего добиться UEFI-загрузки Yocto Linux на Intel Quark прошивкой размером в 64 кб.
Если это так, то я могу прямо тут расписаться в полной свой профнепригодности и ехать собирать бананы в Африку, ибо по всему выходит, что как разработчик прошивок я никуда не годен.
Если серьезно, на средний по сложности проект адаптации BIOSа для CRB под конкретную плату уходит в среднем от 3 до 6 месяцев, и первые пару недель не грузится вообще ничего дальше начальной инициализации RAM, а иногда перестает работать еще раньше. Когда плата смогла загрузить хотя бы DOS — устраевается Boot-Party с шампанским и сладостями во всем отделе RnD, ибо это результат огромного количества работы практически всего отдела. А тут обещают управиться за несколько часов, блин.
Нет в современных ПК вообще ничего простого, даже чтобы UART завести нужна математика с пределителями, а чтобы завести RAM или PEG Gen3 нужна либо куча кода от производителя платформы, либо документация и несколько месяцев работы на полный день.
QR-код — это ярчайший представитель M2M-интерфейсов, а вы предлагаете его постить крупно вместо ссылок. Кодируйте тогда уже все содержимое рекламы в QR-код, чего мелочиться то, заодно и города от вычурной рекламы избавите, пока не появятся терминаторы, способные распознавать коды находу. Вот на них, видимо, продукт и рассчитан.
Если считать обычным пользователем человека, которому от БИОСа требуется, чтобы его ОС загрузилась и побыстрее — вообще никакой разницы между legacy BIOS, UEFI, FSP, OpenBIOS, coreboot, libreboot и остальными нет. Но дьявол прячется в деталях, как всегда.
Я не согласен с тем, что UEFI — это «рефакторинг» BIOSа, от которого там не осталось вообще ничего. Это новая реализация на основе новых идей, своего рода «вторая система». Да, теперь приходится эмулировать старое поведение при помощи некоторого числа хаков, но переходный период закончится через 5-7 лет, и можно будет начать пользоваться преимуществами UEFI без постоянной оглядки на совместимость.
Как избежать заражения — использовать SecureBoot и HW root-of-trust вроде Intel BootGuard и AMD/ARM TrustZone, которые уже сейчас вполне готовы к применению и два года не надо ждать. Есть, конечно, и обратная сторона — никаких больше модификаций оригинального БИОСа не сделать, и белый список оборудования не открутить, и расширенное меню не открыть, и прошивку на coreboot не сменить, свободу конечного пользователя снова ограничили ради безопасности теми самыми code signing и vendor lock-in.
На фото — либо Regional Express, либо какой-то из Regional Bahn'ов.
Меня на radare2 навел один из его разработчиков, xvilka, и проект мне понравился, и хотя его интерфейс по умолчанию писали любители vim, но это его не портит. Очень жду, когда допилят Bokken до приличного состояния, и можно понемногу уходить с IDA в сторону открытых решений, а то уж больно дорого стоит нынче ее лицензия.