Да мне и AMIBIOS8 хватило, доктор сказал «в морг» — значит в морг.
Люди, которые выше в коментариях пишут про «теплый ламповый простой и отлаженный BIOS» просто не видели, в какую вавилонскую башню из костылей и велосипедов он превратился в конце двухтысячных. Из UEFI я сейчас могу практически безболезненно выкинуть все, к чему у меня не лежит душа. Bosch не устраивает наличие SMM (он мешает работе hard-RTOS) — отключаем. Нам не нравится миллион способов прошивки, а нужно оставить один, но провереный — просто отключаем остальные. Понадобилось заменить чип SuperIO на другой — сменили пару DXE-драйверов и готово.
UEFI — это конструктор LEGO в мире прошивок, и каждый собирает из него то, что считает нужным.
Можно, если очень стараться и все остальное уже и так работает. Многие пользователи Хакинтоша отлаживают свои DSDT и SSDT самостоятельно до состояния Errors 0, Warnings 0, Remarks 0, Info 0, не имея при этом документации, но это все отнимает кучу времени и будет сломано следующим апдейтом БИОСа, а потому разработчикам просто некогда разбираться с ошибками ACPI. Работает — и ладно.
Не просто 16-разрядным, а написанным на ассемблере по большей части. И он больше 20 лет нес с собой груз тогдашних «временных решений» вроде API через прерывания, управления адрессной линией A20, ресетов через порт клавиатуры и работы с таймером 8256. И производители CPU не могли выбросить никому уже не нужный полоработающий 16-разрядный режим потому, что загрузиться станет невозможно.
Да, за эти годы компьютер стал включаться несколько иначе, а с повсеместным внедрением Management Engine — принципиально иначе, только конечному пользователю это не видно и не интересно. И систему, на самом деле, удалось упростить, а не усложнить, вы просто не видели, что творилось внутри какого-нибудь AMIBIOS8 во времена чипсета P55.
По поводу незовможности загрузки альтернативных ОС из коментария ниже — управление ключами доступно, добавляй свои ключи, удаляй стандартные и будь уверен, что на твоей системе не запустится ничего, кроме того, что ты подписал своими руками. А у тех, кто управление ключами пользователю не дает, просто ничего покупать не нужно.
Стоит добавить, что спеку писали законченые наркоманы, а людей, которые могут правильно писать на AML без ошибок, можно по пальцам пересчитать. Более того, примерно 80% AML-кода пишется производителем CPU (которому плевать на warning'и), еще по 10% — IVB и конечным вендором (и будь они хоть кем, их код — капля в море). Да и если большая часть современных ОС на недоработки ACPI все равно плевать хотела (а серьезно пользуется им только OSX), то и отношение к технологии — соответствующее. Пока оно работает хоть как-то — никто ничего трогать не будет, работы хватает и без этого.
Несмотря на вот это все — надежда есть и дело понемногу двигается с мертвой точки. Технологию обязательно обкатают, и лет через 5 у нас будут хорошие и защищенные UEFI-совместимые прошивки, а пока мы имеем то, что имеем, и пытаемся если не совсем избежать удара граблями, то хотя бы надеть каску и приготовить бинты.
Хорошая идея, нажал кнопку — через 30 секунд получил работающую прошивку. Попробую реализовать в одном из следующих проектов, разводка которого еще не закончена.
Именно так, проблема никуда не делась, и скорее всего никуда уже не денется. Жизненный цикл продуктов для массовго рынка — полгода, потом к ним перестают выпускать обновления, ведь нужно разработывать новое поколение продуктов, у которых еще больше фич и еще короче время выхода на рынок. Большая часть ИТ (как и всей остальной индустрии) — пример широко известной в узких кругах экономики говна, исключений там два с половиной и все они работают на индустрию, а не на конечного пользователя.
Системники не понесут, там 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» просто не видели, в какую вавилонскую башню из костылей и велосипедов он превратился в конце двухтысячных. Из UEFI я сейчас могу практически безболезненно выкинуть все, к чему у меня не лежит душа. Bosch не устраивает наличие SMM (он мешает работе hard-RTOS) — отключаем. Нам не нравится миллион способов прошивки, а нужно оставить один, но провереный — просто отключаем остальные. Понадобилось заменить чип SuperIO на другой — сменили пару DXE-драйверов и готово.
UEFI — это конструктор LEGO в мире прошивок, и каждый собирает из него то, что считает нужным.
Да, за эти годы компьютер стал включаться несколько иначе, а с повсеместным внедрением Management Engine — принципиально иначе, только конечному пользователю это не видно и не интересно. И систему, на самом деле, удалось упростить, а не усложнить, вы просто не видели, что творилось внутри какого-нибудь AMIBIOS8 во времена чипсета P55.
По поводу незовможности загрузки альтернативных ОС из коментария ниже — управление ключами доступно, добавляй свои ключи, удаляй стандартные и будь уверен, что на твоей системе не запустится ничего, кроме того, что ты подписал своими руками. А у тех, кто управление ключами пользователю не дает, просто ничего покупать не нужно.
Системники не понесут, там 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 кб.