Раскрываем секреты загрузочных ISO-образов

В этой статье я хочу поговорить об ISO-файлах, на которые, как известно, распространяются дистрибутивы операционных систем. Начиная писать статью, я немного сомневался в её актуальности, так как я ассоциировал ISO-образы с оптическими дисками, которые, ввиду ряда причин, уходят в прошлое. У меня было стойкое понимание, что ISO-файлы в основном нужны только для хранения образов оптических дисков, которые содержат установщик операционной системы. Но, как оказалось, всё гораздо сложнее и интереснее, особенно применительно к современному железу.

Если у вас нет много времени читать эту статью или набирать исходный код и команды, вы всегда можете найти на GitHub мой проект с исходным кодом, который можно запустить и поэкспериментировать с ним.

Также у меня была статья на Хабре, где я затрагивал тему загрузочных ISO, но не вдавался в подробности реализации.

Что вы найдёте в этой статье

Не знаю, как для кого, но для меня лучше всего запоминается то, что ты сам попробовал на практике, когда ты сделал немало ошибок, чтобы разобраться с темой. Поэтому мой рассказ о загрузочных ISO-образах будет совмещён с практикой.

Для лучшего понимания материала стоит рассматривать тему на простых воспроизводимых примерах, а потом, разобравшись в основах, разбирать более сложные вопросы. Поэтому я, как и в предыдущей статье, создал минимальный пример, который, с моей точки зрения, достаточно хорошо раскрывает тему загрузочных образов ISO.

После прочтения этой статьи вы сможете создать универсальный загрузочный образ ISO, который можно будет записать на оптический диск, внешний жёсткий диск или флеш-накопитель так, что при загрузке с него будут выполняться минимальные программы Hello, World, никак не зависимые от операционной системы. Эти программы можно считать заглушками для реальных загрузчиков операционных систем. Пример из статьи позволит вам разобраться со структурой загрузочных ISO-образов и улучшит ваше понимание процесса загрузки компьютера (bootstrapping).

Немного теории, которую необходимо знать

Как известно, теория без практики ничего не значит, справедливо и обратное утверждение. Поэтому приведу немного теории, которая позволит лучше понять, что же вы делаете.

Загрузка операционной системы на компьютере x86

При включении питания компьютера процессор сразу начинает выполнять команды. Первые команды, выполняемые процессором, принадлежат предустановленной программе, которая располагается в ROM памяти на материнской плате компьютера. Основное назначение программы – базово проверить компьютер на ошибки, проинициализировать часть устройств для дальнейшей загрузки и передать управление загрузчику, предоставив программный интерфейс для взаимодействия с собой.

Существует два вида программ, располагающихся в ROM — BIOS (Basic Input/Output system) и UEFI (Extensible Firmware Interface). Обычно компьютеры с UEFI позволяют эмулировать BIOS, если выбрать опцию Legacy Mode.

Механизм загрузки BIOS (Legacy)

BIOS не имеет никакого представления о файловых системах, установленных на устройствах, с которых осуществляется загрузка. Он рассматривает устройства как блочные, которые могут возвращать блоки данных (сектора), располагающиеся по определённым LBA (Logical Block Address). Ранее дисковые устройства ещё имели режим адресации CHS (Cylinder, Head, Sector), который был более близок к физической геометрии жёстких дисков, но сейчас он практически не используется.

Если данные удовлетворяют определённому критерию, BIOS загружает их в память, рассматривает их как программу и передаёт ей управление.

Эта программа может работать с устройствами компьютера через специальный интерфейс на основе программных прерываний. Она обычно пишется на ассемблере.

Когда BIOS передаёт управление, то процессор x86 находится в реальном режиме, а это значит, что в программе можно обратиться только к 1МiB оперативной памяти и, если вы хотите использовать всю оперативную память, то необходимо позаботиться о том, чтобы перевести процессор в защищённый режим. Такие загрузчики, как GRUB 2, как раз это и делают.

Механизм загрузки UEFI

UEFI знает о файловой системе FAT. При загрузке с устройства UEFI пытается найти на устройстве раздел с этой файловой системой и исполняемый файл UEFI в ней, после чего запустить его на выполнение.

Программа, находящаяся в исполняемом файле, может взаимодействовать с UEFI при помощи специального программного интерфейса, который использует так называемые сервисы UEFI. Она обычно пишется на языке высокого уровня С или C++.

Когда UEFI передаёт управление программе, то процессор находится в защищённом режиме, и из программы вы уже можете обращаться ко всей оперативной памяти, которая присутствует на компьютере.

Загрузка с жёсткого диска или флеш-накопителя

Загрузка с жёсткого диска или флеш-накопителя в большинстве случаев подразумевает, что они размечены на разделы, а на одном или нескольких разделах находятся загрузчики и операционные системы, которые необходимо загрузить. Мне известно о двух видах разметки: MBR (Master Boot Record) и GPT (GUID Partition Table).

MBR – более ранний способ разметки, подразумевающий разметку диска на 4 первичных раздела. Существует способ увеличить общее количество разделов за счёт создания так называемых расширенных разделов, но загрузка с таких разделов усложняется.

GPT – современный способ разметки, подразумевающий разметку диска на большое количество разделов и поддержку дисков размером более 2TiB.

На просторах Интернета существует очень распространённое заблуждение, которое заключается в том, что на компьютерах с BIOS используется ТОЛЬКО MBR-разметка, а с UEFI TOЛЬКО GPT-разметка. Это неверно.

BIOS не имеет понятия как о GPT, так и о MBR, он только знает о том, что нужно загрузить и выполнить программу, находящуюся в нулевом секторе, если этот диск является загрузочным и последние два байта в секторе равны 55AAh. Но если в результате будет передано управление загрузчику, который «понимает» GPT, то последний сможет загрузить операционную систему с раздела GPT. Разумеется, сама операционная система должна поддерживать GPT-разметку. Но даже если она не поддерживает GPT, в нулевом секторе можно разместить таблицу разделов MBR, которая будет указывать на подмножество разделов GPT (максимум 4 шт., которые находятся в пределах первых 2ТiB размеченного диска), и они будут видны этой операционной системе.

Чтобы компьютер загрузил ОС средствами UEFI, необходимо наличие системного раздела EFI на диске (EFI System Partition (ESP)), с которого осуществляется загрузка. Неважно, какая разметка используется (MBR или GPT), важно наличие самого раздела, а также наличие приложения UEFI с прописанным именем в системных переменных UEFI или имеющего стандартное имя bootx64.efi и располагающегося в директории EFIboot в разделе ESP.

Таким образом, различие BIOS и UEFI-загрузки заключается в том, как загрузится и выполнится самая первая программа (приложение) после них. В BIOS загружается и выполняется программа, которая находится в нулевом секторе диска, в UEFI выполняется программа, которая находится на системном UEFI разделе диска.

Файловая система оптических дисков

Для хранения файлов на оптических дисках очень часто используется файловая система ISO 9660. Она имеет несколько уровней (Level 1, Level 2, Level 3) и расширений (Rock Ridge, Joliet). Также часто используется файловая система UDF, но для нашей задачи эти знания не понадобятся, так как фактически мы будем работать с секторами диска. В статье я не буду подробно рассматривать файловые системы для оптических дисков. Загрузчик, который будет загружен BIOS или UEFI для выполнения дальнейшей загрузки, должен «понимать» файловую систему оптических дисков, а я для краткости это не рассматриваю.

Загрузка с оптического диска

Для того, чтобы компьютер смог загружаться с оптического диска, BIOS или UEFI должны поддерживать стандарт El Torito, придуманный специально для этого. И тут, как и при загрузке с жёсткого диска, для BIOS важен сектор, в котором находится программа начальной загрузки, а для UEFI важен системный UEFI-раздел на диске c программой UEFI.

Скажу честно, я до последнего думал, что UEFI запускает файл bootx64.efi, который находится в файловой системе ISO 9660 на оптическом диске, однако это не так, так как UEFI понимает загрузку только с ESP, поэтому ему нужно предоставить образ ESP с файлом bootx64.efi, а в специальной структуре Booting Catalog указать расположение образа.

Гибридный ISO-образ

В настоящее время большинство дистрибутивов Linux распространяются в виде так называемых гибридных ISO-образов.

Суть гибридных ISO-образов в следующем: один и тот же образ можно посекторно записать на оптический диск или на флеш-накопитель/внешний жёсткий диск. Загрузка будет выполнена с любого из устройств, если его выбрать в качестве загрузочного. Это очень удобно для конечного пользователя. Он просто берёт образ и записывает его на оптический диск или флеш-накопитель, не выполняя никаких преобразований.

Как же это происходит? Дело в том, что первые 16 секторов в файловой системе ISO 9660, каждый из которых размером 2048 байт, используются для системных нужд, поэтому там можно разместить MBR и/или GPT. Они игнорируются BIOS/UEFI при загрузке с оптического диска, но при загрузке с флеш-накопителя они используются.

Запись о разделе в MBR или GPT будет указывать на файл с образом ESP, а в случае MBR для BIOS будет содержаться код начальной загрузки, который уже будет каким-то образом читать код из секторов и выполнять его, продолжая тем самым дальнейшую загрузку.

При всём своём удобстве этот подход не стандартизован и, например, Windows или какие-то программы по разметке диска могут считать такую информацию в MBR или GPT неверной.

Структура загрузочного ISO-образа

Любой ISO-образ должен содержать список дескрипторов томов. Каждый дескриптор занимает целый сектор (2048) байта. Дескрипторы томов размещаются начиная с 16-го сектора, если нумерация секторов осуществляется с 0.

Дескриптор тома с загрузочными записями El Torito располагается в 17-м секторе.
Структура загрузочного ISO-образа для современных компьютеров х86 представлена на рисунке.

Для загрузки с оптического диска нас интересует Boot Record Volume Descriptor. С описанием Primary Volume Descriptor и Volume Descriptor Set Terminator вы можете ознакомиться в спецификации файловой системы ISO 9660 (ECMA-119)

▍ Boot Record Volume Descriptor

Назначение Boot Record Volume Descriptor — указать, где находится Booting Catalog, который содержит информацию для BIOS или UEFI о том, что именно и каким способом можно загрузить с оптического диска.

▍ Booting Catalog

Booting Catalog – это массив записей размером 32 байта каждая. Количество записей не ограничено. Всего в спецификации определены 5 типов записей: Validation Entry, Default Entry, Section Header, Section Entry, Section Entry Extension. Последнюю описывать не буду, так как я не встречал её применение.

Validation Entry

Назначение Validation Entry — это подтверждение того, что образ ISO (оптический диск) действительно является загрузочным.

Default Entry

Назначение Default Entry — указать, что будет загружено по умолчанию. Обычно это сектора для загрузки при помощи BIOS.

Section Header

Назначение Section Header — сгруппировать возможные виды загрузки, однако обычно на практике существует ещё только один вид загрузки через UEFI.

Section Entry

Назначение Section Entry — указать, что может быть загружено и откуда. Обычно это сектора образа ESP для загрузки при помощи UEFI.

Практическая часть

Создание образа

Изначально я хотел описать в статье, как создать образ с нуля без использования сторонних программ, но потом мне показалось, что это раздует статью, её будет сложно читать, и вы потратите много времени на изучение. Поэтому использовал уже готовые решения, которые используются в Linux: Xorriso для создания образов, а для того, чтобы увидеть наглядно структуры загрузочного ISO, xxd для просмотра содержимого образа в шестандцатиричном формате

Вы всегда можете попробовать создать загрузочный ISO-файл сами, написав небольшие программы на C, Java или другом языке программирования, но в статье я на этом останавливаться не буду.

Минимальные программы-заглушки загрузчиков для BIOS и UEFI

Загрузчик для BIOS — это один или несколько секторов на диске, содержащих инструкции, которые используют сервисы (программные прерывания) BIOS и осуществляют дальнейшую инициализацию компьютера, загружают и запускают на выполнение ядро операционной системы.

Загрузчик для UEFI — это исполняемый файл, располагающийся в ESP-разделе и содержащий инструкции, которые используют сервисы UEFI, чтобы осуществлять дальнейшую инициализацию компьютера, загружать и запускать на выполнение ядро операционной системы.

Для упрощения понимания наши загрузчики не будут ничего делать кроме вывода тривиальных фраз типа «Hello, world!» на экран. Можно сказать, что это заглушки, которые могут быть использованы для написания полноценных загрузчиков в дальнейшем.

Код программы-заглушки загрузчика BIOS

Загрузчик для BIOS – это один или несколько секторов на диске. Инструкции, содержащиеся в них, процессор выполняет в реальном режиме, где доступно только 1MiB оперативной памяти.
Обычно исходный код загрузчика при помощи ассемблера превращается в бинарный файл, содержимое которого потом посекторно записывается на диск.

Для меня проще всего получить такой код, используя ассемблер fasm.

		use16
		org 0x7c00
		
		cli
		jmp 0:start
		times 8-($-$$) nop		; Pad to file offset 8

; iso_boot_info structure is filled by xorriso when we generate ISO file.
iso_boot_info:
bi_pvd:	dd 16				; LBA of primary volume descriptor
bi_file:	dd 0				; LBA of boot file
bi_length:	dd 0xdeadbeef			; Length of boot file
bi_csum:	dd 0xdeadbeef			; Checksum of boot file
bi_reserved:	times 10 dd 0xdeadbeef	; Reserved
iso_boot_info_end:

signature:	dd 0x7078c0fb			; used by ISOLINUX hybrid MBR

start:
		xor ax, ax
		push ax
		pop es
		push ax
		pop ds
		sti

		mov ax, 0x03
		int 0x10

		mov si, hello_message

		mov ah, 0xe
print_loop:
		lodsb
		or al, al
		jz done
		int 0x10
  		jmp print_loop

done:
		jmp $
hello_message:
		db "Hello world BIOS", 0x0a, 0

		times 510 - ($ - $$) db 0
		dw 0xaa55

Код у нас получается достаточно простой, но существуют моменты, на которые необходимо обратить внимание.

1. Так как процессор будет выполнять код в реальном режиме, нам нужно использовать директиву use16.
2. Наш код будет загружаться в BIOS по адресу 0x7c00. Чтобы ассемблер закрепил корректные адреса за метками, используется директива org.
3. Чтобы аппаратные прерывания не помешали начальной инициализации регистров, используется команда процессора cli.
4. Очень важно проинициализировать регистры. Во многих статьях по созданию загрузочных секторов забывают этот факт. В результате вроде всё гладко работает в qemu или VirtualBox, однако в VMWare или на реальном железе код отказывается работать. Я потратил достаточно много времени, пока это не понял.
5. Так как часть полученного кода будет модифицироваться Xorriso, который записывает нужные данные, то нам необходимо выполнить команду jmp, а дальше в коде зарезервировать место под эти данные.
6. Я не создавал свою MBR для ISO-образа, а использовал ту, которую предоставляет загрузчик ISOLINUX, поэтому необходимо прописать значение signature, ожидаемое загрузчиком из MBR, иначе наша заглушка загрузчика для BIOS не будет выполнена.
7. Значение 55AA и заполнение нулями в конце программы необязательно, но я хотел получить полноценный загрузочный сектор, который можно было бы записать в нулевой сектор жёсткого диска или флеш-накопителя, и он тоже бы выполнялся.

Код программы-заглушки загрузчика UEFI

Загрузчик для UEFI – это уже исполняемый файл, который помимо программного кода и данных содержит дополнительную информацию о том, как размещать их в оперативной памяти. Файлы .efi по формату практически совпадают с исполняемыми файлами Windows. Разумеется, в них нет вызовов функций операционной системы. Обычно исходный код пишется на языке C или С++. Мы для простоты будем использовать C.

При сборке в операционной системе Linux нам понадобится кросс-компилятор.

Необходимости комментировать что-то в программе нет ввиду её простоты, однако я добавлю, что для компиляции программы у вас должен быть установлен пакет gnu-efi, а вечный цикл (while (1)) я сделал для наглядности, чтобы сообщение не исчезало при завершении работы программы, и EFI_SUCCESS она никогда не вернёт.

#include <efi.h>
#include <efilib.h>

EFI_STATUS EfiMain (EFI_HANDLE ImageHandle, EFI_SYSTEM_TABLE  *SystemTable ) {

    SystemTable->ConOut->OutputString(SystemTable->ConOut, L"UEFI Hello World!n");
    while(1);
    return EFI_SUCCESS;
}

Алгоритм создания загрузочного диска вручную

Я собирал образ загрузочного диска на Ubuntu 22.10.

Для начала необходимо поставить следующие пакеты, если они не установлены.

1. Создаём необходимые директории.

$ cd ~
$ mkdir -p boot-hello-world
$ cd boot-hello-world
$ mkdir -p build
$ mkdir -p out

2. Создаём файлы bioshello.asm и efihello.c с исходным кодом наших программ-заглушек загрузчиков.

3. Компилируем заглушку для загрузчика BIOS.

$ fasm bioshello.asm build/bootsec.bin

4. Компилируем заглушку для загрузчика UEFI.

$ x86_64-w64-mingw32-gcc -shared -I/usr/include/efi -nostdlib -mno-red-zone -fno-stack-protector -Wall -e EfiMain efihello.c -o build/bootx64.efi.dll
$ objcopy --target=efi-app-x86_64 build/bootx64.efi.dll build/bootx64.efi

5. Создаём образ ESP, создаём в нём директории, копируем в него файл bootx64.efi.

$ dd if=/dev/zero of=build/uefi.img bs=512 count=2880
$ mkfs.msdos -F 12 -n 'EFIBOOTISO' build/uefi.img
$ mmd -i build/uefi.img ::EFI
$ mmd -i build/uefi.img ::EFI/BOOT
$ mcopy -i build/uefi.img build/bootx64.efi ::EFI/BOOT/bootx64.efi

6. Создаём структуру из файлов и директорий, которые будут размещены в образе ISO.

$ mkdir -p build/iso-image/boot
$ mkdir -p build/iso-image/EFI/boot
$ cp build/bootx64.efi build/iso-image/EFI/boot/
$ cp build/bootsec.bin build/iso-image/boot/
$ cp build/uefi.img build/iso-image/boot/

7. Создаём гибридный загрузочный образ ISO.

$ xorriso  -as mkisofs -V "HYBRID" -o out/bootdisk.iso -isohybrid-mbr /usr/lib/ISOLINUX/isohdpfx.bin -c boot/boot.cat -b boot/bootsec.bin -no-emul-boot -boot-info-table 
-boot-load-size 4 -eltorito-alt-boot -e boot/uefi.img -no-emul-boot -isohybrid-gpt-basdat build/iso-image --sort-weight 0 /boot --sort-weight 1 /

8. Экспериментируем и проверяем работу образа в различных эмуляторах, например qemu, виртуальных машинах (VMWare, Virtual Box), записываем образ на оптический диск и флеш-накопитель (при помощи программ Win32DiskImager, balenaEtcher).

Например, чтобы запустить в qemu-эмуляторе загрузочный ISO с использованием BIOS, если бы он был записан на оптический диск:

$ qemu-system-x86_64 -boot d -cdrom out/bootdisk -nographic -net none -monitor telnet::45454,server,nowait -serial mon:stdio

Чтобы запустить в qemu-эмуляторе загрузочный ISO с использованием UEFI, если бы он был записан на флеш-накопитель:

$ qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -boot d -hda $(BOOT_ISO) -nographic -net none -monitor telnet::45454,server,nowait -serial mon:stdio

Чтобы выйти из эмулятора, нужно нажать клавиши Ctrt + A, а потом X.

Я думаю, о том, как запустить эмуляцию запуска загрузочного диска с использованием BIOS с флеш-накопителя и с использованием UEFI с оптического диска вы догадаетесь сами.

Ещё один способ создания загрузочного флеш-накопителя в Windows

Внимательный читатель мог заметить, что зачем-то в ISO-образ помимо образа ESP помещается и файл bootx64.efi. Напрашивается вопрос, зачем это делается, если UEFI нужен именно образ ESP в ISO-образе? Ответ заключается в том, что, разместив файл в образе ISO, можно создать загрузочный флеш-накопитель путём простого копирования всех файлов из ISO-образа.

Единственное, что нужно это разметить и отформатировать флеш-накопитель, используя команду diskpart. Обращаю внимание, что хотя способ и простой, вы обязательно должны понимать, что вы делаете и выполнять эту процедуру очень внимательно, так как вы можете уничтожить содержимое вашего жёсткого диска, если неправильно выберете диск, на котором будете осуществлять разметку и форматирование.

1. Запускаем программу diskpart.
2. Выводим на экран список доступных дисков командой list disk.
3. Выбираем среди них флеш-накопитель, который мы будем размечать и форматировать командой select disk.
4. Выполняем очистку выбранного диска командой clean.
5. Создаём первичный раздел командой create partition primary.
6. Форматируем раздел командой format fs=fat32 quick.
7. Выходим из diskpart командой exit.
8. Копируем файлы из ISO-образа на флеш-накопитель простым копированием файлов

В нашем случае нам достаточно скопировать только директорию EFI, так как остальные файлы использоваться не будут, но для простоты скопируйте все файлы из ISO-образа.

Изучение структуры созданного загрузочного ISO-образа

Созданный образ у нас находится в директории out и имеет имя bootdisk.iso.

1. Выведем номер сектора, где располагается Booting Catalog:

$ xxd -l 4 -s $(expr 17 * 2048 + 71) out/bootdisk.iso 

Здесь 4 — это количество байт, которые выводим, 17 — номер сектора с Boot Record Volume Descriptor, 2048 — размер сектора, 71 — смещение внутри сектора, где располагается LBA Booting Catalog.

Номер сектора занимает 4 байта, поэтому нужно знать, какой порядок байтов используется Big Endian или Little Endian. Я не нашёл в спецификации El Torito, какой порядок используется, но, судя по всему, это Little Endian, поэтому байты нужно читать справа налево, получая 0x00000021.

2. Выведем первые четыре записи Booting Catalog:

$ xxd -l $(expr 32 * 4) -s $(expr $(echo $((0x21))) * 2048) out/bootdisk.iso

Здесь 32 — это размер записи в Booting Catalog, 4 — количество записей, $(expr $(echo $((0x21))) — десятичное представление 0x21, 2048 — размер сектора.

3. Выведем LBA-адрес сектора, который будет загружен при загрузке средствами BIOS:

$ xxd -l 4 -s $(expr $(echo $((0x21))) * 2048 + 32 + 8) out/bootdisk.iso

Здесь 4 — количество байт, которые выводим, 32 — размер записи в Booting Catalog (мы берём данные из Default Entry, поэтому пропускаем 32 байта), 8 — смещение внутри Default Entry, где располагается LBA загрузчика для BIOS, 2048 — размер сектора.

4. Выведем первые 512 байт этого сектора (это наша программа, которую мы написали на ассемблере и откомпилировали).

$ xxd -l 512 -s $(expr $(echo $((0x22))) * 2048) out/bootdisk.iso

5. Выведем LBA сектора, где располагается образ раздела ESP, необходимый для загрузки средствами UEFI.

$ xxd -l 4 -s $(expr $(echo $((0x21))) * 2048 + 32 * 3 + 8) out/bootdisk.iso

6. Выведем первые 512 байт образа ESP.

$ xxd -l 512 -s $(expr $(echo $((0x23))) * 2048) out/bootdisk.iso

LBA адресов теоретически могут быть у вас быть другие. Я привёл те, которые были у меня.

Вы можете получить LBA адресов, по которым располагается откомпилированная программа на ассемблере, используя структуры MBR и GPT, находящиеся в первых секторах, изучив документацию по MBR и GPT. Здесь я приводить не буду, оставляю на самостоятельное изучение. Скажу только, что они будут отличаться, так как используются в этом случае сектора по 512 байт, а не по 2048.

Создание среды для сборки

Для создания воспроизводимого окружения для сборки очень удобно использовать Docker. Он позволяет создавать изолированные окружения с необходимыми зависимостями. Мы тоже будем использовать его, ниже я привожу Dockerfile.

FROM ubuntu:22.10
RUN apt update && apt install --yes make gcc-mingw-w64 fasm gnu-efi binutils
RUN apt install --yes mtools dosfstools xorriso isolinux xxd
RUN apt install --yes qemu-system-x86 ovmf 
WORKDIR /app/

Вы можете собрать образ Docker со всеми необходимыми для сборки зависимостями, используя команду.

$ docker build -t boot-hello-world:latest . 

Для запуска контейнера в интерактивном режиме в PowerShell в директории, где у вас содержатся файлы bioshello.asm и efihello.c нужно ввести команду.

$docker run --name isobuilder -v ${pwd}:/app --rm -it boot-hello-world bash

Автоматизация сборки ISO-образа

Для автоматизации сборки из исходников существует множество различных утилит, но для простоты мы будем использовать make.

Основное отличие утилиты make от обычных shell-скриптов заключается в том, что она:

• отслеживает зависимости в исходных файлах;
• пересобирает только при наличии изменений.

Ниже привожу файл Makefile, который автоматизирует сборку и позволяет запускать этот образ в эмуляторе qemu в различных режимах.

CC = x86_64-w64-mingw32-gcc 
CFLAGS = -shared -I/usr/include/efi -nostdlib -mno-red-zone -fno-stack-protector -Wall -e EfiMain

BUILDDIR = build
OUT = out
ISO_DIR = $(BUILDDIR)/iso-image
EFI_BOOT_DIR = $(ISO_DIR)/EFI/boot

EFI_APP = bootx64.efi
BIOS_APP = bootsec.bin
ESP_IMAGE = uefi.img
BOOT_ISO = $(OUT)/bootdisk.iso

HYBRID_MBR = /usr/lib/ISOLINUX/isohdpfx.bin
TARGETS = $(BOOT_ISO)

all: $(TARGETS)  	

$(BUILDDIR):
	mkdir -p $(BUILDDIR)
	mkdir -p $(OUT)

$(BUILDDIR)/$(BIOS_APP): bioshello.asm | $(BUILDDIR)
	@echo "[BUILDING BIOS APP]"
	fasm $< $@

$(BUILDDIR)/$(EFI_APP): efihello.c | $(BUILDDIR)
	@echo "[BUILDING EFI APP]"
	$(CC) $(CFLAGS) $< -o $@.dll
	objcopy --target=efi-app-x86_64 $@.dll $@

$(BUILDDIR)/$(ESP_IMAGE): $(BUILDDIR)/$(EFI_APP) | $(BUILDDIR)
	@echo "[BUILDING ESP IMAGE]"
	dd if=/dev/zero of=${BUILDDIR}/${ESP_IMAGE} bs=512 count=2880
	mkfs.msdos -F 12 -n 'EFIBOOTISO' ${BUILDDIR}/${ESP_IMAGE}
	mmd -i ${BUILDDIR}/${ESP_IMAGE} ::EFI
	mmd -i ${BUILDDIR}/${ESP_IMAGE} ::EFI/BOOT
	mcopy -i ${BUILDDIR}/${ESP_IMAGE} ${BUILDDIR}/${EFI_APP} ::EFI/BOOT/bootx64.efi

$(ISO_DIR): $(BUILDDIR)/$(BIOS_APP) $(BUILDDIR)/$(ESP_IMAGE)
	@echo "[CREATING ISO DIRECTORY WITH FILES]"
	mkdir -p ${ISO_DIR}/boot
	mkdir -p ${EFI_BOOT_DIR}
	cp ${BUILDDIR}/${EFI_APP} ${EFI_BOOT_DIR}/
	cp ${BUILDDIR}/${BIOS_APP} ${ISO_DIR}/boot/
	cp ${BUILDDIR}/${ESP_IMAGE} ${ISO_DIR}/boot/   

$(BOOT_ISO): $(ISO_DIR)
	@echo "[BUILDING HYBRYD ISO FILE]"
	xorriso  -as mkisofs -V "HybridBootISOSample" -o $@ -isohybrid-mbr $(HYBRID_MBR) -c boot/boot.cat -b boot/$(BIOS_APP) -no-emul-boot -boot-info-table 
	-boot-load-size 4 -eltorito-alt-boot -e boot/$(ESP_IMAGE) -no-emul-boot -isohybrid-gpt-basdat $(ISO_DIR) --sort-weight 0 /boot --sort-weight 1 /
	@echo "The Hybrid ISO file [$@] was created. You can burn it to CD/DVD or to the flash disk and test"

clean:
	@echo "[PERFORMING CLEAN]"
	rm -rf $(BUILDDIR)
	rm -rf $(OUT)

qemu-bios-cdrom: $(BOOT_ISO)
	@echo "[STARTING QEMU WITH BIOS FIRMWARE FROM CDROM]"
	qemu-system-x86_64 -boot d -cdrom $(BOOT_ISO) -nographic -net none -monitor telnet::45454,server,nowait -serial mon:stdio

qemu-efi-cdrom: $(BOOT_ISO)
	@echo "[STARTING QEMU WITH UEFI FIRMWARE FROM CDROM]"
	qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -boot d -cdrom $(BOOT_ISO) -nographic -net none -monitor telnet::45454,server,nowait -serial mon:stdio

qemu-bios-flash-disk: $(BOOT_ISO) 
	@echo "[STARTING QEMU WITH BIOS FIRMWARE FROM FLASH DISK]"
	qemu-system-x86_64 -boot d -hda $(BOOT_ISO) -nographic -net none -monitor telnet::45454,server,nowait -serial mon:stdio
 
qemu-efi-flash-disk: $(BOOT_ISO)
	@echo "[STARTING QEMU WITH UEFI FIRMWARE FROM FLASH DISK]"
	qemu-system-x86_64 -bios /usr/share/ovmf/OVMF.fd -boot d -hda $(BOOT_ISO) -nographic -net none -monitor telnet::45454,server,nowait -serial mon:stdio 

Данный Makefile позволяет собрать ISO-образ (make clean all), а также запустить его в эмуляторе с BIOS, UEFI, с флеш-накопителя и cdrom, что понятно из названий.

Полезные ссылки

1. Спецификация ISO 9660 (ECMA 119).
2. Cпецификация El Torito.
3. Спецификация UEFI.
4. Docker Desktop.
5. SD Card Memory Formatter — программа для форматирования (форматирует USB-накопители тоже). Иногда помогает, когда программы записи образов отказываются записывать образ.
6. balenaEtcher — программа для записи образов на флеш-накопитель.
7. Win32 Disk Imager — программа для записи образов на флеш-накопитель. Иногда записывает, когда и balenaEtcher отказывается.
8. wiki.osdev.org — сайт с информацией по разработке ОС, где среди прочего есть информация по загрузке ОС.
9. wiki.archlinux.org — сайт с исчерпывающей информацией по операционным системам, но лучше искать информацию на нём с помощью Google.

Заключение

В статье создан минимальный гибридный ISO-образ, который позволяет понять основы загрузки на компьютерах (BIOS и UEFI c жёсткого диска, флеш-накопителя, оптического диска). Многие вопросы не были рассмотрены с целью упрощения, так как статья имеет познавательный, а не энциклопедический характер и не рассчитана на тех, кто имеет значительный опыт по этой теме.

Минимальный гибридный образ не содержит никаких операционных систем, он содержит только заглушки для загрузчиков, которые позволяют понять механизмы загрузки и структуру самого гибридного образа.

Я не рассматривал загрузочные образы операционной системы Windows и реализацию загрузки с оптических дисков в Windows, но, получив знания из статьи, вам будет гораздо проще понять, так как там тоже используется El Torito.

Надеюсь, я раскрыл тему создания загрузочных ISO-образов хотя бы на базовом уровне и не сильно утомил детализацией, а вы не будете так пугаться темы загрузочных образов, как пугался я. Вы гораздо лучше будете понимать, почему у вас не грузится операционная система с ISO-образа дистрибутива, и что вы сделали не так.