Спасибо за отличную статью. Добавлю со своей 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-загрузчиками это все не стоит.
Проект небольшой, всего 80 Мб кода, на анализ ушло ~5 минут работы анализатора (VmWare 10, 4 ядра, 8 гб памяти) плюс около часа я потратил на разгребание предупреждений и поиск ошибок.
На работе анализировал проекты на 400 — 600 Мб кода, на анализ тратится 10-15 минут, 4 ядра, 8 гб памяти в реальной ОС.
Ну нужно нам такого счастья, извините.
PCIe — это возможность иметь по несколько OptionROMов в каждом устройстве на шине, которые выполняются в контексте BIOSа и могут быть использованы для атаки на него. А т.к. SecureBoot пользователи почему-то дико не любят, то внешние интерфейсы с PCIe — «входные ворота инфекции». А если вдруг от OROMов вредоносных защитились — ну даже и без них PCIe-устройство может инициировать DMA со всей физической памятью, кроме SMRAM, и утащить у вас все пароли и ключи шифрования, которые неосмотрительно хранятся в RAM. Эту проблему решает IOMMU, который включен у двух с половиной параноиков, остальные надеются на то, что им ничего вредоносного в PCIe не попадет, а тут его в каждый USB-порт предлагают добавить…
libcore is built on the assumption of a few existing symbols:
memcpy, memcmp, memset — These are core memory routines which are often generated by LLVM. Additionally, this library can make explicit calls to these functions. Their signatures are the same as found in C. These functions are often provided by the system libc, but can also be provided by the rlibc crate.
rust_begin_unwind — This function takes three arguments, a fmt::Arguments, a &str, and a u32. These three arguments dictate the panic message, the file at which panic was invoked, and the line. It is up to consumers of this core library to define this panic function; it is only required to never return.
Поведение такое же, как в C, и тоже придется либо реализовывать самому, либо использовать библиотеку rlibc, либо обернуть уже доступные gRS->CopyMem и gRS->SetMem.
Вот именно что в UTF8. А в UEFI — в UCS2, в итоге строковые литералы придется делать через макросы, и простого L«String» уже недостаточно.
По поводу memset и memcpu — в С бывают случаи, когда их вызовы могут быть вставлены компилятором автоматически (к примеру, при передаче по значению структуры, размер которой не кратен никакому доступному регистру), а потом при линковке вдруг оказывается, что таких функций нет. Когда я столкнулся с таким поведением впервые — был немало удивлен, поэтому и спрашиваю.
Очень хочу попробовать написать несколько DXE-драйверов на Rust, но пока совершенно не хватает времени на то, чтобы сделать нормальный интерфейс хотя бы к UEFI BootServices и RuntimeServices. Плюс язык новый и малознакомый, плюс хитрое calling convention, плюс строки в UCS2 вместо UTF8, и в итоге получается какой-то хлам, а не драйвер, и проще дальше на С писать.
Вопрос к тем, кто уже пробовал писать на Rust действительно системные вещи (bare-metal, к примеру): сильно сложно жить без стандартной библиотеки? Компилятор не вставляет memset и memcpu самостоятельно?
Стоит еще добавить, что устройства с Thunderbolt (и с любым другим интерфейсом типа «PCI наружу», вроде Firewire или PCMCIA), могут содержать код (т.н. Option ROM), исполняемый с привилегиями BIOSа, через который может быть осуществлена атака на этот самый BIOS, внедрен буткит и получен полный доступ к ПК в обход всех защитных средств ОС.
В качестве превентивной меры помогает SecureBoot, но его пока мало кто включает, ибо «это зло!!!111».
Это действительно i3-4015U D0, и он ищется на ARK-CARE (внутреннем сайте Intel для разработчиков систем) по кодовому имени QAES. Почему его нет в рознице и публичном доступе — я не знаю.
Работаю сейчас над БИОСом для похожей платы, вот такой.
«EDP1» — это Embedded DisplayPort, относительно новый стандарт подключения LCD-панелей, наследник LVDS.
BIOS — AMI'шный Aptio4 референс без изменений, денег на обработку напильником никто тратить не стал.
Теперь к вопросу «зачем платить больше»: за качество железа и ПО, возможности замены при поломке и восстановления при сбое прошивки. Китайский noname хорош там, где его поломка не останавливает работу, так что купить себе такую плату домой — самое то, но для всего остального лучше купить изделие Apple, Intel, Gigabyte или любого известного производителя embedded-решений (Kontron, congatec, advantech, и.т.п.), у которых работает тех. поддержка и прошивки обновляются.
Такие устройства уже пошли, это любые современные видеокарты, SSD с интерфейсом NVMe, разного рода ускорители на FPGA и т.д. На данный момент производители предоставляют и OptionROM для совместимости с legacy BIOS, и DXE driver для UEFI, но втечение пары лет от поставки OROM'ов откажутся окончательно, вместе с отказом от CSM на большинстве десктопов. А на ноутбуках от CSM некоторые производители отказались уже сейчас.
Если речь идет про то, что раньше называлось 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-загрузчиками это все не стоит.
На работе анализировал проекты на 400 — 600 Мб кода, на анализ тратится 10-15 минут, 4 ядра, 8 гб памяти в реальной ОС.
PCIe — это возможность иметь по несколько OptionROMов в каждом устройстве на шине, которые выполняются в контексте BIOSа и могут быть использованы для атаки на него. А т.к. SecureBoot пользователи почему-то дико не любят, то внешние интерфейсы с PCIe — «входные ворота инфекции». А если вдруг от OROMов вредоносных защитились — ну даже и без них PCIe-устройство может инициировать DMA со всей физической памятью, кроме SMRAM, и утащить у вас все пароли и ключи шифрования, которые неосмотрительно хранятся в RAM. Эту проблему решает IOMMU, который включен у двух с половиной параноиков, остальные надеются на то, что им ничего вредоносного в PCIe не попадет, а тут его в каждый USB-порт предлагают добавить…
Поведение такое же, как в C, и тоже придется либо реализовывать самому, либо использовать библиотеку rlibc, либо обернуть уже доступные gRS->CopyMem и gRS->SetMem.
По поводу memset и memcpu — в С бывают случаи, когда их вызовы могут быть вставлены компилятором автоматически (к примеру, при передаче по значению структуры, размер которой не кратен никакому доступному регистру), а потом при линковке вдруг оказывается, что таких функций нет. Когда я столкнулся с таким поведением впервые — был немало удивлен, поэтому и спрашиваю.
Вопрос к тем, кто уже пробовал писать на Rust действительно системные вещи (bare-metal, к примеру): сильно сложно жить без стандартной библиотеки? Компилятор не вставляет memset и memcpu самостоятельно?
В качестве превентивной меры помогает SecureBoot, но его пока мало кто включает, ибо «это зло!!!111».
«EDP1» — это Embedded DisplayPort, относительно новый стандарт подключения LCD-панелей, наследник LVDS.
BIOS — AMI'шный Aptio4 референс без изменений, денег на обработку напильником никто тратить не стал.
Теперь к вопросу «зачем платить больше»: за качество железа и ПО, возможности замены при поломке и восстановления при сбое прошивки. Китайский noname хорош там, где его поломка не останавливает работу, так что купить себе такую плату домой — самое то, но для всего остального лучше купить изделие Apple, Intel, Gigabyte или любого известного производителя embedded-решений (Kontron, congatec, advantech, и.т.п.), у которых работает тех. поддержка и прошивки обновляются.