Вы путаете CSM и легаси-загрузку. CSM — это вообще наличие интерфейса BIOS Interrupt Call, 16-битных обработчиков прерываний, BDA/EBDA и всего такого, а легаси-загрузка — это использование вот этого всего для загрузки 16-битного кода из MBR.
Почти все современные ПК по умолчанию используют UEFI-загрузку, но CSM при этом не отключают, и в DOS с флешки на них все еще можно загрузиться без необходимости идти в BIOS Setup и включать его специально.
Нет, они там все поддерживают дух старой школы. Пользователь ожидает от х86-совместимой системы поддержки всех наколенных за 30 лет ее развития костылей, каких-нибудь сумашедших ресетов через порт клавиатуры (который эмулируется теперь при помощи бубна и такой то матери) и управления адресной линией А20. Без этого всего — это уже не IBM PC, и некоторым категориям пользователей от этого очень грустно. Вон выше даже Meklon продолжает использовать CSM и легаси-загрузку, т.к. она «просто работает», а то что для ее работы разработчики прошивок каждые полгода через ад проходят — этого никто не видит.
Пацаны там, конечно, вообще ребята, но идея переписать PEI потому, что мы можем — она очень плохо сочетается с современными реалиями. Ни один производитель нормальных х86 процессоров код иницилизации своего оборудования просто так не отдаст (я не знаю, чего они там все боятся, но вот так), а реверсить его можно до ишачьей пасхи, и к моменту, когда тренировка памяти наконец-то заработает, платформа успеет 10 раз устареть.
Идея заменить фазу DXE на Линукс — она в принципе не плохая, особенно для ребят вроде Гугла (проект NERF), которые в Линукс уже умеют, а в DXE — еще не сильно, но на таких системах кроме линукса в итоге ничего толком и не запустишь, а если снова начинать реализовывать SMBIOS, ACPI, SMM и UEFI — есть неплохой шанс, что снова получится DXE, только теперь уже местного разлива. Если их там NIH не разбил в самое сердце — пусть лучше TianoCore пилят, на мой взгляд.
Ext3 было бы довольно трудно внедрить в самом начале, потому что на тот момент Intel плотно работал над спецификацией вместе с MS, и люди просто использовали то, что знали. Зато стремление Интел открыть код нормально вывело FAT из под угрозы патентного преследования, правда случилось это буквально пару лет назад, а до этого драйвер поставлялся в бинаре, под отдельной лицензией и в отдельном репозитории.
Это потому, что по умолчанию почти на всех нынешних ПК (за исключением совсем новых топовых систем Dell, HP, Lenovo и MS, и продукции Apple последних трех примерно лет) CSM включен по умолчанию и его никто не выключает, потому что для этого надо в настройки лезть.
Самое смешное, когда CSM оказывается включен по умолчанию на системах с процессорами Intel Kaby Lake и новее, для которых для ОС старше Windows 10 и драйверов то толком нет, и не осталось никаких уже причин иметь включенный CSM, ведь видеокарту внешнюю туда можно воткнуть только в порт USB-C/TB3, но нет, инерция мышления IBV (в данном случае — AMI) сильна как никогда, а Intel пофиг — ОС загружается, что еще надо, а то, что у вас умолчания ничего общего с безопасностью не имеют — значит она вам и не нужна.
Оно там все кривое просто потому, что сам интерфейс BIOS IC — кривой как бараний рог, даже безотносительно безопасности.
Про матрешка-процессоры — то ли еще будет, про Integrated Sensor Hub как-то все молчат в тряпку, хотя там точно такое же ядро Quark, как и то, на котором МЕ исполняется, и его тоже можно использовать для каких-то своих интересных целей, если влом ставить свой копеечный АРМ вместо EC.
Выше ответил, изображения не будет в лучшем случае до загрузки видеодрайвера, в худшем — все зависнет намертво еще на загрузке. Отключите Legacy Boot целиком и посмотрите, как Windows 7 отреагирует на это, даже будучи запускаемой через bootmgrfw.efi
Вот этот пункт с мутным названием, скорее всего, и отключает CSM полностью.
Что подразумевает: CSM — это реализация старого интерфейса BIOS Interrupt Call, в том числе прерывания 10h, которое используется для работы с видеоадаптерами.
При отключенном CSM никакие обработчики прерываний BIOS не инициализируются (потому что они 16-битные, и работа с ними на современной 64-битной системе — очень сильное колдунство), в том числе не инициализируется VideoBIOS и не выделяется legacy VGA framebuffer, расположенный по физическим адресам A0000-BFFFF, поэтому все, что его раньше использовало для вывода на экран, теперь ничего никуда не выводит.
Нормальные EFI-совместимые загрузчики могли бы просто переключиться на использование EFI-протокола Graphic Output Protocol (GOP) и выводить свои веселые картинки при помощи GOP->Blt(), но в MS решили, что для Windows 7 это все реализовано не будет по каким-то своим причинам, возможно объективным, а возможно и сугубо политическим.
Не, там скорее драйвер в прошивке, ОЕМы его любят.
Проблема только в том, что добавление любых нетривиальных парсеров на С в прошивку (а парсер 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х-битный.
Почти все современные ПК по умолчанию используют UEFI-загрузку, но CSM при этом не отключают, и в DOS с флешки на них все еще можно загрузиться без необходимости идти в BIOS Setup и включать его специально.
Нет, они там все поддерживают дух старой школы. Пользователь ожидает от х86-совместимой системы поддержки всех наколенных за 30 лет ее развития костылей, каких-нибудь сумашедших ресетов через порт клавиатуры (который эмулируется теперь при помощи бубна и такой то матери) и управления адресной линией А20. Без этого всего — это уже не IBM PC, и некоторым категориям пользователей от этого очень грустно. Вон выше даже Meklon продолжает использовать CSM и легаси-загрузку, т.к. она «просто работает», а то что для ее работы разработчики прошивок каждые полгода через ад проходят — этого никто не видит.
Идея заменить фазу DXE на Линукс — она в принципе не плохая, особенно для ребят вроде Гугла (проект NERF), которые в Линукс уже умеют, а в DXE — еще не сильно, но на таких системах кроме линукса в итоге ничего толком и не запустишь, а если снова начинать реализовывать SMBIOS, ACPI, SMM и UEFI — есть неплохой шанс, что снова получится DXE, только теперь уже местного разлива. Если их там NIH не разбил в самое сердце — пусть лучше TianoCore пилят, на мой взгляд.
Самое смешное, когда CSM оказывается включен по умолчанию на системах с процессорами Intel Kaby Lake и новее, для которых для ОС старше Windows 10 и драйверов то толком нет, и не осталось никаких уже причин иметь включенный CSM, ведь видеокарту внешнюю туда можно воткнуть только в порт USB-C/TB3, но нет, инерция мышления IBV (в данном случае — AMI) сильна как никогда, а Intel пофиг — ОС загружается, что еще надо, а то, что у вас умолчания ничего общего с безопасностью не имеют — значит она вам и не нужна.
Про матрешка-процессоры — то ли еще будет, про Integrated Sensor Hub как-то все молчат в тряпку, хотя там точно такое же ядро Quark, как и то, на котором МЕ исполняется, и его тоже можно использовать для каких-то своих интересных целей, если влом ставить свой копеечный АРМ вместо EC.
Что подразумевает: CSM — это реализация старого интерфейса BIOS Interrupt Call, в том числе прерывания 10h, которое используется для работы с видеоадаптерами.
При отключенном CSM никакие обработчики прерываний BIOS не инициализируются (потому что они 16-битные, и работа с ними на современной 64-битной системе — очень сильное колдунство), в том числе не инициализируется VideoBIOS и не выделяется legacy VGA framebuffer, расположенный по физическим адресам A0000-BFFFF, поэтому все, что его раньше использовало для вывода на экран, теперь ничего никуда не выводит.
Нормальные EFI-совместимые загрузчики могли бы просто переключиться на использование EFI-протокола Graphic Output Protocol (GOP) и выводить свои веселые картинки при помощи GOP->Blt(), но в MS решили, что для Windows 7 это все реализовано не будет по каким-то своим причинам, возможно объективным, а возможно и сугубо политическим.
Проблема только в том, что добавление любых нетривиальных парсеров на С в прошивку (а парсер 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х-битный.