Как написать свое ядро операционной системы с нуля

Ошибка triple fault с мгновенной перезагрузкой виртуальной машины — то, с чем сталкивается почти каждый, кто впервые пытается написать свое ядро: процессор дошёл до кода, который не смог выполнить, и ушёл в циклический ресет. Причина почти всегда одна — не настроена таблица дескрипторов прерываний или нарушена адресация при переходе в защищённый режим. Именно с диагностики таких вещей и начинается реальная разработка ядра, а не с абстрактной теории.

Написать собственное ядро — выполнимая задача для одного разработчика, если понимать её границы. Речь не о конкуренте Linux, а об учебном или исследовательском проекте: загрузчик, переход в защищённый или длинный режим, базовая обработка прерываний, простой менеджер памяти и вывод текста на экран. Ниже разобран полный маршрут: от выбора инструментов до отладки в эмуляторе, с акцентом на типичные точки отказа.

Что такое ядро и какой минимум оно должно делать

Ядро — это код, который работает в привилегированном режиме процессора и управляет ресурсами: памятью, прерываниями, задачами и доступом к устройствам. Всё остальное — драйверы, файловые системы, пользовательские программы — надстраивается поверх. Для первой версии достаточно, чтобы ядро загружалось, инициализировало таблицы процессора и могло вывести строку на экран через VGA-буфер или последовательный порт.

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

⚠️ Внимание: не пытайтесь сразу проектировать «правильную» архитектуру на годы вперёд. Самая частая причина брошенных проектов — разработчик тратит месяцы на идеальную структуру, так и не получив загружающийся бинарник. Сначала — работающий минимум, потом рефакторинг.

Выбор инструментов: язык, компилятор, эмулятор

Ядра пишут на C, C++ (ограниченное подмножество) или Rust, а критичные участки — на ассемблере. C остаётся стандартом де-факто: предсказуемый код без скрытых выделений памяти и исключений. Rust привлекателен гарантиями безопасности памяти, но требует больше усилий на старте. Ассемблер неизбежен минимум в двух местах: точке входа после загрузчика и обработчиках прерываний.

Ключевой момент — кросс-компилятор. Системный компилятор вашей ОС собирает код под вашу же ОС и её стандартную библиотеку, что для ядра недопустимо. Нужна сборка под цель вроде i686-elf или x86_64-elf со свободно стоящим окружением: флаги -ffreestanding и -nostdlib отключают зависимость от libc. Тестирование удобнее всего вести в QEMU — он позволяет подключить отладчик GDB и поставить точку останова прямо на инструкции процессора.

• 🛠️ Компилятор: GCC или Clang, собранные под цель x86_64-elf без привязки к хостовой ОС
• 💻 Ассемблер: NASM или GNU as — для точки входа и низкоуровневых обработчиков
• 🖥️ Эмулятор: QEMU с опциями -s -S для подключения GDB и остановки на первой инструкции
• 📦 Загрузчик: GRUB с поддержкой Multiboot — снимает необходимость писать свой boot sector
• 🔧 Сборка: Makefile или скрипт, собирающий ядро и упаковывающий его в загрузочный ISO

Загрузка: Multiboot и точка входа

Писать собственный загрузчик с нуля — отдельный большой проект: нужно читать сектора диска, включать линию A20, переходить в защищённый режим. На старте рациональнее использовать GRUB и спецификацию Multiboot: загрузчик сам переводит процессор в 32-битный защищённый режим, загружает ваш бинарник по известному адресу и передаёт управление на точку входа, указанную в скрипте компоновщика.

Чтобы GRUB распознал файл как ядро, в начало бинарника помещается Multiboot-заголовок — несколько магических чисел в первых килобайтах образа. Точка входа обычно пишется на ассемблере: она настраивает стек (без него невозможен вызов функций C), обнуляет при необходимости секцию .bss и вызывает функцию kmain(). Именно в kmain начинается код на C.

section .multiboot
align 4
dd 0x1BADB002          ; магическое число Multiboot
dd 0x00                ; флаги
dd -(0x1BADB002)       ; контрольная сумма

section .text
global _start
extern kmain
_start:
mov esp, stack_top     ; настраиваем стек
call kmain             ; переходим в код на C
cli
.hang:
hlt
jmp .hang

Если после запуска QEMU показывает чёрный экран без перезагрузок — это часто означает, что управление дошло до kmain, но код вывода на экран не сработал. Проверьте адрес VGA-буфера 0xB8000 и корректность записи символов с атрибутами цвета.

Таблицы процессора: GDT и IDT

После перехода в защищённый режим процессор опирается на две структуры. GDT (глобальная таблица дескрипторов) описывает сегменты памяти: для современного плоского режима достаточно нулевого дескриптора, сегмента кода и сегмента данных, покрывающих всё адресное пространство. IDT (таблица дескрипторов прерываний) связывает номера прерываний с адресами обработчиков — без неё любое исключение процессора приведёт к triple fault.

Обе таблицы загружаются инструкциями lgdt и lidt, которым передаётся структура из лимита и базового адреса. Типичная ошибка — неверный порядок байтов в этой структуре или загрузка указателя на данные, которые компилятор разместил не там, где ожидалось. Если после lidt машина перезагружается при первом же прерывании, проверяйте выравнивание таблицы и корректность полей дескрипторов: селектор кода, флаги присутствия, уровень привилегий.

⚠️ Внимание: исключения процессора (деление на ноль, page fault, general protection fault) срабатывают в ядре постоянно на этапе разработки. Если обработчиков нет, вы получите молчаливую перезагрузку без какой-либо диагностики. Первым делом после IDT напишите обработчики, которые печатают номер исключения и останавливают процессор — это сэкономит часы отладки.

Управление памятью: от физических страниц к куче

До появления аллокатора ядро не может создавать динамические структуры — ни списки задач, ни буферы. Первый уровень — менеджер физических страниц: он ведёт учёт свободных блоков фиксированного размера (на x86 страница традиционно 4 КБ) и выдаёт их по запросу. Карту доступной памяти предоставляет загрузчик — в Multiboot она приходит в структуре, указатель на которую GRUB кладёт в регистр при старте.

Следующий уровень — виртуальная память через страничную адресацию. Таблицы страниц отображают виртуальные адреса на физические, изолируют процессы и позволяют разместить ядро в верхних адресах. Это одна из самых трудоёмких частей: ошибка в записи таблицы страниц проявляется как page fault в совершенно неожиданном месте кода. Поверх страничного менеджера строится куча ядра — функции kmalloc() и kfree(), выдающие блоки произвольного размера.

Компонент	Назначение	Типичная ошибка
GDT	Описание сегментов кода и данных	Забытый far jump для обновления CS
IDT	Обработчики прерываний и исключений	Неверный селектор в дескрипторе
Физический менеджер	Учёт свободных страниц RAM	Игнорирование карты памяти от загрузчика
Таблицы страниц	Виртуальная память и изоляция	Отсутствие флага present у записи
Куча ядра	kmalloc/kfree для структур ядра	Повреждение метаданных при освобождении

Многозадачность и системные вызовы

Когда память работает, ядру нужна многозадачность. Минимальная схема — кооперативная: задача сама отдаёт управление вызовом yield(). Более правильный вариант — вытесняющая многозадачность на прерываниях таймера: программируемый таймер (PIT или APIC) генерирует прерывание с заданной частотой, обработчик сохраняет регистры текущей задачи в её структуру и загружает контекст следующей. Переключение контекста — ещё один участок, где без ассемблера не обойтись.

Чтобы пользовательские программы могли просить ядро о сервисах, нужен механизм системных вызовов. Классический способ на x86 — программное прерывание int 0x80, современный — инструкции syscall/sysenter. Программа кладёт номер вызова и аргументы в регистры, ядро находит функцию в таблице и возвращает результат. Начать можно с двух-трёх вызовов: вывод строки, завершение задачи, выделение памяти.

• ⏱️ Таймер: настройте PIT или APIC на периодические прерывания — это сердцебиение планировщика
• 🔄 Контекст: сохраняйте все регистры общего назначения и указатель стека задачи при переключении
• 📞 Системные вызовы: начните с таблицы указателей на функции, индексируемой номером вызова
• 👤 Режим пользователя: переход в ring 3 требует корректных сегментов и стека пользователя — оставьте это на поздний этап

Почему нельзя вызывать функции BIOS после перехода в защищённый режим

Прерывания BIOS (int 0x10, int 0x13 и другие) написаны для 16-битного реального режима и используют сегментную адресацию, несовместимую с защищённым режимом. После перехода весь доступ к оборудованию придётся реализовывать самостоятельно: через порты ввода-вывода (in/out) и отображённую на память видеопамять. Именно поэтому вывод текста в собственном ядре делается записью напрямую в буфер по адресу 0xB8000, а не через привычный int 0x10.

Отладка: как понять, где ядро упало

Отладка ядра отличается от отладки обычных программ: нет ни printf, ни отладчика «из коробки», а ошибка часто выглядит как мёртвый чёрный экран. Рабочая связка — QEMU с флагами -s -S: эмулятор ждёт подключения GDB на порту 1234 и стартует остановленным. GDB загружает символы из вашего ELF-файла, и вы получаете точки останова, пошаговое выполнение и просмотр регистров — вплоть до отдельных инструкций.

Второй инструмент — логирование. Опция QEMU -d int пишет в лог все прерывания и исключения: по записи об исключении видно его номер, адрес инструкции и состояние регистров в момент падения. Дополнительно полезен собственный отладочный вывод в COM1-порт через функцию на пару строк с инструкцией outb — он работает на самых ранних стадиях, когда ни VGA, ни куча ещё не инициализированы. Расставляйте маркеры вида «дошёл до точки A/B/C», чтобы сузить область поиска.

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

Дальнейшее развитие проекта

После того как ядро загружается, управляет памятью и переключает задачи, открывается свобода выбора направления. Логичные следующие шаги: драйвер клавиатуры через прерывание IRQ1, простая файловая система (например, чтение tar-архива как initrd от загрузчика), командная оболочка внутри ядра. Каждый такой шаг делает систему ощутимо «живой».

Полезно изучать существующие учебные проекты и документацию: руководства по OSDev, исходники учебных ядер, спецификации Intel и AMD по архитектуре x86. Чужой код стоит читать как справочник, а не копировать целиком — иначе вы получите систему, которую не сможете отладить. Ведение журнала разработки с описанием решений и ошибок заметно ускоряет прогресс: через месяц вы уже не вспомните, почему выбрали именно такой формат записи таблицы страниц.

Часто задаваемые вопросы

Нужно ли знать ассемблер, чтобы написать ядро?

Полностью без ассемблера обойтись нельзя: точка входа после загрузчика, обработчики прерываний и переключение контекста задач требуют работы с регистрами напрямую. Однако объём ассемблерного кода невелик — обычно это несколько коротких функций. Основная часть ядра пишется на C или Rust, а встроенный ассемблер (inline asm) позволяет встраивать отдельные инструкции прямо в код на C.

Сколько времени занимает написание первого работающего ядра?

Зависит от подготовки и целей. Загружаемое через GRUB ядро с выводом текста на экран — задача на несколько дней при наличии опыта программирования на C. Добавление IDT, обработчиков исключений и менеджера физической памяти обычно занимает ещё несколько недель неспешной работы. Полноценная многозадачность и системные вызовы — это уже месяцы. Сроки сильно растягиваются, если параллельно приходится изучать архитектуру процессора с нуля.

Можно ли написать ядро на Rust вместо C?

Да, Rust подходит для разработки ядер и даёт преимущества: безопасность памяти на уровне компилятора и отсутствие целого класса ошибок вроде use-after-free. Потребуется сборка с no_std и собственная реализация обработчика паники. Порог входа выше, чем у C: придётся разбираться с unsafe-блоками и особыми целями компиляции. Для первого проекта C проще в отладке, для долгосрочного — Rust вполне оправдан.

Нужно ли писать собственный загрузчик?

Нет, и на старте это не рекомендуется. GRUB с поддержкой Multiboot берёт на себя загрузку образа, переход в защищённый режим и передачу карты памяти. Собственный загрузчик имеет смысл писать позже — если хочется разобраться с реальным режимом, чтением диска и UEFI. Для учебных целей это интересный, но необязательный этап, который легко отложить.

Почему QEMU просто перезагружается после запуска моего ядра?

Циклическая перезагрузка почти всегда означает triple fault: процессор встретил исключение, обработчик исключения тоже упал, и произошёл аппаратный сброс. Типичные причины — отсутствующая или некорректная IDT, неверная GDT, обращение по невалидному адресу. Подключите GDB через qemu -s -S или включите лог прерываний опцией -d int — по номеру исключения и адресу инструкции вы быстро найдёте проблемное место.