Может, никто не спорит. Сделан этот сервис в первую очередь для того, чтобы предоставить абстракцию от конкретного способа выполнить этот самый Reset, а то этих способов за 30 лет развития архитектуры x86 накопилось столько, что не знаешь, за какой хвататься, и какие еще работают (IO port 0xCF9), какие уже 10 лет устаревают (IO port 0x92), а какие наконец-то устарели совсем (IO port 0x64).
Добавлю, что на машинах с UEFI есть возможность вызвать перезагрузку вызовом gRT->ResetSystem(), который не зависит от ядра и может выполнить даже power cycle reset, при условии, что БП не завис намертво. Доступен сервис на любой системе и без IPMI, но как достучаться до UEFI RT Services из ОС — вопрос отдельный.
Я же так и написал, что это идея, хочешь используй eMMC в качестве хранилища прошивки, хочешь — продолжай использовать SPI. Да и не удивляюсь я ничему, выше уже писал, что на Bay Trail было почти то же самое. Вы меня как-то неправильно поняли, мне кажется.
Защищена область будет очень просто — начиная со стандарта eMMC 4.4 на них имеется специальный RPMB-раздел размером до 32 Мб, на котором можно хранить ключи шифрования и прочую чувствительную информацию, и два раздела Boot0 и Boot1 (оба до 32 Мб), запись на которые можно запретить до перезагрузки во время инициализации прошивки. В итоге ничего разруливать не нужно — контролер eMMC разрулит все за нас.
Идею адаптировали еще на Bay Trail, только там загрузка была двухстадийная и PEI все равно был только на флешке, а теперь вот удалось интегрировать контролер eMMC достаточно глубоко, чтобы грузится с него. Безопасность там обеспечат каким-нибудь аналогом BootGuard, при котором прошивку можно будет хранить хоть где — пока коллизии SHA256 не научились находить за полчаса, такой защиты хватит. Посмотрим, я не буду загадывать. Производители для индустрии у пользователя возможность добавить собственный код в прошивку не отбирали и не будут отбирать, а до всяких Asus'ов мне теперь уже дела почти нет, пусть хоть на голове танцуют.
Можно и 64 кб впихнуть, если стараться, но это все никому не нужно.
Сейчас вот в недавней презентации новой линейки Atom под кодовым именем Apollo Lake на слайде двинули интересную во всех отношениях идею — отказ от SPI-чипа для хранения прошивки в пользу EMMC. Там и автоматический WL, и регистр EXT_CSD, в котором результаты WL и прогноз живучести можно наблюдать, и разделы специальные под загрузчики с защитой от записи и тайминг-атак, да и вообще плюсы сплошные. С другой же стороны, получив возможность иметь в прошивке не 16 МБ, а 16Гб, у некоторых производителей от такого обилия моментально снесет крышу, и в прошивку засунут не просто 3D-моделей и заказ пиццы, а вообще целиковый эмулятор андроида (привет, AMI DuOS), какой-нибудь еще линукс для административных задач, и парочку своих велосипедов на паровой тяге размером в полгигабайта.
Я устал уже разным людям из индустрии говорить, что прошивки вообще и UEFI в частности «созданы, чтобы умирать», как PHP в свое время, и не нужно делать ОС общего назначения из UEFI Shell, там кишки наружу все и любое переполнение буфера — это компрометация всей системы. Все равно об стену горохом, мусора в прошивке с каждым годом все больше, а толку от нее все меньше.
С другой строны, в качестве wear leveling'а отлично работает стратегия VSS, когда с предыдущей структуры снимается бит Valid, и в конец записывается следующая, не важно, большего там размера данные, меньшего или такого же. Дошли до конца — делаем сборку мусора. Подход AMI в данном случае лучше тем, что не нужно копировать имя и GUID, т.е. ресурс флеша все-таки экономится. Заодно становится понятно, зачем поле Next обновляют не в первой записи, а в последней — пара месяцев, и первую запись переменной MonitonicCounter или MemScrambleSeed затерло бы иначе просто до дыр, а так — все в порядке. В общем, тут все же больше экономия места на флеше, чем управление износом, на мой взгляд.
Может быть, не исключено, но можно придумать и менее хитрые способы, при которых хотя бы не нужно проходить по односвязным спискам до конца, чтобы до данных добраться.
Плат с «уставшим» SPI-чипом я тоже перевидал изрядно, причем симтомы там почти каждый раз разные, и сразу не поймешь, почему система сначала 5 лет работала в станке без сбоев, а потом начала на загрузке виснуть, на выключении виснуть, или вообще просто виснуть, без внешних причин. Никогда на SPI-чип не подумал бы, если бы его замена не решала бы проблему.
Потому что для Subzero.io используется обрезанная версия uefi-firmware-parser, в которую разбор NVRAM еще не портирован из UEFITool или CHIPSEC. Либо Тедди допилит UFP, либо мне хватит сил на libffsparser, но поддержка эта рано или поздно добавится.
На здоровье. Формат, конечно, полный песец. Ничего не мешало использовать формат VSS, который хоть и занимает побольше, зато прямой как палка и парсить его — одно удовольствие, но нет, если стандарт позволяет свободу в реализации, ей нужно пользовать именно таким образом.
Забыл сказать спасибо ребятам из проекта CHIPSEC за референсную реализацию парсига, на которую я частенько оглядывался, и тов. xvilka, который помогал с разбором NVAR и образами, и советами, и даже кодом.
Я тут мимо проходил, и на верилоге почти не пишу, поэтому не могу сказать, где код ужасен, а где нет, но хотел бы научиться отличаться ужасный код от нормального и толковые комментарии от профессионалов могли бы в этом помочь. Вместо них у вас тут «и так понятно».
Посмотрите для примера на комментарии тов. khim, он тоже не терпит говнокода, но при этом не ленится пояснять почему конкретный код — говно и что с этим можно сделать. В итоге в выигрыше все, и автор, и комментатор, и читатели.
TL;DR: Критикуешь — предлагай.
Обычно хранилищ NVRAM делают два — основное и резервное, и в данном случае прошивка обнаружила повреждение основного хранилища, и переключилась на резервное. Ошибка же производителя в том, что «личные» данные конкретной платы в основное хранилище записали при начальной настройке, а в дополнительное — почему-то забыли. Восстановление после такого можно попробовать провернуть, сняв резервную копию сразу же и попытавшись вытащить данные из основного хранилища, возможно это получилось бы сделать, но через пару-тройку перезагрузок сработает сборщик мусора и тогда все, плакали наши данные.
С основной могла не запуститься потому, что воткнули новую память, понадобилось записать новые SPDData и MemCeiling, и на них не хватило места. Почему «протухла» резервная — понятно непросто, может сама SPI-микросхема попалась глючная, может еще что.
Мне как-то пришлось именно восстанавливать, т.к. на машине была куча крайне дорогого диагностического софта от нескольких автопроизводителей, который привязывается к данным DMI и упорно отказывается даже страртовать на «другой» машине. А потом на этом ноутбуке неожиданно развалился EVSA NVRAM, в котором половина данных DMI и хранилась, и софт отказался признавать ноутбук за сфоего после восстановления на программаторе. Повезло, что ребята сняли оригинальный дамп, с которым они ко мне и пришли. Посидел с часок, часть данных достал, нужны оказались System UUID и Motherboard Serial Number, которые получилось найти и перенести, после чего софт заработал снова.
Уникальными должна быть комбинация «GUID + имя», но если дедупликация GUIDов еще имеет какой-то смысл (т.к. переменных с одним и тем же GUIDом довольно много, и это совершенно нормально), то с именами этот смысл уже практически не найти.
Да я и сам под впечатлением до сих пор, а парсер CMDB даже не смог заставить себя написать, т.к. гадость. Я подозреваю, что они просто раньше всех начали, еще со времен чипсетов пятой серии, и потому на тот момент просто не знали, как правильно пользоваться технологиями EFI вроде банального ReadFile. Поэтому пришлось реализовать свой собственный набор велосипедов, и с тех пор они перекатываются из одного reference tree в другой почти без изменений. Нужно отделить переменные SecureBoot от остальных — вот вам еще пара EVSA store специально под них. Нужны дефолты — вот еще два таких хранилища. Микрокоды надо грузить пораньше — и их в том NVRAM, единственный, содержимое которого можно выдумывать как угодно, и никакая спецификация PI тебе не указ!
Очень надеюсь, что они одумаются и откажутся от своих тюнингованных шоссейников в пользуй решений из EDKx, когда-нибудь. А пока имеем то что имеем — цирк-шапито на конной тяге.
Спасибо автору за отличное введение в KS, а тов. GreyCat за саму утилиту. Надо будет взять на вооружение, а то я так и продолжаю хранить все форматы в виде С-стуруктур и комментариев к ним, а парсеры писать вручную (вкривь и вкось).
«Отключить» МЕ нужно так, чтобы он а) не мешал никому своими вотчдогами, б) ничего не писал на флеш (читает пусть сколько угодно) и в) система при этом не сильно проседала по производительности или возможностям. Понятно, что совсем честное отключение — это когда региона МЕ вообще нет, но на безрыбье народ согласен и на вышеперечисленное, хоть и добиться его становится сложнее с каждым поколением.
Большое спасибо за материал, пригодится обязательно.
Защищена область будет очень просто — начиная со стандарта eMMC 4.4 на них имеется специальный RPMB-раздел размером до 32 Мб, на котором можно хранить ключи шифрования и прочую чувствительную информацию, и два раздела Boot0 и Boot1 (оба до 32 Мб), запись на которые можно запретить до перезагрузки во время инициализации прошивки. В итоге ничего разруливать не нужно — контролер eMMC разрулит все за нас.
Сейчас вот в недавней презентации новой линейки Atom под кодовым именем Apollo Lake на слайде двинули интересную во всех отношениях идею — отказ от SPI-чипа для хранения прошивки в пользу EMMC. Там и автоматический WL, и регистр EXT_CSD, в котором результаты WL и прогноз живучести можно наблюдать, и разделы специальные под загрузчики с защитой от записи и тайминг-атак, да и вообще плюсы сплошные. С другой же стороны, получив возможность иметь в прошивке не 16 МБ, а 16Гб, у некоторых производителей от такого обилия моментально снесет крышу, и в прошивку засунут не просто 3D-моделей и заказ пиццы, а вообще целиковый эмулятор андроида (привет, AMI DuOS), какой-нибудь еще линукс для административных задач, и парочку своих велосипедов на паровой тяге размером в полгигабайта.
Я устал уже разным людям из индустрии говорить, что прошивки вообще и UEFI в частности «созданы, чтобы умирать», как PHP в свое время, и не нужно делать ОС общего назначения из UEFI Shell, там кишки наружу все и любое переполнение буфера — это компрометация всей системы. Все равно об стену горохом, мусора в прошивке с каждым годом все больше, а толку от нее все меньше.
Плат с «уставшим» SPI-чипом я тоже перевидал изрядно, причем симтомы там почти каждый раз разные, и сразу не поймешь, почему система сначала 5 лет работала в станке без сбоев, а потом начала на загрузке виснуть, на выключении виснуть, или вообще просто виснуть, без внешних причин. Никогда на SPI-чип не подумал бы, если бы его замена не решала бы проблему.
Забыл сказать спасибо ребятам из проекта CHIPSEC за референсную реализацию парсига, на которую я частенько оглядывался, и тов. xvilka, который помогал с разбором NVAR и образами, и советами, и даже кодом.
Посмотрите для примера на комментарии тов. khim, он тоже не терпит говнокода, но при этом не ленится пояснять почему конкретный код — говно и что с этим можно сделать. В итоге в выигрыше все, и автор, и комментатор, и читатели.
TL;DR: Критикуешь — предлагай.
Мне как-то пришлось именно восстанавливать, т.к. на машине была куча крайне дорогого диагностического софта от нескольких автопроизводителей, который привязывается к данным DMI и упорно отказывается даже страртовать на «другой» машине. А потом на этом ноутбуке неожиданно развалился EVSA NVRAM, в котором половина данных DMI и хранилась, и софт отказался признавать ноутбук за сфоего после восстановления на программаторе. Повезло, что ребята сняли оригинальный дамп, с которым они ко мне и пришли. Посидел с часок, часть данных достал, нужны оказались System UUID и Motherboard Serial Number, которые получилось найти и перенести, после чего софт заработал снова.
Очень надеюсь, что они одумаются и откажутся от своих тюнингованных шоссейников в пользуй решений из EDKx, когда-нибудь. А пока имеем то что имеем — цирк-шапито на конной тяге.