Comments 80
По-моему, лучше добавить такой дисклеймер:
В этой статье не рассматривается написание или доработка самого UEFI. Вне зависимости от представленных скриншотов, здесь будет описано создание некоторого "заменителя" операционной системы (здесь называется загрузчиком): т.е. ВМЕСТО операционной системы будет загружаться ваш код.
-
Почему хочется доработанный дисклейме: из начала статьи создаётся впечатление, что сейчас будет доработка UEFI, сейчас сделаем свой внешний вид настроечных экранов. Нет, такого не будет. Это ни хорошо и не плохо, это немного вводит в заблуждение.
Или, как вариант, не до конца понял статью и её посыл. Тогда примите извинения, и можно побольше раскрыть тему.
Создание процессорной загрузочной операционной системы "Привет МИР", первая итерация.
Ждем продолжения!
Ну, хоть кто-то в 16 лет сейчас интересуется ассемблером и прочими низкоуровневыми вещами, а не сплошными быдлосайтиками или, в лучшем случае, ИИ на пыхтоне :)
Из минусов -- приличное кол-во ошибок в русском языке. Стоило б подтянуть.
Ну, хоть кто-то в 16 лет сейчас интересуется ассемблером и прочими
Я бы не спешил с выводами:
Недавно увлёкся низкоуровневым программированием на Ассемблере и C/C++.
но основной код приведен на Питоне:
Давайте напишем небольшой скрипт на Python Build.py
прикольно!
но основной код приведен на Питоне:
Основной код приведён на C, а на Python написан скрипт для сборки и запуска основной программы.
Нет, основной код -- как раз на сях; на питоне -- вспомогательный скрипт, без которого можно обойтись.
Но настоящая проблема не в том, что молодёжь питон использует, а в... скажем так, узколобо-фанатичном подходе и в крайне узком кругозоре, характерном для очень многих. Тот же ИИ отнюдь не на питоне сделан, вся лежащая в его основе математика написана на других языках, вплоть до фортрана и ассемблера. Но из всех утюгов несётся: питон, питон, питон! (А 10 лет назад неслось: руби, руби, руби!)
Ну, хоть кто-то в 16 лет сейчас интересуется ассемблером и прочими низкоуровневыми вещами, а не сплошными быдлосайтиками или, в лучшем случае, ИИ на пыхтоне :)
Ну, в мои 16 лет просто нечем было чем-то другим интересоваться кроме ассемблера, а не потому что он такой хороший. :)
Примерно то же самое. Правда, ещё и электроника, да и ассемблеры были другими (8086 -- примерно пятый мой ассемблер, от которого я дико плевался, да и сейчас плююсь).
Да понял вам! У 8086 отличный ассемблер в сравнении с MC68000, даже у Z80 нормальный был
Зря минусанули человека, у 8086 действительно неплохая система команд и понятные мнемоники. Но что там в AMD64 уже сложнее))
Она отвратительна -- в частности, из-за неуниверсальности "регистров общего назначения", которые ни разу не общего. Ну а мнемоники почти везде достаточно понятны, а если полистать описание -- то вообще везде.
У 8086 основная проблема в малом количестве неортогональных регистров. 68k тоже имеет такие проблемы (различие A и D), но не настолько жёстко. 68k значительно ровнее в этом плане. Её проигрыш получился фактически через нерыночные факторы - Intel получил госденьги на OoO архитектуру, Motorola такое не смогла.
С другой стороны, 68k была значительно более стиля CISC чем x86, и, например, декодер и конвертер в микрооперации для него оказался бы значительно дороже, чем даже кошмарик x86. Думаю, при переходе на 64 бита они предпочли бы поменять это полностью, сделав реализацию значительно ближе к RISC (или вообще наложив чужой RISC).
Я, кстати, лет в 13 заинтересовался асмом в ~2014-2015 годах и на emu8086 чёт даже писал)) Сейчас освежаю полученные тогда знания и буду пилить игруху на ноутбуке@NickDoom!
Вот спасибо, я как раз хотел спросить, как оно пошло́ :)
Удивительно, но так бы мог выглядеть мир, если бы IBM сделала вместо кассетного бейсика — нормальную поддержку загрузки .COM-файла с кассетного порта! CGA + телек + кассетник, ага :)
Так что это не просто ретро, это маленький кусочек альтернативной вселенной, которой не суждено было состояться в реальности, и я прямо весь жду, как она бы выглядела :)
Мне 30. Опыт программирования те же 14-15 лет. Не вижу смысла в низкоуровневых яп сейчас, если речь не о высоконагруженных системах, требующих наибыстрейшего отклика...
За быдлосайтиками на микросервисах будущее, и оно уже наступило. И за ИИ будущее, и оно тоже уже здесь.
Опечатка понравилась:
Конечно есть некоторые люди которые что-то писали о об этом, но их очень мало, а те что есть, показались мне уж слишком сложными и малопонятными.
Получилось: некоторые ЛЮДИ показались уж слишком сложными и малопонятными, те что есть :)
Интересно. Но в разделе про bios немного притянуто. Во первых bios с поддержкой uefi может выглядеть точно так же как обычный bios. это касается и п.4 - все зависит от того как написан bios Остальные недостатки это скорее неудобства, но вполне решаемые дополнительной прослойкой. uefi это просто встроенная прослойка, которая пытается что то стандартизировать с одной стороны, но с другой - загнать в узкие рамки. в результате мы компилируем .exe под linux для того что можно было бы уместить в 512 байт загрузчика на ассемблере
Еще важно дополнить то, что UEFI имеет режим работы Legacy. А вот как он его реализовывает - вопрос интересный. Поскольку сам UEFI работает в x64, предположительно, для легаси он входит в режим v8086. А может и банально эмулирует всё до момента фактического перехода в Protected-режим процессора.
@dlinyjне хотел бы поизучать эту тему и запилить статью7
у меня подозрение что за много времени ни чего не поменялось. Просто UEFI натянут на обычную загрузку.
Но могу ошибаться, это всего лишь моё предположение. Надо будет покопаться в исходниках и посмотреть так ли это. Хотя, может народ уже копался и знает без меня? Ведь UEFI существует не первый год.
В V86 он войти не может, насколько помню: поддержка V86 выпилена из 64-разрядного режима. Хотя за IA-32/AMD64 уже много лет не наблюдаю, так что могу и ошибаться.
Но ничто не мешает 64-разрядному коду переключаться в 32-разрядный режим, где тот же V86 благополучно поддерживается из-за совместимости.
UEFI имеет режим работы Legacy
уже почти «имел».
попадаются мамки, на которых нет legacy. и интел уже опубликовал новую версию архитектуры, в которой 16-битного режима не будет вовсе
Это довольно большой шаг. Может, дане новую архитектуру не постигнет судьба италиума.
The X86-S mode would require booting CPUs directly into 64-bit mode and also allow for some fundamental changes like being able to switch to 5-level paging without leaving a paged mode.
Among Intel's expressed benefits for a 64-bit mode-only architecture is removing ring 1 and 2, dropping 16-bit addressing support, eliminating ring 3 I/O port accesses and the string port I/O, simplified segmentation model, and removing some unused operating system bits.
Under this proposal, those wanting to run legacy 32-bit operating systems would have to rely on virtualization. To further clarify, 32-bit x86 user-space software would continue to work on modern 64-bit operating systems with X86-S.
@dlinyjне хотел бы поизучать эту тему и запилить статью7
Хватит меня тегать при каждом удобном случае. Не хотел бы.
Круто! Начало положено.
Теперь дальше можно рассказать о взаимодействии с прошивкой и выполнении основных операций - чтение/запись диска, ввод с клавиатуры, может работа с экраном. В общем то, что раньше обеспечивали всякие int 10h, 15h и т.д.
Спасибо! Возможно выпущу продолжение этой статьи, тема очень интересная.
Еще более интересная (мож, не только мне?) тема:
какого лешего разные версии Убунты (и 10, и 22-версии) лезут в мои разные БИОСы без EFI и с ней, чтобы всё там перекорежить для послед. загрузки виндовс.
Я понимаю, что место выбрал для таких вопросов неподходящее, но я тут мимокрокодил на другую тему, кхе-кхе...
Как понять лезут ? Им лазить вБиос не надо, хватает простого указание пользователя что будет загрузчиком MBR или загрузочная запись раздела.Для геометрии диска есть стандартный вызов по прерыванию, все .
Телепат мод по проблеме: скорее всего у тебя кривой подраздел ACPI .Некоторые производители реализовывают под операционки оптимизированные таблицы, стандарт позволяет.В общем узнаешь есть ли обновление Биоса,кривые таблицы в последний очередь чинят (смотришь багофиксы) и узнаешь либо через утилиты,либо через linux декодер acpi (не помню точное название утилиты) какие таблицы у тебя в биосе есть,прописываем в загрузчике в опциях- либо стандартную таблицу либо версию под виндовс.
Я не знал заранее, получу ли ответ здесь, поэтому сократил до "лезет".
Подробности 2-х случаев далее.
кривой подраздел ACPI
Два очень разных производителя: совпадение возможно, но мне проще БИОС сбрасывать каждый раз после...
бук Lenovo SL-500: ссылок навалом, поэтому их даже не привожу.
После загрузки Убунта-10 с ЮСБ и послед. загрузки винХР со встроенного HDD
у винХР стабильно "слетает" драйвер слота карты памяти, подключенный не через юсб внутри, а как-то иначе - и поэтому же он "незагрузочный".
Т.е. винХР предлагает установить драйвера для нового обнаруженного устройства.
Помогает повторная установка драйвера "как в первый раз".
НЕ помогает поиск драйвера среди установленных ранее, хотя он же был установлен!!111нечто "феноменально" дешевое под именем
Evolve III Maestro E-Book 11.6" - это было в Америке на короткой распродаже.
Аналогичными буками торгует в России DIGMA, а недано и Яндекс Маркет под своей (тм)
Вот богатая тема
https://old.reddit.com/r/linuxhardware/comments/tk6hdp
но там юзеры пользуются этим каждый день, НАВЕРНОЕ, поэтому не заметили у себя мой кейс:
в полностью выключенном состоянии
батарея начинает садиться на 11% в ДЕНЬ
после загрузки Убунта-22 с ЮСБ
Помогает сброс настроек БИОС в заводские, после чего
в полностью выключенном состоянии
батарея садится на 3% в НЕДЕЛЮ. Штатно установлена вин10, но рядом есть кастрированная вин10 с отключенными обновлениями (как заявлено мододелом). Т.о. "полностью выключенное состояние" происходит из кастрированной вин10, и имхо за "день хранения" нет попыток самообновления, о которых про вин10+ слагают легенды с большим количеством мата.
Если эти кейсы можно объяснить как-то иначе - заранее благодарю.
да обычные, активно рекламируемые блоГерами Т-Бао. там батарея от блока питания не развязана никак. т.е. подключен блок питания, на его плате выходного напряжения светодиод горит, да и сама конструкция внутри то ещё загонялово в аппаратном смысле. сборище дешёвых решений, без развязок и прочего.
просто купил осенью 22 года и позже заметил - неделю полежит - батарея - 0%, стал смотреть что да как... волосы до сих пор шевелятся.
Спасибо за быстрый ответ, но до Убунты-22 у меня 1.5 года не было проблем с разрядом батареи.
Сначала штатная вин10 была неактивирована и все лежало в запечатанной коробке - у меня руки не доходили, после установки кастрированной вин10 я выключал на хранение только из нее.
Скорость разряда на хранении описал выше: имхо вполне норм для такой распродажи.
могу предположить что это все как то связано со сменой привязки часов к UTC, в linux и windows разница 3 часа, тогда они переустанавливаются при каждой загрузке ОС, и да - пишутся в настройки bios. В общем то да - это уже "лезет", но и винда тоже.
первый случай несколько неоднозначно связано с bios - это надо почитать детальнее. картридер в ноутах бывает еще подключается по pcie. как может повлиять смена часов на драйвер - не знаю.
а вот во втором случае прямо уже любопытно - может какая то настройка bios прям "сама" меняется? что это видно в меню и ее сброс помогает. вполне возможно что это чтото из настроек энергосбережения, может даже bios косячный, а может - опять же смена часов как то влияет, в порядке бреда - какой то контроллер показания часов использует.
картридер в ноутах бывает еще подключается по pcie
да, в SL-500 именно так
как может повлиять смена часов на драйвер - не знаю.
в БИОС есть фича отключения конкретно этого слота, но я не проверял "слетание драйвера" после ручного передергивания этого в БИОС
во втором случае прямо уже любопытно - может какая то настройка bios прям "сама" меняется? что это видно в меню
а тут в БИОС настроек так много, что мне не по плечу отслеживать их все, тем более что часы не сбрасываются после сброса БИОС, хотя RTC-batt там точно нет
тут выше https://habr.com/ru/articles/798587/comments/#comment_26594009
у кого-то точно так же батарея садилась в момент, причем докладчик понимает в схемотехнике - в отличие от меня, но ему даже не пришло в голову сравнить саморазряд батареи в отключенном от матери состоянии, а также не пришло в голову элементарное соображение: за время доставки с фабрики до покупателя в сроки в разы более долгие, чем неделя, батарея не села ни у кого даже на Реддит (там куча участников с большим интервалом дат покупки и даже 2 разных типов: с доп. слотом для второго SSD (на самом деле изначально там стоИт LTE-modem) или без него), т.е. явно батарея начинала садиться быстро только после начала использования бука, откуда прямая дорога к моему открытию "для лечения - сбросить БИОС".
Но мой изначальный вопрос: нафига Убунта такая разрушительная в отличие от Винды, для меня все еще мутен.
да я примерно понимаю ситуацию, но пока что это в какой то степени шаманство. в моем понимании "лезет" когда видно что да сменилась настройка, вероятно я бы реально все пункты перепроверил. чисто технически можно отслеживать записи в bios, но помимо bios в ноуте стоят всякие контроллеры с фирмварями которая линукс тоже дергает, причем на свой вкус и иногда даже не по документации (ее нет). ну и так это все таки как бы узкие случаи а не повсеместная проблема.
это в какой то степени шаманство.
да, но проверенное веками и толпами юзеров. Это второе универсальное средство после "перезагрузка"
я бы реально все пункты перепроверил
там слишком много экранов: скриншотить их снаружи камерой смарта "до" и "после", после чего сравнивать "на глаз"? Мне явно проще ресет делать после загрузки убунты - каждый раз, которые у меня редки
чисто технически можно отслеживать записи в bios
как и ковырять таблицы ACPI - мне такое явно не по плечу
все таки как бы узкие случаи а не повсеместная проблема.
на Реддит большинство громоздило пингвинов на это чудо для юзания от блока питания, а потому могли и не заметить,
а здесь, в этой явно непрофильной теме, нас таких уже двое.
На форумы ДИГМЫ как давнего и массового продавца этого продукта, надежды нет: я тупо не нашел там ничего похожего на "обсуждение продукта", а мож даже и форума там нет - не помню уже: давно крест поставил.
ИТОГО:
у этого продукта "дочь явная проститутка, несмотря на то, что официально заявлены только сыновья" (с)
линукс дергает на свой вкус и иногда даже не по документации (ее нет)
а это исчерпывающий для моего уровня ответ для описанного случая с Леново
Диагностики понятно дело должен делать производитель железа, но этому особо не cдалось и вообще частенько обещают только работу с windows. Но и винить во всем Linux тоже както перебор
винить во всем Linux тоже както перебор
не "винить", а пытаться понять.
Тут недавно был перевод статьи про запредельное ЧСВ у разрабов Гнома - "внушаить!".
Вот и в случае деструктивного влезания в БИОС мне интересно: даже если руки кривые, то какова была цель?
У меня бывали случаи в разных областях, когда мое копание в непонятных моментах проясняло мне то, о чем я даже вопроса задать не мог, без которого и ответа АКА полезных мне знаний не получить.
Вот и тут мой интерес такой же: а вдруг там у Сени не перелом, а золото-бриллианты? (с)
что вообще означает "лезут"? не то чтобы совсем нельзя но это явно не тот случай когда "само"
ответил выше https://habr.com/ru/articles/798587/comments/#comment_26593979
Заранее спасибо!
Протоколы UEFI заметно попроще как я понял :) Всё таки основная сложность BIOS-вызовов в необходимости реализации v8086 режима для вызова нужных прерываний, но это медленно и приходится реализовывать стек для работы с PCI, ATA-контроллерами и даже флоппаводами!
Питоновский скрипт здесь явно лишний, хватило бы строк десять в уже существующем makefile. А так поздравления с первым работающим кодом!
Теперь ждём такую же статью не на Си, а на Расте.
Вдруг кого заинтересует написание мини ОС на rust. Правда там грузят через bios, если память не изменяет. Заодно можно помочь проекту с uefi
Вот более современная сборка под таргет *-unknown-uefi
Спасибо! Скрипт и в правду можно было легко написать и в Makefile, об этом я как-то не подумал.
Вставлю еще пару копеек, на что можно посмотреть, делая что-то под UEFI
EfiGuard - отключает PatchGuard до его фактического запуска в Windows (от 7 до 11), плюс DSE фикс - разрешает загрузку неподписанных драйверов без тестового режима
SecureFakePkg - эмуляция Secure boot без его фактического включения
rainbow - подмена идентификаторов оборудования
efi-memory - оставляет хук для чтения/записи памяти, вызова функций в KernelMode
rainbow - подмена идентификаторов оборудования
Любопытно, я правильно понимаю что это поможет в случаях когда некоторые производители огораживают список возможных компонентов белым листом (привет фирме леново)?
Или все не так просто как кажется?
Установим и скомпилируем GNU-EFI:
Что он делает, зачем он нужен? Было-бы хорошо это расписать хотя-бы в паре строк. Я конечно понимаю что это библиотека стандартных функций но хотелось-бы поподробней.
Ещё нам понадобятся файлы OVMF_CODE.fd и OVMF_VARS-1024x768.fd.
То-же самое. Зачем они нам нужны? Может и без них у нас все получится?
Люди которые читают вашу статью могут не располагать знаниями которыми располагаете вы и это нужно учитывать.
Ну и выбор тулчайна надо осветить все-таки там столько видов бывает (есть eabi есть noneabi) например.
Ну экскурс в BIOS - полный провал. Лучше было его и не делать вовсе.
Никакой такой загрузки с дисков BIOS вообще не подразумевает. BIOS не знает файловых систем в принципе (в отличии от UEFI - тот FAT32 знает и может драйвер любой другой FS подрузить). BIOS тупо загружает первый сектор с самого первого (по приотритету загрузки) диска и передает ему управление. Далее все зависит от того, что там написано в первом секторе. И да - никто не мешает в первые 512 байт написать загрузчик следующих секторов диска, который позволит реализовать первичную загрузку уже не так сильно ограниченную одним сектором (так, например, GRUB умеет делать). Ну а далее при желании можно и GPT разметку заюзать и загрузится уже с любого диска (забыв про MFT секцию первого сектора как про страшный сон).
Вот только такая загрузка - жутко небезопасна... и вся верификация - это проверка двух байтов в конце первого сектора - если там правильная последовательность бит, то такой сектор автоматически считается правильным, грузится и запускается...
Но остальной материал - вполне годно.
С UEFI вообще забавно, стандарты не читал, но большинство материнок просто ищут файл на первом разделе жёсткого диска по пути /EFI/BOOT/BOOTX64.EFI и запускают его на выполнение (справедливо для x86_64, для других архитектур другие имена). Даже ядро линукса давно умеет грузиться в UEFI.
The EFI Boot Stub
On the x86 and ARM platforms, a kernel zImage/bzImage can masquerade as a PE/COFF image, thereby convincing EFI firmware loaders to load it as an EFI executable.
Даже существуют утилиты, которые соберут вам в один EFI-файл initrd+kernel linux (даже без загрузчика!) и это просто будет запускаться с флешки, по факту являясь файлом-прошивкой для архитектуры x86_64.
зачем какие-то утилиты? ядро штатным способом умеет собираться с initrd внутри, ну а про то, что оно может быть собрано (и обычно собирается) как приложение efi, вы уже написали
все так только ядро нужно специально собранное и желательно подписанное, что бы secure boot и все такое.... Правда еще и ключик для верификации подписи нужно в UEFI занести (что иногда и не так просто бывает).
все так только ядро нужно специально собранное
не поленился, нашёл патч, который добавил efi stub в defconfig:
https://lore.kernel.org/all/20200724130638.645844-2-mingo@kernel.org/
4 года как (и то, у меня есть подозрение, что массовые дистрибутивы начали собирать ядро с efi stub ещё раньше)
Да все так, и некоторые дистрибутивы даже сразу такое ядро ставят со связкой SHIM -> GRUB -> kernel+initrd. Первый при этом подписан ключом от M$, который есть в UEFI практически любого компа. Shim же умеет работать с о своей связкой ключей которая уже содержит ключик для GRUB и ядра.
Только вот такой велосипед на 13 колесах и прячет под капотом большинство дистрибутивов.
Но при этом из UEFI можно грузить сразу ядро или даже несколько версий ядер (UEFI в принципе содержит вполне полноценный boot loader). И если нужный ключик доложить в хранилище ключей UEFI то можно грузить да;е в режиме Secure Mode (c проверкой подписи).
Собственно я даже скриптик для UBUNTU накидал для реализации автоматического обновления бутлоадера UEFI при получении нового ядра или удаление старого через стандартный менеджер пакетов (apt): https://github.com/slytomcat/UEFI-Boot
да давно ли мы видим свежие вирусы в mbr :) разучились уже писать такое
И да - никто не мешает в первые 512 байт написать загрузчик следующих секторов диска, который позволит реализовать первичную загрузку уже не так сильно ограниченную одним сектором
более того, все загрузчики так и устроены
BIOS тупо загружает первый сектор с самого первого (по приотритету загрузки) диска и передает ему управление.
Если быть финально точным - бывали BIOS, которые пытались лезть в эту тему, особенно в районе конца 1990-х. Для них в загрузочных секторах файловых систем рисовали фиктивные FAT BPB, без которого могло молча отказаться грузить. Чем более "вендорский" комп, тем это вероятнее. Практически исчезло под давлением наличия альтернативных систем вроде Linux.
Вот только такая загрузка - жутко небезопасна...
Этого не понял. Чем она небезопасна, если диски подключить по ATA/SCSI/etc. это явное действие, после которого надо пересчитать загрузку, а всякие USB требуют явного вызова boot menu?
Oxide наоборот решили уйти от UEFI в пользу управляющего микроконтроллера и довольно разумно это обосновывают (с учётом вертикальной интеграции).
А можно вообще не загружать операционную систему, а запускать скрипт или сервис (например веб-сервер) через UEFI?
Можно. Были даже примеры простых игр (уровня Pacman) как (U)EFI бинарей.
Проблема в том, что это отдельная платформа со своей спецификой, и что-то большое разрабатывать под неё тупо нет смысла. Вам придётся сделать свой R/W драйвер целевой FS, свою поддержку мультипроцессности в нужном стиле, достаточно богатое API для работы такого сервиса, сделать все нужные драйвера включая сетевой (EFI может его не предоставлять)... сама модель EFI ориентирована на простоту (ну, как её понимает Intel) и надёжность процесса, а не на скорость... с какого-то момента будет понятно, почему если "за морем телушка - полушка, да рубль перевоз", то грузить Linux с диска дешевле во всех смыслах:)
Для запуска внутри уефи вам надо будет писать свой уефи загрузчик, с блекджеком и дефками, и затем прошить его в вашу плату.
вы что-то не то написали.
uefi по сути небольшая операционная система (ну как небольшая, уровня ms dos). она умеет запускать свои приложения (внутри, сюрприз, MZ/PE).
бутлоадер или efi shell — просто примеры таких приложений.
кладёте любое приложение на флешку в EFI/BOOT/BOOTx64.EFI, выбираете загрузку с этой флешки и ваше приложение запустится.
(в общем-то примерно это в статье, под которой идёт обсуждение, и написано)
Создание своего UEFI приложения