Комментарии 19
Круто, очень круто👍
Исторически так сложилось, что при включении питания процессор находится в так называемом Real Mode.
По моему это не "исторически сложилось" а необходимо для обратной совместимости. Ведь если мы захотим запустить старую ОС которая ничего не знает про защищенный режим, то по другому ничего не получится.
Ну я бы немного возразил, запустить DOS на современном компьютере, у которого нет Legacy Mode, придется с ухищрениями, и, думаю, без загрузки эмулятора ничего не выйдет. Поправьте, если я ошибаюсь.
Из real-mode процессор как раз переключается в защищенный режим с помощью Uefi. Зашьете другой загрузчик, который этого не делает - останетесь в реал-моде. Разве что режим с 16-битового на 32-битовый поменяете для удобства.
Лично на интеловую плату зашивал ABL(Advanced Bootloader или как то так), который только настраивал периферию, но плату оставлял в реал-моде, в защищенный его переключала уже стартуемая ОС. т.е. эмуляторов никаких тут не было, просто другой загрузчик.
Обратной совместимости тут и так нет. Под каждую платформу - а это, считай, поколение или несколько процессоров на одном чипсете, и один вендор материнок - BIOS (legacy или UEFI) дорабатывается, потому что меняются такие особенности, как, например, строить связи кэшей между ядрами и процессорами, управлять периферией типа вентиляторов, итд итп. Это, конечно, не весь код, его малая часть, но критически существенная.
Если бы какой-то следующий процессор стартовал в 64-битном защищённом режиме, но мог переключаться в реальный для тех, кому ещё нужен старт в старом режиме - то совершенно не было бы проблем это сделать. Старые BIOS с начала 90-х и так одно из первым что делают - входит в защищённый режим, чтобы настроить плоскую адресацию на 4GB размер, и выходят обратно. Можете почитать про это книгу "BIOS disassembly ninjutsu uncovered", есть и русский перевод (2007-й год). Ну делали бы выход без входа, проблем-то.
(Остановленный совсем недавно проект X86S исключал реальный режим вообще и оставлял сразу старт в 64-битном защищённом режиме. Для 99% современных ОС разницы бы не было. Но это уже следующий шаг.)
Класс!
Отлично изложено!
Рад, что оказался полезен.
Статья огонь! (не пойму правда почему нельзя оставить коммент отдельно и приходится писать в ответ на ваш коммент. это опять какаято хабраособенность связанная с кармой?)
Начну с простго глупого вопроса.)
Скажите. Я правильно понимаю что в отличии от винды, ядро линукс уже содержит загловок efi и как бы для него прозрачно(ну т.е. такой efi загрузчик на стероидах)? А у винды загрузка возможна из UEFI только через прмоежутчный efi файл загрузчика.
Т.е. вашему загрузчику по идее точно также можно скормить эти маленькие файлы efi =) или я ошибаюсь?
Да, Вы правильно понимаете.
Уточню на всякий случай.
Eсли ядро Linux скомпилировано с установленным параметром CONFIG_EFI_STUB, то оно является валидным UEFI Application. И его можно запустить как из ЕFI Shell так и непосредственно из Boot Managera. Я такое же ядро с EFI Stub запускал как из своего загрузчика ( протокол загрузки chain load), так и прописывая загрузочные записи в NVRAM UEFI. Файл ядра Windows не является UEFI приложением, поэтому небходимо сначала передать управление Bootmgfw.efi, который подготовит и загрузит ядро и передаст ядру управление.
Если Вы имеете ввиду, что можно ли моему загрузчику для протокола загрузки chainload указать вместо vmlinuz - Bootmgfw.efi, то я не проверял, так как не углублялся в особенности загрузки Windows в статье, но теоретически это должно работать. Может придется чуть подправить код загрузчика в плане обработки конфигурационного файла.
Спасибо за статью!
А можно из 64-бит UEFI загрузить 32-х битную ОС?
Действительно хорошая статья.
А никому не попадалась такого же уровня статья для ARM64?
что современные ядра Linux являются валидными UEFI-приложениями
Да мы поняли, поняли!
🫶
Спасибо, познавательно!
Пишем свой загрузчик операционной системы Linux