В наличии с сайта производителя или отдельно (нужно будет включить kext-dev-mode в 10.10), упомянутые в статье утилиты ch341* должны собираться и работать и в OSX, но я этот момент не проверял.
Можно попробовать TinyBitBang, но в ней I2C реализован через ногодрыг, и потом работает медленнее, чем аппаратные реализации, но зато даже на FT232RL и прочих копеечных FTDI'шках без MPSSE.
Пропустил статью, пока был в отпуске, наверстываю. Есть SMM и на Atom, и на Quark, ибо кое-где он реально нужен. Используется SMM для эмуляции legacy USB, поддержки USB-клавиатур и мышей в DOS, обновления компонентов прошивки (доступ к SPI flash возможен только из SMM при правильной реализации защиты прошивки от переписывания вредоносным кодом), эмуляции отсутствующих и исправления неверно реализованных IO-портов (т.н. IO Trap), иногда используется для независимого от ОС управления сложной периферией вроде EC. Если это все не нужно, зато нужен риалтайм — SMM можно отключить полностью, для этого достаточно посадить линию SMI# процессора на землю, снять все биты регистра SMI_EN (отключив таким образом все источники программных SMI) и поставить бит SMI_LOCK, чтобы злоумышленник не смог включить все обратно. У нас есть разработанные по заказу Bosch варианты наших плат с уменьшенными задержками, отключенным энергосбережением и управлением питанием, полностью отключенным SMM и другими мелкими изменениями, помогающими использовать RTOS на x86.
Потому, что для UEFI закрытый код инициализации памяти и чипсета поставляется в составе платформы AMI Aptio, доступ к которой у нас имеется, а в случае coreboot инициализацию выполняет открытый код, написанный сообществом в результате реверс-инжениринга и потому не всегда работающий правильно. Да и избавиться от проприетарных компонентов не получится даже с coreboot, все равно нужны и ME, и VBIOS, на использование которых все равно придется купить у Intel лицензию.
Не думаю. Если реализаций не появится — ненужные части просто выкинут, как это уже случилось с «хвостатыми» файлами в при переходе с FV Rev1 к FV Rev2. Наличие стандарта (даже если он всеобъемлющий и непонятный) гарантирует интероперабельность при условии, что реализации следуют букве этого самого стандарта. На данный момент в реализациях UEFI 2.4 замечательно работают драйверы, написанные для EFI 1.01, хотя их и рекомендуется переписать под новую Driver Model, чтобы они были меньше и загружались быстрее. EFI-приложения, не использующие вендорские расширения, запускаются и работают на реализациях UEFI любого производителя (проверял лично на реализациях AMI, Phoenix, Insyde и Intel). С пониманием там тоже не должно быть больших проблем, я думаю. Да, стандарт достаточно объемный, но основные идеи (как устроены драйверы, что такое протоколы, как вызвать общий код, как сохранить свои данные и т.п) намного проще, чем интерфейс через прерывания и IO-порты, которым грешил legacy BIOS.
Мне тоже не нравится тот факт, что фичи постоянно добавляют, а баги в реализациях чинят не очень резво, но сделать с этим фактом я могу только одно — не пихать в свои БИОСы бездумно все подряд, до чего появился доступ, ведь чем меньше кода в прошивке, тем там меньше багов. К сожалению, такое мнение среди «обычных пользователей» не слишком популярно, им нужен графический Setup с красивой картинкой на фоне и прочий stuff. И загрузка чтобы без PXE-костылей. И дуалбут в Android. И черта в ступе еще. Пока такой подход позволяет продать больше плат, чем конкуренты — процесс добавления фич не остановить.
UEFI — это пока еще не ОС в привычном понимании термина, это скорее очень продвинутый аналог HAL. На ОС становится похожа его комбинация с UEFI Shell, вот её уже можно назвать однозадачной дисковой ОС с прямым доступом к ресурсам, таким себе новым DOS без костылей времен Очакова.
Добавление загрузки по HTTP объяснимо и ожидаемо, ведь хоть какой-нибудь HTTP-сервер имеется почти в каждой внутренней сети, и просто положить в /boot/bootx64.efi файл с загрузчиком намного проще, чем поднимать TFTP-сервер, настраивать специальным образом DHCP так, чтобы от отвечал на PXE-запросы и собрать загрузчик для 16-битного реального режима, не забыв проследить, чтобы его размер не превысил доступные 0x20000 байт.
Туда он свернул или не туда — посмотрим лет через 10-15, сейчас же в каждом новом стандарте просто добавляют очередную нужную фичу, показавшуюся полезной участникам UEFI Forum. К счастью, большая часть этих фич не является обязательно к реализации, и некоторые «темные углы» стандарта EFI 1.01 так и не реализованы до сих пор. UEFI хорош тем, что если какая-то его часть мне особенно не нравится — я ее просто не собираю и все. К примеру, мне не нравится стандартный механизм Capsule Update, и в моих реализация функциих UpdateCapsule и QueryCapsuleCapabilities просто возвращают EFI_UNSUPPORTED. Кому-то не нравится SMM, кому-то другому — RW и RO-данные в одной микросхеме, но все эти вопросы решаемые и разные части стандарта не приколочены друг к другу намертво. UEFI похож на конструктор, каждый собирает из него то, что считает нужным.
Сложно сравнивать, это проекты разных весовых категорий. С одной стороны у нас UEFI Forum из Intel/AMD/MS/HP/Dell/etc., а с другой — небольшая группа энтузиастов и примкнувший к ним Google, использующий coreboot на Chromebook. Для UEFI есть «раздутый и чрезмерно усложненный», но открытый стандарт, документация, бесплатные инструменты для проверки на соответсвие реализации стандарту, открытый SDK и т.п., для coreboot есть только код, немного документации, немного вики-страниц с coreboot.org и громадный mailing list. Более того, coreboot, по сути, отвечает только за очень раннюю инициализацию системы, это аналог PEI в UEFI, а все остальное предлагается делать через payload, которым может быть либо ядро ОС (как у Google, если нужен single OS PC — самое то), либо «эмулятор» легаси БИОСа SeaBIOS, либо даже реализация UEFI из TianoCore.
Я не работал с coreboot напрямую, но участвовал на правах «мимокрокодила» в проекте проходящего у нас практику студента, который занимался адаптацией coreboot под наши платы. За 8 месяцев работы по 4-5 часов в день у него получилось загрузить Linux в качестве payload на 3 платах из 5, Windows 7 через SeaBIOS на тех же трех, но работала ОС нестабильно, а на двух оставшихся платах coreboot так и не смог инициализировать DRAM правильно, несмотря на все танцы с бубном и помощь двух не самых глупых инженеров. И наблюдений я делаю вывод, что coreboot в данный момент хорошо подходит для какого-то вполне опредленного нишевого железа (как хромобуки или индустриальные ПК), но со всеми проблемами с инициализацией, стартом и работой системы придется разбираться самому, поддержка сообщества быстро сведется к shut up and hack. Пока Google не начнет продавать support plan'ы для coreboot, нам делать на нем что-то — слишком большой риск, есть шанс не вылезти из отладки.
С моей точки зрения пользователю тоже стало чуть проще, хоть и немного непривычно, но это ощущение может быть вызвано банальной профдеформацией.
Если не лезть под капот, то UEFI для пользователя отличается тем, что там GPT/ESP вместо MBR, загрузчик больше не 16-битный, нет 2Тб-ограничения на размер дисков и Setup выглядит более модным. Пользователи чуть продвинутее замечают, что настройки из CMOS memory теперь дополнены громандым куском NVRAM, порядок загрузки устройств теперь задать сложнее и загрузка по типу (т.е. не «вот это загрузчик», а «USB HDD») теперь не доступна по умолчанию (эта фича старых БИОСов оказалась настолько полезна клиентам, что нам пришлось реализовать ее еще в 2011 году, а в 2014 я переписывал реализацию с нуля, т.к. в UEFI 2.4 старый подход перестал работать). Плюс проблема root-of-trust более или менее решилась, а на замену древнего DOS для прямого доступа к системе пришел UEFI Shell. Стало ли все это усложнением для пользователя — возможно, я не знаю. Но усложнив в одном месте, сильно упростили в другом, и теперь не нужно править MBR, чтобы новый загрузчик на диск дописать, или устраивать ресет ОС выводом в порт клавиатуры, которого давно уже на самом деле нет, но БИОС вынужден был его эмулировать.
Да, нетребовательность линукса к ACPI позволяет этот самый код ACPI отлаживать в нем без особого бубна. Я бы не назвал ACPI самым худшим стандартом (IEEE 1149.7 уверенно держит марку, на мой взгляд), но и хорошим его пока нызвать тоже рано. Будем посмотреть, возможно руками UEFI Forum из ACPI получится сделать что-то удобоваримое.
Тем не менее, даже с опцией acpi=off ядро успешно загружается и работает. И то, что Linux не использует «свой» набор данных из метода _OSI — это факт.
Про «на отвяжись» я уже однажды на ГТ писал:
Примерно 80% ASL-кода пишется производителем CPU (которому плевать на warning'и), еще по 10% — IBV и конечным вендором (и будь они хоть кем, их код — капля в море). Да и если большая часть современных ОС на недоработки ACPI все равно плевать хотела (а серьезно пользуется им только OSX), то и отношение к технологии — соответствующее. Пока оно работает хоть как-то — никто ничего трогать не будет, работы хватает и без этого.
Ситуация понемногу улучшается, но медленно. Посмотрим, что будет в новых прошивках.
От использования любых других компиляторов кроме Intel IASL отказались пару лет назад, когда стандарт ACPI был передан UEFI Forum на сопровождение. А после внедрения ASL 2.0 этот компилятор — вообще единственный, который способен собрать из нового кода что-то работающее.
Расскажу вам как разработчик UEFI, что вот этот «убогий сине-белый набор менюшек в текстовом режиме» превосходит по стабильности и отлаженности графический сетап на порядок. И работает даже в text mode, когда с VBIOS или GOP-драйвером что-то стряслось. И serial redirection в нем работает замечательно, а не как попало. И ломаться там почти нечему, ибо 90% кода уже лет 5 входит в состав открытого проекта TianoCore.
UEFI — это не сетап и не менюшки, это в первую очередь интерфейс для драйверов и загрузчиков, свободный груза легаси-костылей времен царя Гороха, способный не загружать неподписанные option ROM'ы и выступать в качестве root-of-trust для ОС.
Спасибо за отличную статью. Добавлю со своей UEFI-колокольни, что в прошивке теперь тоже есть своя ВМ — EBC, но пока она используется весьма слабо, т.к. компилятор в байт-код стоит денег, а системы с UEFI на ARM только начинают появляться. В итоге или писать прямо на байт-коде, как icbook, или собрать 2-3 драйвера для разных архитектур и режимов и забыть про ВМ. Выбор очевиден.
Отдел маркетинга немного спутал терминологию, и теперь непонятно, о каком именно Guard'е идет речь.
Если речь идет про то, что раньше называлось Intel PFAT, но отрицательно, слишком уж сложной оказалась технология, а плюсов каких-то кроме меньшей attack surface у нее по сравнению с обычным SMM-флешером нет, зато минусов вагон и маленький бронепоезд. решающими минусами для меня были vendor lock-in и необходимость писать скрипты на еще одном DSL, только чтобы образ для обновления прошивки подготовить.
Если же речь идет о том, что раньше называлось Intel AC, а теперь называется то BIOS Guard, то Boot Guard в зависимости от настроения, то нейтрально. С одной стороны, я отлично понимаю, зачем и кому нужен hardware root of trust, но когда для возможности сменить прошивку или добавить туда свой код в худшем случае придется менять чипсет (или весь SoC, если у вас одночиповая система) или терпеть перезагрузку раз в 30 минут — это наводит на неприятные мысли про тивоизацию, ограничение свободы ради безопасности и так далее. Есть, конечно, свои плюсы, но на большинстве наших плат технология эта использовать не будет. Хотите root-of-trust — используйте крипточип или TPM measured boot, а обычный пользователь имеет право менять прошивки своих устроств на все, что угодно.
Поддерживаю, тем более, что сетевой стек UEFI готов к применению уже пару лет, а толку от него не было почти никакого и потому он был отключен по умолчанию почти на всех системах. Теперь вот применение нашлось, но реализаций я пока еще не видел, ждем-с.
Там были проблемы с 64-битным БИОСом на мобильных платформах, которые вынуждали либо релизить 32-битную версию сейчас, либо откладывать релиз на полгода, понятно, что выбрали первое. И до сих пор некоторые пакеты ПО вроде Windriver IoT Kit выпускаются только для 32-битных UEFI, и приходится поддерживать обе версии.
Вообще, преимущества определенные для слабых машин у 32-битного UEFI имеются, грузится машина чуть быстрее, под runtime-сервисы использует чуть меньше памяти и т.п., но геморроя с 32-битными EFI-загрузчиками это все не стоит.
Мне тоже не нравится тот факт, что фичи постоянно добавляют, а баги в реализациях чинят не очень резво, но сделать с этим фактом я могу только одно — не пихать в свои БИОСы бездумно все подряд, до чего появился доступ, ведь чем меньше кода в прошивке, тем там меньше багов. К сожалению, такое мнение среди «обычных пользователей» не слишком популярно, им нужен графический Setup с красивой картинкой на фоне и прочий stuff. И загрузка чтобы без PXE-костылей. И дуалбут в Android. И черта в ступе еще. Пока такой подход позволяет продать больше плат, чем конкуренты — процесс добавления фич не остановить.
Добавление загрузки по HTTP объяснимо и ожидаемо, ведь хоть какой-нибудь HTTP-сервер имеется почти в каждой внутренней сети, и просто положить в /boot/bootx64.efi файл с загрузчиком намного проще, чем поднимать TFTP-сервер, настраивать специальным образом DHCP так, чтобы от отвечал на PXE-запросы и собрать загрузчик для 16-битного реального режима, не забыв проследить, чтобы его размер не превысил доступные 0x20000 байт.
Туда он свернул или не туда — посмотрим лет через 10-15, сейчас же в каждом новом стандарте просто добавляют очередную нужную фичу, показавшуюся полезной участникам UEFI Forum. К счастью, большая часть этих фич не является обязательно к реализации, и некоторые «темные углы» стандарта EFI 1.01 так и не реализованы до сих пор. UEFI хорош тем, что если какая-то его часть мне особенно не нравится — я ее просто не собираю и все. К примеру, мне не нравится стандартный механизм Capsule Update, и в моих реализация функциих UpdateCapsule и QueryCapsuleCapabilities просто возвращают EFI_UNSUPPORTED. Кому-то не нравится SMM, кому-то другому — RW и RO-данные в одной микросхеме, но все эти вопросы решаемые и разные части стандарта не приколочены друг к другу намертво. UEFI похож на конструктор, каждый собирает из него то, что считает нужным.
В русскоязычных интернетах так мало информации, к сожалению, что даже банальный пересказ ченджлога становится статьей.
Я не работал с coreboot напрямую, но участвовал на правах «мимокрокодила» в проекте проходящего у нас практику студента, который занимался адаптацией coreboot под наши платы. За 8 месяцев работы по 4-5 часов в день у него получилось загрузить Linux в качестве payload на 3 платах из 5, Windows 7 через SeaBIOS на тех же трех, но работала ОС нестабильно, а на двух оставшихся платах coreboot так и не смог инициализировать DRAM правильно, несмотря на все танцы с бубном и помощь двух не самых глупых инженеров. И наблюдений я делаю вывод, что coreboot в данный момент хорошо подходит для какого-то вполне опредленного нишевого железа (как хромобуки или индустриальные ПК), но со всеми проблемами с инициализацией, стартом и работой системы придется разбираться самому, поддержка сообщества быстро сведется к shut up and hack. Пока Google не начнет продавать support plan'ы для coreboot, нам делать на нем что-то — слишком большой риск, есть шанс не вылезти из отладки.
Если не лезть под капот, то UEFI для пользователя отличается тем, что там GPT/ESP вместо MBR, загрузчик больше не 16-битный, нет 2Тб-ограничения на размер дисков и Setup выглядит более модным. Пользователи чуть продвинутее замечают, что настройки из CMOS memory теперь дополнены громандым куском NVRAM, порядок загрузки устройств теперь задать сложнее и загрузка по типу (т.е. не «вот это загрузчик», а «USB HDD») теперь не доступна по умолчанию (эта фича старых БИОСов оказалась настолько полезна клиентам, что нам пришлось реализовать ее еще в 2011 году, а в 2014 я переписывал реализацию с нуля, т.к. в UEFI 2.4 старый подход перестал работать). Плюс проблема root-of-trust более или менее решилась, а на замену древнего DOS для прямого доступа к системе пришел UEFI Shell. Стало ли все это усложнением для пользователя — возможно, я не знаю. Но усложнив в одном месте, сильно упростили в другом, и теперь не нужно править MBR, чтобы новый загрузчик на диск дописать, или устраивать ресет ОС выводом в порт клавиатуры, которого давно уже на самом деле нет, но БИОС вынужден был его эмулировать.
Про «на отвяжись» я уже однажды на ГТ писал:
Ситуация понемногу улучшается, но медленно. Посмотрим, что будет в новых прошивках.
От использования любых других компиляторов кроме Intel IASL отказались пару лет назад, когда стандарт ACPI был передан UEFI Forum на сопровождение. А после внедрения ASL 2.0 этот компилятор — вообще единственный, который способен собрать из нового кода что-то работающее.
UEFI — это не сетап и не менюшки, это в первую очередь интерфейс для драйверов и загрузчиков, свободный груза легаси-костылей времен царя Гороха, способный не загружать неподписанные option ROM'ы и выступать в качестве root-of-trust для ОС.
Если речь идет про то, что раньше называлось Intel PFAT, но отрицательно, слишком уж сложной оказалась технология, а плюсов каких-то кроме меньшей attack surface у нее по сравнению с обычным SMM-флешером нет, зато минусов вагон и маленький бронепоезд. решающими минусами для меня были vendor lock-in и необходимость писать скрипты на еще одном DSL, только чтобы образ для обновления прошивки подготовить.
Если же речь идет о том, что раньше называлось Intel AC, а теперь называется то BIOS Guard, то Boot Guard в зависимости от настроения, то нейтрально. С одной стороны, я отлично понимаю, зачем и кому нужен hardware root of trust, но когда для возможности сменить прошивку или добавить туда свой код в худшем случае придется менять чипсет (или весь SoC, если у вас одночиповая система) или терпеть перезагрузку раз в 30 минут — это наводит на неприятные мысли про тивоизацию, ограничение свободы ради безопасности и так далее. Есть, конечно, свои плюсы, но на большинстве наших плат технология эта использовать не будет. Хотите root-of-trust — используйте крипточип или TPM measured boot, а обычный пользователь имеет право менять прошивки своих устроств на все, что угодно.
Вообще, преимущества определенные для слабых машин у 32-битного UEFI имеются, грузится машина чуть быстрее, под runtime-сервисы использует чуть меньше памяти и т.п., но геморроя с 32-битными EFI-загрузчиками это все не стоит.