Не, там скорее драйвер в прошивке, ОЕМы его любят.
Проблема только в том, что добавление любых нетривиальных парсеров на С в прошивку (а парсер NTFS — нифига не тривиальный, там в спецификации рота чертей все ноги сломит) сильно ухудшает безопасность платформы, потому что творчески испорченная флешка может на такой системе обходить SecureBoot, пароль на Bios Setup и черт знает что еще потому, что ФС надо парсить раньше, чем получится проверить загрузчик, который на ней лежит.
FAT потому и потребовали для ESP, что его спецификация весьма несложная, и написать и отладить относительно нормальный драйвер для этой ФС на С все таки можно.
Как разработчик прошивок (в прошлом) и инженер по их безопасности (в настоящем) я горячо поддерживаю Intel в желании выкинуть наконец CSM, только вот проблема в том, что просто так выкинуть 30 лет обратной совместимости и при этом никого не обидеть — решительно невозможно.
Большая часть промышленных систем х86 как загружалась дедовским 16-битным загрузчиком, так и продолжит загружаться, и менять ради Intel какой-нибудь ткацкий станок Bosch за миллион долларов никто не будет, поэтому производители для Embedded и Industrial вроде Kontron, congatec, Advantec, DFI и т.п. будут поддерживать CSM до последнего патрона, причем такой home-grown CSM будет, скорее всего, еще более кривым, дырявым и глючным, чем то, что Intel поставляет нам сейчас.
С другой стороны, Apple отказались от CSM уже довольно давно, и т.к. на их машинах редко запускали DOS и прочее легаси времен царя Гороха, этого почти никто не заметил. Для большей части нынешних пользователей отказ от CSM пройдет совершенно незаметно — они DOS и не запускали никогда, а в каком режиме процессор стартует и какой интерфейс использует для взаимодействия с прошивкой — 99.9% пользователей решительно пофиг, лишь бы ОС загружалась.
У них там, к сожалению, нет поддержки GOP, потому что в Microsoft принципиально решили, что этот протокол поддерживать не будут. В результате при отключенном CSM Windows 7 загружается «вслепую», если загружается вообще.
Не нужно бояться слова "мудак", ребят, оно не матерное и хорошо передает смысл на русском языке вместо непонятного в этом контексте "придурок".
По теме же статьи — человеку иногда нужно побыть мудаком минут 10 в неделю, ибо безупречная вежливость и обходительность очень многими воспринимается как слабость.
С другой стороны, нет никакого смысла наказывать за баги — это приведет к только к тому, что о них перестанут сообщать, и начнут открещиваться от них до последнего.
Главный вопрос, на который необходимо ответить после разбора полетов — "как недопустить повторения ошибочной ситуации в будущем?".
Если же человек просто все время ведет себя как мудак — таким лучше сразу желать здоровья и отправлять в свободное плавание, на мой взгляд.
Когда RedHat начнет выпускать прошивки или железо — вот тогда они смогут пропихнуть что-угодно в свои продукты, а пока их ОС ставится на сервера и рабочие станции Lenovo, Dell или HP, их безопасники за одну только идею добавить в прошивку еще один весьма нетривиальный парсер на С любому голову оторвут.
Нет, подождите. Опять создай раздел? Может быть кто-нибудь догадается в спецификацию EFI добавить поддержку LVM? Пожалуйста?
Через мой труп, извините. Иметь драйверы любых файловых систем кроме совсем тривиальных в прошивке — верный способ быть взломанным через втыкание внешнего носителя с творчески испорченной ФС, разбор которой приведет к выполнению вредоносного кода в BDS, а дальше там обход SecureBoot, обход пароля от BIOS Setup, и прочее воровство и убийство.
Вот вам один стандартный формат и драйвер к нему, оба простые как палка — пользуйтесь, городите поверх них любые LVMы, ZFSы, APFSы, что угодно, а прошивке оставьте ее GPT, который просто работает.
Отличная статья, хабр еще торт!
Если серьезно — очень на многих платах до сих пор DCI управляется из переменной Setup (первый способ с HII — это оно и есть), т.е. для его включения в конкретной прошивке нужны всего две вещи — IFR Extractor, чтобы выяснить, по какому смещению в переменной Setup находится эта настройка, и EFI Shell с командой dmpstore чтобы поменять ее.
Думаю, что эти слухи из разряда баек, появившихся в тёмные времена, когда производители клали на стандарт UEFI
Эти темные времена — они были всегда и будут всегда, так что это не слухи, а суровая реальность.
Дело там вот в чем: efibootmgr сам по себе ничего не ломает, особенно если менять только переменную BootOrder, как это описано в статье. А вот если пытаться создавать новые записи для загрузчиков или переписывать уже имеющиеся, придется, кроме всего прочего, конструировать EFI DevicePath, и вот здесь у нас получается бомба, поскольку правильность DevicePath зависит от текущей прошивки, и реакция на неправильный также зависит от прошивки. Иногда угадать формат получается и все проходит хорошо, а в других случаях не получается, и восстановление из такого состояния может быть как безболезненным (у AMI Aptio, к примеру), так и очень неприятным (Phoenix SCT), а иногда и вовсе практически смертельным для прошивки (старые Insyde H2O).
Короче: доверьте управление загрузочными устройствами самой прошивке, она точно знает, как именно создать правильные записи BootXXXX так, чтобы ничего не сломалось. Да, это баг в реализации, и в последнее время он встречается не очень часто, но лучше не испытывать судьбу.
Вот тут Крис Домас решил найти их все (даже недокументированные) при помощи весьма забавного трюка с помещением очередного кандидата в валидные инструкции на границу между страницами памяти.
Видео оригинального доклада, рекомендую двумя руками:
Отличный материал, спасибо еще раз.
Локализация вообще очень редко освещается в статьях о разработке ПО (просто потому, что большая часть этих статей на английском, и там локализация мало кому нужна), а тут такой подарок.
Отлично, замечу только, что с gST->ConOut и gST->ConIn напрямую стоит работать только в процессе начального обучения, потому что цепочки из X->Y->Z(X->Y, T) сильно замусоревают код и его становится неприятно читать, а читаемость — это, на мой взгляд, вторая по важности характериска кода прошивки после работоспособности.
В реальных приложениях и драйверах обычно используют библиотеку PrintLib, которая превращает кошмарный gST->ConOut->OutputString(gST->ConOut, L"String") во вполне безобидные Print(L"String") или AsciiPrint("String").
Скорее всего, это все будет в следующих частях, ждем с нетерпением.
Пожалуйста, рад что кому-то моя статья помогла.
По поводу нового фреймворка — соглашусь, но новички перестанут быть новичками, и изучать сборочную систему EDK2 им все равно придется, неважно, с чего они при этом начинали, с NT32Pkg, c VisualUEFI, или с какой-нибудь IDE от IBV (я раньше работал с Visual eBIOS, которая сделана из Eclipse, сейчас работаю с Xcode). Визарды — это отлично, конечно, но их быстро перестанет хватать.
Не могу сказать, что лучше начинать прямо с EDK2, как это сделано в моей статье, но точно могу сказать, что работать с EDK2 в любом случае придется, рано или поздно, так или иначе.
Приятно видеть статьи про UEFI на Хабре, спасибо за материал.
Главный недостаток дефолтного OVMF — 32х-битность и не совсем честная эмуляция оборудования, но если не пробовать пробрасывать туда железо и отлаживать там VT-d, SGX и подобные вещи, хорошая эмуляция которых будет доступна еще не скоро, то такой подход намного лучше, чем "голый" EDK2.
Заодно порекомендую проект VisualUEFI товарища Ионеску, преследующий те же цели, да еще и 64х-битный.
Дело в том, что криптография — это раздел математики, а не разработки ПО, так что еще до того, как написать первую строчку кода, нужен положительный результат криптоанализа предложенного алгоритма (лучше всего в виде статьи в нормальном журнале, чтобы собрать критику со специалистов), иначе весь этот код — поделка на коленке, а использование такой "потреотичных" реализации — хуже, чем отсутствие шифрования вообще, т.к. дает ложное чувство защищенности.
Бремя доказательства лежит на авторах утверждений вроде "позволяет при сохранении уровня стойкости ограничиваться меньшим числом раундов", так что это не нам всем тут слабо взломать, а вам слабо предоставить не только алгоритм, но и результаты его анализа.
Спасибо огромное за исследования, наконец-то общественности стало известно то, что производители встраемового железа используют уже давно.
Интересно, что раньше этот бит хранился в дескрипторе:
К сожалению, отключать ME ни один производитель систем для широких народных масс (ну, за исключением Purism, наверное) не будет — Интел этот режим не поддерживает, PAVP работать перестает (т.е. HDCP для встроенной видеокарты придется заводить с серьезным таким бубном), да и вообще АНБ не велит не комильфо.
Отвечаю: замыкать надо вывод чипсета HDA_SDO на единицу (т.е. на 3.3В или 1.8В на Атомах). Если удобных площадок нет, надо работать с тем, что есть, но что будет от замыкания шестой ноги на питание — тут я не могу сказать наверняка, это зависит от модели аудочипа.
Добавлю, что в этом режиме дескриптор и все остальные регионы становятся открытыми на запись, а это в свою очередь весьма нехорошо для безопасности платформы. Использовать этот режим нужно только в случае, если регион ME поврежден и нежно его восстановление, а программатора под рукой нет или подключить его слишком сложно (привет новым системам с флешками в корпусе TFBGA24).
Проблема только в том, что добавление любых нетривиальных парсеров на С в прошивку (а парсер NTFS — нифига не тривиальный, там в спецификации рота чертей все ноги сломит) сильно ухудшает безопасность платформы, потому что творчески испорченная флешка может на такой системе обходить SecureBoot, пароль на Bios Setup и черт знает что еще потому, что ФС надо парсить раньше, чем получится проверить загрузчик, который на ней лежит.
FAT потому и потребовали для ESP, что его спецификация весьма несложная, и написать и отладить относительно нормальный драйвер для этой ФС на С все таки можно.
Большая часть промышленных систем х86 как загружалась дедовским 16-битным загрузчиком, так и продолжит загружаться, и менять ради Intel какой-нибудь ткацкий станок Bosch за миллион долларов никто не будет, поэтому производители для Embedded и Industrial вроде Kontron, congatec, Advantec, DFI и т.п. будут поддерживать CSM до последнего патрона, причем такой home-grown CSM будет, скорее всего, еще более кривым, дырявым и глючным, чем то, что Intel поставляет нам сейчас.
С другой стороны, Apple отказались от CSM уже довольно давно, и т.к. на их машинах редко запускали DOS и прочее легаси времен царя Гороха, этого почти никто не заметил. Для большей части нынешних пользователей отказ от CSM пройдет совершенно незаметно — они DOS и не запускали никогда, а в каком режиме процессор стартует и какой интерфейс использует для взаимодействия с прошивкой — 99.9% пользователей решительно пофиг, лишь бы ОС загружалась.
Не нужно бояться слова "мудак", ребят, оно не матерное и хорошо передает смысл на русском языке вместо непонятного в этом контексте "придурок".
По теме же статьи — человеку иногда нужно побыть мудаком минут 10 в неделю, ибо безупречная вежливость и обходительность очень многими воспринимается как слабость.
С другой стороны, нет никакого смысла наказывать за баги — это приведет к только к тому, что о них перестанут сообщать, и начнут открещиваться от них до последнего.
Главный вопрос, на который необходимо ответить после разбора полетов — "как недопустить повторения ошибочной ситуации в будущем?".
Если же человек просто все время ведет себя как мудак — таким лучше сразу желать здоровья и отправлять в свободное плавание, на мой взгляд.
Когда RedHat начнет выпускать прошивки или железо — вот тогда они смогут пропихнуть что-угодно в свои продукты, а пока их ОС ставится на сервера и рабочие станции Lenovo, Dell или HP, их безопасники за одну только идею добавить в прошивку еще один весьма нетривиальный парсер на С любому голову оторвут.
Через мой труп, извините. Иметь драйверы любых файловых систем кроме совсем тривиальных в прошивке — верный способ быть взломанным через втыкание внешнего носителя с творчески испорченной ФС, разбор которой приведет к выполнению вредоносного кода в BDS, а дальше там обход SecureBoot, обход пароля от BIOS Setup, и прочее воровство и убийство.
Вот вам один стандартный формат и драйвер к нему, оба простые как палка — пользуйтесь, городите поверх них любые LVMы, ZFSы, APFSы, что угодно, а прошивке оставьте ее GPT, который просто работает.
Отличная статья, хабр еще торт!
Если серьезно — очень на многих платах до сих пор DCI управляется из переменной Setup (первый способ с HII — это оно и есть), т.е. для его включения в конкретной прошивке нужны всего две вещи — IFR Extractor, чтобы выяснить, по какому смещению в переменной Setup находится эта настройка, и EFI Shell с командой dmpstore чтобы поменять ее.
Эти темные времена — они были всегда и будут всегда, так что это не слухи, а суровая реальность.
Дело там вот в чем: efibootmgr сам по себе ничего не ломает, особенно если менять только переменную BootOrder, как это описано в статье. А вот если пытаться создавать новые записи для загрузчиков или переписывать уже имеющиеся, придется, кроме всего прочего, конструировать EFI DevicePath, и вот здесь у нас получается бомба, поскольку правильность DevicePath зависит от текущей прошивки, и реакция на неправильный также зависит от прошивки. Иногда угадать формат получается и все проходит хорошо, а в других случаях не получается, и восстановление из такого состояния может быть как безболезненным (у AMI Aptio, к примеру), так и очень неприятным (Phoenix SCT), а иногда и вовсе практически смертельным для прошивки (старые Insyde H2O).
Короче: доверьте управление загрузочными устройствами самой прошивке, она точно знает, как именно создать правильные записи BootXXXX так, чтобы ничего не сломалось. Да, это баг в реализации, и в последнее время он встречается не очень часто, но лучше не испытывать судьбу.
Видео оригинального доклада, рекомендую двумя руками:
Отличный материал, спасибо еще раз.
Локализация вообще очень редко освещается в статьях о разработке ПО (просто потому, что большая часть этих статей на английском, и там локализация мало кому нужна), а тут такой подарок.
Отлично, замечу только, что с gST->ConOut и gST->ConIn напрямую стоит работать только в процессе начального обучения, потому что цепочки из X->Y->Z(X->Y, T) сильно замусоревают код и его становится неприятно читать, а читаемость — это, на мой взгляд, вторая по важности характериска кода прошивки после работоспособности.
В реальных приложениях и драйверах обычно используют библиотеку PrintLib, которая превращает кошмарный gST->ConOut->OutputString(gST->ConOut, L"String") во вполне безобидные Print(L"String") или AsciiPrint("String").
Скорее всего, это все будет в следующих частях, ждем с нетерпением.
Пожалуйста, рад что кому-то моя статья помогла.
По поводу нового фреймворка — соглашусь, но новички перестанут быть новичками, и изучать сборочную систему EDK2 им все равно придется, неважно, с чего они при этом начинали, с NT32Pkg, c VisualUEFI, или с какой-нибудь IDE от IBV (я раньше работал с Visual eBIOS, которая сделана из Eclipse, сейчас работаю с Xcode). Визарды — это отлично, конечно, но их быстро перестанет хватать.
Не могу сказать, что лучше начинать прямо с EDK2, как это сделано в моей статье, но точно могу сказать, что работать с EDK2 в любом случае придется, рано или поздно, так или иначе.
Приятно видеть статьи про UEFI на Хабре, спасибо за материал.
Главный недостаток дефолтного OVMF — 32х-битность и не совсем честная эмуляция оборудования, но если не пробовать пробрасывать туда железо и отлаживать там VT-d, SGX и подобные вещи, хорошая эмуляция которых будет доступна еще не скоро, то такой подход намного лучше, чем "голый" EDK2.
Заодно порекомендую проект VisualUEFI товарища Ионеску, преследующий те же цели, да еще и 64х-битный.
Дело в том, что криптография — это раздел математики, а не разработки ПО, так что еще до того, как написать первую строчку кода, нужен положительный результат криптоанализа предложенного алгоритма (лучше всего в виде статьи в нормальном журнале, чтобы собрать критику со специалистов), иначе весь этот код — поделка на коленке, а использование такой "потреотичных" реализации — хуже, чем отсутствие шифрования вообще, т.к. дает ложное чувство защищенности.
Бремя доказательства лежит на авторах утверждений вроде "позволяет при сохранении уровня стойкости ограничиваться меньшим числом раундов", так что это не нам всем тут слабо взломать, а вам слабо предоставить не только алгоритм, но и результаты его анализа.
Примерно из этих соображений некоторые компании не используют никакие сетевые карты Intel в своих продуктах.
Актуально на всех чипсетах Intel, которые поддерживают descriptor mode, т.е. с ICH7 и до самых последних.
Это ничего еще, NVRAM который лежит на флеше — вот где засада.
Спасибо огромное за исследования, наконец-то общественности стало известно то, что производители встраемового железа используют уже давно.
Интересно, что раньше этот бит хранился в дескрипторе:
К сожалению, отключать ME ни один производитель систем для широких народных масс (ну, за исключением Purism, наверное) не будет — Интел этот режим не поддерживает, PAVP работать перестает (т.е. HDCP для встроенной видеокарты придется заводить с серьезным таким бубном), да и вообще
АНБ не велитне комильфо.Отвечаю: замыкать надо вывод чипсета HDA_SDO на единицу (т.е. на 3.3В или 1.8В на Атомах). Если удобных площадок нет, надо работать с тем, что есть, но что будет от замыкания шестой ноги на питание — тут я не могу сказать наверняка, это зависит от модели аудочипа.
Добавлю, что в этом режиме дескриптор и все остальные регионы становятся открытыми на запись, а это в свою очередь весьма нехорошо для безопасности платформы. Использовать этот режим нужно только в случае, если регион ME поврежден и нежно его восстановление, а программатора под рукой нет или подключить его слишком сложно (привет новым системам с флешками в корпусе TFBGA24).