Pull to refresh

Comments 13

Нда, кислые ягодки.
Спасибо за описание формата!
Теперь понятно откуда некоторые особенности и баги UEFI растут.
Столько возможностей для багов и эксплоитов =\
На здоровье. Формат, конечно, полный песец. Ничего не мешало использовать формат VSS, который хоть и занимает побольше, зато прямой как палка и парсить его — одно удовольствие, но нет, если стандарт позволяет свободу в реализации, ей нужно пользовать именно таким образом.
Забыл сказать спасибо ребятам из проекта CHIPSEC за референсную реализацию парсига, на которую я частенько оглядывался, и тов. xvilka, который помогал с разбором NVAR и образами, и советами, и даже кодом.
Немного не в тему, но если уж форматы nvram более-менее известны, то почему-то на сайте subzero.io нет пока поддержки NVRAM:
«UEFI Varibles (NVRAM)
Coming Soon»

Потому что для Subzero.io используется обрезанная версия uefi-firmware-parser, в которую разбор NVRAM еще не портирован из UEFITool или CHIPSEC. Либо Тедди допилит UFP, либо мне хватит сил на libffsparser, но поддержка эта рано или поздно добавится.
> Зачем так сделано — еще одна великая тайна, я не могу придумать уважительной причины такому поведению.
Железячник во мне говорит что это такой своеобразный wear leveling, и в AMI таким образом попытались продлить жизнь SPI флешке. В итоге имеем всю область nvram с одинаковым износом.
Да, есть у меня одна плата которая умерла какраз по износу флеша — верификация обрамывается ровно на одном блоке, причем постоянно, я думаю не надо говорить, что в дампе прошивки находилось на этом месте. Машинка перезагружалась раз 6 за день, прожила два года, подарила мне нелюбовь к macronix.
Может быть, не исключено, но можно придумать и менее хитрые способы, при которых хотя бы не нужно проходить по односвязным спискам до конца, чтобы до данных добраться.
Плат с «уставшим» SPI-чипом я тоже перевидал изрядно, причем симтомы там почти каждый раз разные, и сразу не поймешь, почему система сначала 5 лет работала в станке без сбоев, а потом начала на загрузке виснуть, на выключении виснуть, или вообще просто виснуть, без внешних причин. Никогда на SPI-чип не подумал бы, если бы его замена не решала бы проблему.
С другой строны, в качестве wear leveling'а отлично работает стратегия VSS, когда с предыдущей структуры снимается бит Valid, и в конец записывается следующая, не важно, большего там размера данные, меньшего или такого же. Дошли до конца — делаем сборку мусора. Подход AMI в данном случае лучше тем, что не нужно копировать имя и GUID, т.е. ресурс флеша все-таки экономится. Заодно становится понятно, зачем поле Next обновляют не в первой записи, а в последней — пара месяцев, и первую запись переменной MonitonicCounter или MemScrambleSeed затерло бы иначе просто до дыр, а так — все в порядке. В общем, тут все же больше экономия места на флеше, чем управление износом, на мой взгляд.
Ну как говорится модель Велосипеды-Баги-Костыли используется крупными мировыми разработчиками ПО. А с экономией я скажу так — корбутовская прошивка влезает в 1мб и спокойно работает и не жужжит (ну правда тоже гадит в флеш, но это решаемо) без особых проблем — система грузится, плюшек и фишек нету, имеем на выходе интерфейс старого доброго биоса на новых платах. С другой стороны если насовать в UEFI кучу «унЕкальных прЕлажений», добавить 3D моделей и прочих свистелок и перделок(привет асусу/асроку, не забудьте добавить функцию заказа пиццы в свои материнки, т.к. пока до вашей техподдержки из uefi достучишься очень хочется кушать, т.к. реализация vpn тормозит у вас) — можно и в 8Мб не влезть, экономия 5кб при таких объемах других модулей мне кажется просто смешной.
Можно и 64 кб впихнуть, если стараться, но это все никому не нужно.
Сейчас вот в недавней презентации новой линейки Atom под кодовым именем Apollo Lake на слайде двинули интересную во всех отношениях идею — отказ от SPI-чипа для хранения прошивки в пользу EMMC. Там и автоматический WL, и регистр EXT_CSD, в котором результаты WL и прогноз живучести можно наблюдать, и разделы специальные под загрузчики с защитой от записи и тайминг-атак, да и вообще плюсы сплошные. С другой же стороны, получив возможность иметь в прошивке не 16 МБ, а 16Гб, у некоторых производителей от такого обилия моментально снесет крышу, и в прошивку засунут не просто 3D-моделей и заказ пиццы, а вообще целиковый эмулятор андроида (привет, AMI DuOS), какой-нибудь еще линукс для административных задач, и парочку своих велосипедов на паровой тяге размером в полгигабайта.
Я устал уже разным людям из индустрии говорить, что прошивки вообще и UEFI в частности «созданы, чтобы умирать», как PHP в свое время, и не нужно делать ОС общего назначения из UEFI Shell, там кишки наружу все и любое переполнение буфера — это компрометация всей системы. Все равно об стену горохом, мусора в прошивке с каждым годом все больше, а толку от нее все меньше.
Идея насчёт eMMC хороша в свете последней моды с этим самым NVRAM вечно пишущимся, а насчёт 16Гб — ну асус в своё время пихал в платы БИОСной эпохи ExpressGate, работало неплохо. Другое дело, что в случае eMMC задачу разделить код прошивки и код перделок сделают через одно место, в эпоху P3-P4 я любил подпихивать через ROMOS во все платы, что через меня проходили самый обычный memtest86, получалось удобно, но безопасностью и не пахло даже. И я даже гарантию дам, что асус таки засунет всякой лабуды. Впрочем получить такую машинку с таким DOMом я бы не отказался, можно браузилку вконтактика засунуть, или банк-клиент на RO носитель, который всегда в материнке. Но, не вешать её на UEFI ничем, кроме загрузчика, нафиг нафиг нафиг мне голая опа выставленная в окно с надписью «засуньте сюда что-нить»
П.С. Идею спёрли из микроконтроллерного/микропроцессорного мира — в тех-же армах давно уже на чипе микробутлоадер, который по конфигурации пинов грузит основной код с eMMC/SD/USART/чтотамзахрень
Идею адаптировали еще на Bay Trail, только там загрузка была двухстадийная и PEI все равно был только на флешке, а теперь вот удалось интегрировать контролер eMMC достаточно глубоко, чтобы грузится с него. Безопасность там обеспечат каким-нибудь аналогом BootGuard, при котором прошивку можно будет хранить хоть где — пока коллизии SHA256 не научились находить за полчаса, такой защиты хватит. Посмотрим, я не буду загадывать. Производители для индустрии у пользователя возможность добавить собственный код в прошивку не отбирали и не будут отбирать, а до всяких Asus'ов мне теперь уже дела почти нет, пусть хоть на голове танцуют.
так ли отказ? там sata и pcie есть, там что можно собрать систему и без emmc… я б сказал, что добавили возможность и, вероятно, загрузка задаётся hw bootstrap, а ля любой embed.
да и к чему такое удивление? что наконец в мир х86 пришла возможность «мультибута»? с помощью разной степени проприетарности загрузчиков что c голого nand что с emmc разный embed грузится как бы не с десяток лет.
интересно, как будет защищена область с fw. тут а ля embed не выйдет, тут ос с парадигмой «пользователь — бог» крутиться будут. fw должна будет разруливать доступ к секторам с собой, или, например, заниматься эмуляцией блочного устроства, скрывая физический накопитель или, например, изменяя нумерацию секторов.
Я же так и написал, что это идея, хочешь используй eMMC в качестве хранилища прошивки, хочешь — продолжай использовать SPI. Да и не удивляюсь я ничему, выше уже писал, что на Bay Trail было почти то же самое. Вы меня как-то неправильно поняли, мне кажется.
Защищена область будет очень просто — начиная со стандарта eMMC 4.4 на них имеется специальный RPMB-раздел размером до 32 Мб, на котором можно хранить ключи шифрования и прочую чувствительную информацию, и два раздела Boot0 и Boot1 (оба до 32 Мб), запись на которые можно запретить до перезагрузки во время инициализации прошивки. В итоге ничего разруливать не нужно — контролер eMMC разрулит все за нас.
Sign up to leave a comment.

Articles