Глава 1. Начальная загрузка и инициализация ядра

Эта глава представляет собой обзор процессов загрузки и инициализации системы, начиная с POST в BIOS (микропрограмме) и заканчивая созданием первого пользовательского процесса. Поскольку начальные этапы загрузки системы сильно зависят от архитектуры, в качестве примера используется архитектура IA-32. Однако архитектуры AMD64 и ARM64 гораздо важнее и интереснее, и их следует рассмотреть в ближайшем будущем в соответствии с темой этого документа.

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

Процесс загрузки — это операция, крайне зависимая от оборудования. Не только для каждой архитектуры компьютера должен быть написан код, но также могут существовать различные типы загрузки в рамках одной архитектуры. Например, список файлов в каталоге stand показывает большое количество кода, зависящего от архитектуры. Для каждой из поддерживаемых архитектур существует отдельный каталог. FreeBSD поддерживает стандарт загрузки CSM (Compatibility Support Module). Таким образом, CSM поддерживается (как с GPT, так и с MBR разметкой), а также загрузка через UEFI (GPT полностью поддерживается, MBR — в основном). Также поддерживается загрузка файлов с ext2fs, MSDOS, UFS и ZFS. FreeBSD поддерживает функцию загрузочного окружения ZFS, которая позволяет основной ОС передавать детали о том, что загружать, выходящие за рамки простого раздела, как это было возможно ранее. Однако в наши дни UEFI более актуален, чем CSM. В следующем примере показана загрузка компьютера x86 с жёсткого диска с MBR-разметкой, где используется мультизагрузчик FreeBSD boot0, сохранённый в самом первом секторе. Этот загрузочный код запускает трёхэтапный процесс загрузки FreeBSD.

Ключ к пониманию этого процесса заключается в том, что он состоит из последовательных стадий возрастающей сложности. Эти стадии — boot1, boot2 и loader (подробнее см. boot(8)). Система загрузки выполняет каждую стадию последовательно. Последняя стадия, loader, отвечает за загрузку ядра FreeBSD. Каждая стадия рассматривается в следующих разделах.

Вот пример вывода, сгенерированного на различных этапах загрузки. Фактический вывод может отличаться в зависимости от машины:

При включении компьютера регистры процессора устанавливаются в некоторые предопределённые значения. Один из регистров — это регистр указателя команд, и его значение после включения питания чётко определено: это 32-битное значение 0xfffffff0. Регистр указателя команд (также известный как Счётчик Команд) указывает на код, который должен быть выполнен процессором. Ещё один важный регистр — это 32-битный управляющий регистр cr0, и его значение сразу после перезагрузки равно 0. Один из битов cr0, бит PE (Protection Enabled, Защита Включена), указывает, работает ли процессор в 32-битном защищённом режиме или 16-битном реальном режиме. Поскольку этот бит сброшен при загрузке, процессор запускается в 16-битном реальном режиме. Реальный режим означает, среди прочего, что линейные и физические адреса идентичны. Причина, по которой процессор не запускается сразу в 32-битном защищённом режиме, — это обратная совместимость. В частности, процесс загрузки зависит от услуг, предоставляемых BIOS, а сам BIOS работает в устаревшем 16-битном коде.

Значение 0xfffffff0 немного меньше 4 ГБ, поэтому, если в машине нет 4 ГБ физической памяти, оно не может указывать на действительный адрес памяти. Аппаратное обеспечение компьютера преобразует этот адрес так, чтобы он указывал на блок памяти BIOS.

BIOS (Basic Input Output System) — это микросхема на материнской плате, которая содержит относительно небольшой объем памяти только для чтения (ROM). Эта память включает различные низкоуровневые процедуры, специфичные для оборудования, поставляемого с материнской платой. Процессор сначала переходит по адресу 0xfffffff0, который фактически находится в памяти BIOS. Обычно по этому адресу содержится инструкция перехода к процедурам POST BIOS.

POST (Power On Self Test) — это набор процедур, включающих проверку памяти, проверку системной шины и другую низкоуровневую инициализацию, чтобы процессор мог правильно настроить компьютер. Важным этапом на этой стадии является определение загрузочного устройства. Современные реализации BIOS позволяют выбирать загрузочное устройство, обеспечивая загрузку с дискеты, CD-ROM, жесткого диска или других устройств.

Самым последним действием в POST является инструкция INT 0x19. Обработчик INT 0x19 считывает 512 байт из первого сектора загрузочного устройства в память по адресу 0x7c00. Термин первый сектор происходит из архитектуры жёстких дисков, где магнитная пластина разделена на множество цилиндрических дорожек. Дорожки нумеруются, и каждая дорожка разделена на несколько (обычно 64) секторов. Нумерация дорожек начинается с 0, но нумерация секторов начинается с 1. Дорожка 0 находится на внешней стороне магнитной пластины, а сектор 1, первый сектор, имеет особое назначение. Он также называется MBR (Master Boot Record) или Главная Загрузочная Запись. Остальные секторы на первой дорожке не используются.

Этот сектор является нашей точкой входа в последовательность загрузки. Как мы увидим, этот сектор содержит копию нашей программы boot0. BIOS выполняет переход по адресу 0x7c00, и она начинает выполняться.

После получения управления от BIOS по адресу памяти 0x7c00 начинает выполняться boot0. Это первый код, который управляется FreeBSD. Задача boot0 довольно проста: просканировать таблицу разделов и позволить пользователю выбрать, с какого раздела загружаться. Таблица разделов — это специальная стандартная структура данных, встроенная в MBR (а значит, и в boot0), которая описывает четыре стандартных PC-раздела. boot0 находится в файловой системе как /boot/boot0. Это небольшой файл размером 512 байт, и именно его процедура установки FreeBSD записывает в MBR жёсткого диска, если во время установки была выбрана опция "bootmanager". Действительно, boot0 и есть MBR.

Как упоминалось ранее, мы вызываем прерывание BIOS INT 0x19 для загрузки MBR (boot0) в память по адресу 0x7c00. Исходный файл для boot0 можно найти в stand/i386/boot0/boot0.S — это впечатляющий фрагмент кода, написанный Робертом Нордье.

Особая структура, начинающаяся со смещения 0x1be в MBR, называется таблицей разделов. Она содержит четыре записи по 16 байт каждая, называемые записями разделов, которые определяют, как разделён жёсткий диск, или, в терминологии FreeBSD, нарезан. Один из этих 16 байт указывает, является ли раздел (срез) загрузочным или нет. Ровно одна запись должна быть с этом установленным флагом, иначе код boot0 откажется продолжать работу.

Запись о разделе содержит следующие поля:

Дескриптор записи раздела содержит информацию о том, где именно раздел расположен на диске. Оба дескриптора, LBA и CHS, описывают одну и ту же информацию, но разными способами: LBA (Logical Block Addressing) содержит начальный сектор раздела и его длину, тогда как CHS (Cylinder Head Sector) содержит координаты первого и последнего секторов раздела. Таблица разделов завершается специальной сигнатурой 0xaa55.

MBR должен помещаться в 512 байт, один сектор диска. Эта программа использует низкоуровневые «трюки», такие как использование побочных эффектов определённых инструкций и повторное использование значений регистров из предыдущих операций, чтобы максимально эффективно использовать минимально возможное количество инструкций. Также необходимо соблюдать осторожность при работе с таблицей разделов, которая встроена в сам MBR. По этим причинам будьте очень внимательны при изменении boot0.S.

Обратите внимание, что исходный файл boot0.S ассемблируется "как есть": инструкции переводятся одна за одной в бинарный код без дополнительной информации (например, без формата файла ELF). Такой низкоуровневый контроль достигается на этапе компоновки с помощью специальных флагов, передаваемых компоновщику. Например, текстовая секция программы располагается по адресу 0x600. На практике это означает, что boot0 должен быть загружен в память по адресу 0x600 для корректной работы.

Стоит взглянуть на Makefile для boot0 (stand/i386/boot0/Makefile), так как он определяет некоторые аспекты поведения boot0 во время выполнения. Например, если для ввода-вывода используется терминал, подключённый к последовательному порту (COM1), необходимо определить макрос SIO (-DSIO). -DPXE включает загрузку через PXE при нажатии F6. Кроме того, программа определяет набор флагов, которые позволяют дополнительно настроить её поведение. Всё это проиллюстрировано в Makefile. Например, обратите внимание на директивы компоновщика, которые предписывают ему начинать секцию текста с адреса 0x600 и создавать выходной файл "как есть" (удаляя любое форматирование файла):

Приступим к изучению MBR, или boot0, начиная с точки входа.

Этот первый блок кода является точкой входа программы. Именно сюда BIOS передаёт управление. Сначала он гарантирует, что строковые операции автоматически увеличивают указатели операндов (инструкция cld) ^[2]. Затем, не делая предположений о состоянии сегментных регистров, он их инициализирует. Наконец, он устанавливает регистр указателя стека (%sp) в ($LOAD = адрес 0x7c00), чтобы обеспечить работоспособный стек.

Следующий блок отвечает за перемещение и последующий переход к перемещенному коду.

Так как boot0 загружается BIOS по адресу 0x7C00, он копирует себя по адресу 0x600 и передаёт управление туда (напомним, что он был слинкован для выполнения по адресу 0x600). Исходный адрес, 0x7c00, копируется в регистр %si. Конечный адрес, 0x600, — в регистр %di. Количество слов для копирования, 256 (размер программы = 512 байт), копируется в регистр %cx. Далее инструкция rep повторяет следующую за ней инструкцию, то есть movsw, количество раз, указанное в регистре %cx. Инструкция movsw копирует слово, на которое указывает %si, по адресу, на который указывает %di. Это повторяется ещё 255 раз. При каждом повторении оба регистра, исходный и конечный, %si и %di, увеличиваются на единицу. Таким образом, по завершении копирования 256 слов (512 байт), %di имеет значение 0x600`512`= `0x800`, а `%si` — значение `0x7c00`512= 0x7e00; таким образом, мы завершили перемещение кода. С момента последнего обновления этого документа инструкции копирования в коде изменились, поэтому вместо movsb и stosb были введены movsw и stosw, которые копируют 2 байта (1 слово) за одну итерацию.

Затем регистр назначения %di копируется в %bp. %bp получает значение 0x800. Значение 8 копируется в %cl для подготовки новой строковой операции (как в предыдущей movsw). Теперь stosw выполняется 8 раз. Эта инструкция копирует значение 0 по адресу, на который указывает регистр назначения (%di, то есть 0x800), и увеличивает его. Это повторяется ещё 7 раз, так что %di в итоге получает значение 0x810. Фактически это очищает диапазон адресов 0x800-0x80f. Этот диапазон используется как (фиктивная) таблица разделов для записи MBR обратно на диск. Наконец, полю сектора для CHS-адресации этого фиктивного раздела присваивается значение 1, и выполняется переход к основной функции из перемещённого кода. Обратите внимание, что до этого перехода к перемещённому коду любые ссылки на абсолютные адреса избегались.

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

Этот код проверяет бит SETDRV (0x20) в переменной flags. Напомним, что регистр %bp указывает на адрес 0x800, поэтому проверка выполняется для переменной flags по адресу 0x800-69= 0x7bb. Это пример типа изменений, которые можно внести в boot0. Флаг SETDRV не установлен по умолчанию, но его можно задать в Makefile. Если он установлен, используется номер диска, сохранённый в MBR, вместо предоставленного BIOS. Мы предполагаем значения по умолчанию и то, что BIOS предоставил корректный номер диска, поэтому переходим к save_curdrive.

Следующий блок сохраняет номер диска, предоставленный BIOS, и вызывает putn для вывода новой строки на экран.

Обратите внимание, что мы предполагаем, что TEST не определён, поэтому условный код в нём не собирается и не появится в нашем исполняемом файле boot0.

Следующий блок реализует фактическое сканирование таблицы разделов. Он выводит на экран тип раздела для каждой из четырёх записей в таблице разделов. Каждый тип сравнивается со списком известных файловых систем операционных систем. Примерами распознаваемых типов разделов являются NTFS (Windows®, ID 0x7), ext2fs (Linux®, ID 0x83) и, конечно же, ffs/ufs2 (FreeBSD, ID 0xa5). Реализация довольно проста.

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

Следующий блок проверяет наличие других дисков. При запуске BIOS записывает количество дисков, присутствующих в компьютере, по адресу 0x475. Если есть другие диски, boot0 выводит текущий диск на экран. Пользователь может позже дать команду boot0 просканировать разделы на другом диске.

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

Следующий блок просто выводит приглашение с последующим вариантом по умолчанию:

Наконец, выполняется переход к start_input, где используются сервисы BIOS для запуска таймера и чтения пользовательского ввода с клавиатуры; если таймер истекает, будет выбран вариант по умолчанию:

Прерывание запрашивается с номером 0x1a и аргументом 0 в регистре %ah. BIOS имеет предопределённый набор сервисов, запрашиваемых приложениями как программно-генерируемые прерывания через инструкцию int, с получением аргументов в регистрах (в данном случае, %ah). Здесь, в частности, запрашивается количество тиков часов с момента последней полуночи; это значение вычисляется BIOS через RTC (Real Time Clock). Эти часы могут быть настроены на работу с частотой от 2 Гц до 8192 Гц. BIOS устанавливает их на 18,2 Гц при запуске. Когда запрос выполнен, 32-битный результат возвращается BIOS в регистрах %cx и %dx (младшие байты в %dx). Этот результат (часть %dx) копируется в регистр %di, и к %di добавляется значение переменной TICKS. Эта переменная находится в boot0 по смещению _TICKS (отрицательное значение) от регистра %bp (который, напомним, указывает на 0x800). Значение этой переменной по умолчанию — 0xb6 (182 в десятичной системе). Идея заключается в том, что boot0 постоянно запрашивает время у BIOS, и когда значение, возвращённое в регистре %dx, становится больше значения, хранящегося в %di, время истекает и будет сделан выбор по умолчанию. Поскольку RTC тикает 18,2 раза в секунду, это условие выполнится через 10 секунд (это поведение по умолчанию можно изменить в Makefile). До истечения этого времени boot0 непрерывно опрашивает BIOS на предмет ввода пользователя; это делается через int 0x16, аргумент 1 в %ah.

Была нажата клавиша или истекло время, последующий код проверяет выбор. В зависимости от выбора, регистр %si устанавливается так, чтобы указывать на соответствующую запись раздела в таблице разделов. Этот новый выбор переопределяет предыдущий выбор по умолчанию. Действительно, он становится новым значением по умолчанию. Наконец, устанавливается флаг ACTIVE выбранного раздела. Если это было разрешено при компиляции, версия boot0 в памяти с этими изменёнными значениями записывается обратно в MBR на диске. Мы оставляем детали этой реализации читателю.

Мы завершаем наше изучение последним блоком кода из программы boot0:

Вспомним, что %si указывает на выбранную запись раздела. Эта запись сообщает нам, где начинается раздел на диске. Мы предполагаем, конечно, что выбранный раздел действительно является срезом FreeBSD.

Буфер передачи установлен в 0x7c00 (регистр %bx), и запрос на чтение первого сектора слайса FreeBSD выполняется вызовом intx13. Мы предполагаем, что всё прошло успешно, поэтому переход к beep не выполняется. В частности, новый прочитанный сектор должен заканчиваться магической последовательностью 0xaa55. Наконец, значение в %si (указатель на выбранную таблицу разделов) сохраняется для использования на следующем этапе, и выполняется переход по адресу 0x7c00, где начинается выполнение нашего следующего этапа (только что прочитанного блока).

До сих пор мы прошли следующую последовательность:

boot1 — это следующий шаг в последовательности загрузки. Это первая из трех стадий загрузки. Обратите внимание, что до сих пор мы работали исключительно с секторами диска. Действительно, BIOS загружает самый первый сектор, а boot0 загружает первый сектор раздела FreeBSD. Обе загрузки происходят по адресу 0x7c00. Мы можем концептуально представлять эти секторы диска как содержащие файлы boot0 и boot1, соответственно, но на самом деле это не совсем верно для boot1. Строго говоря, в отличие от boot0, boot1 не является частью загрузочных блоков ^[3]. Вместо этого, единый полноценный файл boot (/boot/boot) в итоге записывается на диск. Этот файл представляет собой комбинацию boot1, boot2 и Boot Extender (или BTX). Этот единый файл превышает размер одного сектора (больше 512 байт). К счастью, boot1 занимает ровно первые 512 байт этого файла, поэтому, когда boot0 загружает первый сектор раздела FreeBSD (512 байт), он фактически загружает boot1 и передает ему управление.

Основная задача boot1 — загрузить следующий этап загрузки. Этот следующий этап несколько сложнее. Он состоит из сервера под названием "Boot Extender" (BTX) и клиента под названием boot2. Как мы увидим, последний этап загрузки, loader, также является клиентом сервера BTX.

Давайте теперь подробно рассмотрим, что именно делает boot1, начиная, как мы это делали для boot0, с точки входа:

Точка входа start просто переходит через специальную область данных к метке main, которая, в свою очередь, выглядит следующим образом:

Как и boot0, этот код перемещает boot1, на этот раз по адресу 0x700. Однако, в отличие от boot0, он не переходит туда. boot1 скомпонован для выполнения по адресу 0x7c00, фактически там, куда он был изначально загружен. Причина этого перемещения будет рассмотрена далее.

Далее идет цикл, который ищет слайс FreeBSD. Хотя boot0 загрузил boot1 из слайса FreeBSD, ему не была передана информация об этом ^[4], поэтому boot1 должен повторно просканировать таблицу разделов, чтобы найти начало слайса FreeBSD. Для этого он перечитывает MBR:

В приведённом выше коде регистр %dl содержит информацию о загрузочном устройстве. Эти данные передаются BIOS и сохраняются MBR. Числа 0x80 и выше указывают на то, что мы имеем дело с жёстким диском, поэтому вызывается nread, где считывается MBR. Аргументы для nread передаются через %si и %dh. Адрес памяти по метке part4 копируется в %si. Этот адрес памяти содержит "фальшивый раздел", который будет использован nread. Ниже приведены данные фальшивого раздела:

В частности, LBA для этой фиктивной раздела жестко закодирован как ноль. Это используется как аргумент для BIOS при чтении абсолютного сектора один с жесткого диска. Альтернативно, может использоваться адресация CHS. В этом случае, фиктивный раздел содержит цилиндр 0, головку 0 и сектор 1, что эквивалентно абсолютному сектору один.

Продолжим, рассмотрев nread:

Напомним, что %si указывает на поддельный раздел. Слово ^[5] по смещению 0x8 копируется в регистр %ax, а слово по смещению 0xa — в %cx. BIOS интерпретирует их как младшее 4-байтовое значение, обозначающее LBA для чтения (старшие четыре байта предполагаются нулевыми). Регистр %bx содержит адрес памяти, куда будет загружен MBR. Инструкция, помещающая %cs в стек, очень интересна. В данном контексте она ничего не делает. Однако, как мы скоро увидим, boot2 в сочетании с сервером BTX также использует xread.1. Этот механизм будет рассмотрен в следующем разделе.

Код в xread.1 далее вызывает функцию read, которая фактически обращается к BIOS с запросом на чтение сектора диска:

Обратите внимание на длинную инструкцию возврата в конце этого блока. Эта инструкция извлекает регистр %cs, помещённый в стек nread, и возвращает управление. В конце nread также возвращает управление.

С загрузкой MBR в память начинается фактический цикл поиска слайса FreeBSD:

Если обнаружен слайс FreeBSD, выполнение продолжается на метке main.5. Обратите внимание, что при обнаружении слайса FreeBSD %si указывает на соответствующую запись в таблице разделов, а %dh содержит номер раздела. Мы предполагаем, что слайс FreeBSD найден, поэтому продолжаем выполнение на метке main.5:

Напомним, что в данный момент регистр %si указывает на запись среза FreeBSD в таблице разделов MBR, поэтому вызов nread фактически прочитает секторы в начале этого раздела. Аргумент, переданный в регистре %dh, указывает nread прочитать 16 секторов диска. Напомним, что первые 512 байт, или первый сектор слайса FreeBSD, совпадает с программой boot1. Также напомним, что файл, записанный в начало слайса FreeBSD, это не /boot/boot1, а /boot/boot. Давайте посмотрим на размер этих файлов в файловой системе:

Оба файла boot0 и boot1 имеют размер 512 байт каждый, поэтому они занимают ровно один сектор диска. boot2 значительно больше, так как содержит как сервер BTX, так и клиент boot2. Наконец, файл под названием просто boot на 512 байт больше, чем boot2. Этот файл представляет собой объединение boot1 и boot2. Как уже отмечалось, boot0 записывается в самый первый сектор диска (MBR), а boot записывается в первый сектор раздела FreeBSD; boot1 и boot2 не записываются на диск. Команда, используемая для объединения boot1 и boot2 в единый файл boot, выглядит просто как cat boot1 boot2 > boot.

Итак, boot1 занимает ровно первые 512 байт boot, и, поскольку boot записывается в первый сектор слайса FreeBSD, boot1 полностью помещается в этот первый сектор. Когда nread читает первые 16 секторов слайса FreeBSD, он фактически читает весь файл boot ^[6]. Более подробно о том, как boot формируется из boot1 и boot2, мы увидим в следующем разделе.

Напомним, что nread использует адрес памяти 0x8c00 в качестве буфера передачи для хранения прочитанных секторов. Этот адрес выбран не случайно. Действительно, поскольку boot1 принадлежит первым 512 байтам, он оказывается в диапазоне адресов 0x8c00-0x8dff. Следующие 512 байт (диапазон 0x8e00-0x8fff) используются для хранения bsdlabel ^[7].

Начиная с адреса 0x9000 находится начало сервера BTX, и сразу за ним следует клиент boot2. Сервер BTX действует как ядро и выполняется в защищённом режиме с наивысшим уровнем привилегий. В отличие от этого, клиенты BTX (например, boot2) выполняются в пользовательском режиме. Мы увидим, как это реализовано, в следующем разделе. Код после вызова nread находит начало boot2 в буфере памяти и копирует его по адресу 0xc000. Это связано с тем, что сервер BTX размещает boot2 для выполнения в сегменте, начинающемся с 0xa000. Мы подробно рассмотрим это в следующем разделе.

Последний блок кода в boot1 разрешает доступ к памяти выше 1MB ^[8] и завершается переходом к начальной точке сервера BTX:

Обратите внимание, что непосредственно перед переходом прерывания включаются.

Далее в нашей последовательности загрузки идёт сервер BTX. Давайте быстро вспомним, как мы сюда попали:

Прежде чем изучать сервер BTX подробно, давайте рассмотрим, как создается единый, всеобъемлющий файл boot. Способ сборки boot определен в его Makefile (stand/i386/boot2/Makefile). Рассмотрим правило, которое создает файл boot:

Это говорит нам, что boot1 и boot2 необходимы, и правило просто объединяет их для создания одного файла с именем boot. Правила для создания boot1 также довольно просты:

Для применения правила создания boot1 необходимо собрать boot1.out. Это, в свою очередь, зависит от наличия boot1.o. Последний файл является результатом ассемблирования нашего знакомого boot1.S без компоновки. Теперь применяется правило создания boot1.out. Оно указывает, что boot1.o должен быть скомпонован с точкой входа start и начальным адресом 0x7c00. Наконец, boot1 создается из boot1.out применением соответствующего правила. Это команда objcopy, применяемая к boot1.out. Обратите внимание на флаги, передаваемые objcopy: -S указывает на удаление всей информации о перемещении и символов; -O binary указывает формат вывода, то есть простой, неформатированный двоичный файл.

Имея boot1, давайте посмотрим, как устроен boot2:

Механизм сборки boot2 гораздо сложнее. Отметим наиболее важные моменты. Список зависимостей выглядит следующим образом:

Отметим, что изначально файл заголовка boot2.h отсутствует, но его создание зависит от boot1.out, который у нас уже есть. Правило его создания немного лаконично, но важно то, что результат, boot2.h, выглядит примерно так:

Напомним, что boot1 был перемещён (т.е. скопирован из 0x7c00 в 0x700). Это перемещение теперь обретает смысл, потому что, как мы увидим, сервер BTX освобождает часть памяти, включая область, куда boot1 был изначально загружен. Однако серверу BTX необходим доступ к функции xread из boot1; согласно выводу boot2.h, эта функция находится по адресу 0x725. Действительно, сервер BTX использует функцию xread из перемещённого кода boot1. Теперь эта функция доступна из клиента boot2.

Следующее правило указывает компоновщику на необходимость связать различные файлы (ashldi3.o, boot2.o и sio.o). Обратите внимание, что выходной файл boot2.out компонуется для выполнения по адресу 0x2000 (${ORG2}). Напомним, что boot2 будет выполняться в пользовательском режиме внутри специального пользовательского сегмента, созданного сервером BTX. Этот сегмент начинается с адреса 0xa000. Также помните, что часть boot2 в boot была скопирована по адресу 0xc000, то есть со смещением 0x2000 от начала пользовательского сегмента, поэтому boot2 будет работать корректно при передаче управления на него. Далее, boot2.bin создается из boot2.out путем удаления символов и информации о формате; boot2.bin представляет собой сырой бинарный файл. Теперь обратите внимание, что файл boot2.ldr создается как 512-байтный файл, заполненный нулями. Это пространство зарезервировано для bsdlabel.

Теперь, когда у нас есть файлы boot1, boot2.bin и boot2.ldr, осталось только добавить сервер BTX перед созданием универсального файла boot. Сервер BTX находится в stand/i386/btx/btx; у него есть собственный Makefile со своим набором правил для сборки. Важно отметить, что он также компилируется как сырой бинарный файл и линкуется для выполнения по адресу 0x9000. Подробности можно найти в stand/i386/btx/btx/Makefile.

Имея файлы, составляющие программу boot, последним шагом является их объединение. Это выполняется специальной программой под названием btxld (исходный код расположен в /usr/src/usr.sbin/btxld). Некоторые аргументы этой программы включают имя выходного файла (boot), его точку входа (0x2000) и формат файла (бинарный). Различные файлы окончательно объединяются этой утилитой в файл boot, который состоит из boot1, boot2, bsdlabel и сервера BTX. Этот файл, занимающий ровно 16 секторов или 8192 байта, записывается в начало раздела FreeBSD во время установки. Теперь перейдем к изучению программы сервера BTX.

Сервер BTX подготавливает простое окружение и переключается из 16-битного реального режима в 32-битный защищённый режим, непосредственно перед передачей управления клиенту. Это включает инициализацию и обновление следующих структур данных:

Приступим к изучению фактической реализации. Напомним, что boot1 выполнил переход на адрес 0x9010 — точку входа сервера BTX. Прежде чем изучать выполнение программы там, обратите внимание, что сервер BTX имеет специальный заголовок в диапазоне адресов 0x9000-0x900f, непосредственно перед точкой входа. Этот заголовок определён следующим образом:

Обратите внимание, что первые два байта — это 0xeb и 0xe. В архитектуре IA-32 эти два байта интерпретируются как относительный переход за заголовок к точке входа, поэтому теоретически boot1 мог бы перейти сюда (адрес 0x9000) вместо адреса 0x9010. Обратите внимание, что последнее поле в заголовке BTX — это указатель на точку входа клиента (boot2)b2. Это поле исправляется во время компоновки.

Сразу после заголовка следует точка входа сервера BTX:

Этот код отключает прерывания, устанавливает рабочий стек (начиная с адреса 0x1800) и очищает флаги в регистре EFLAGS. Обратите внимание, что инструкция popfl извлекает двойное слово (4 байта) из стека и помещает его в регистр EFLAGS. Поскольку извлекаемое значение фактически равно 2, регистр EFLAGS эффективно очищается (IA-32 требует, чтобы бит 2 регистра EFLAGS всегда был равен 1).

Следующий блок кода очищает (устанавливает в 0) диапазон памяти 0x5e00-0x8fff. В этом диапазоне будут созданы различные структуры данных:

Напомним, что boot1 изначально загружался по адресу 0x7c00, поэтому при такой инициализации памяти эта копия фактически исчезла. Однако также напомним, что boot1 был перемещён на адрес 0x700, поэтому эта копия всё ещё находится в памяти, и сервер BTX будет её использовать.

Далее обновляется таблица векторов прерываний (IVT) в реальном режиме. IVT представляет собой массив пар сегмент/смещение для обработчиков исключений и прерываний. BIOS обычно сопоставляет аппаратные прерывания с векторами прерываний 0x8–0xf и 0x70–0x77, но, как будет показано, программируемый контроллер прерываний 8259A, микросхема, управляющая фактическим сопоставлением аппаратных прерываний с векторами прерываний, программируется для переназначения этих векторов прерываний с 0x8–0xf на 0x20–0x27 и с 0x70–0x77 на 0x28–0x2f. Таким образом, обработчики прерываний предоставляются для векторов прерываний 0x20–0x2f. Причина, по которой обработчики, предоставляемые BIOS, не используются напрямую, заключается в том, что они работают в 16-битном реальном режиме, но не в 32-битном защищённом режиме. Вскоре будет выполнен переход в 32-битный защищённый режим. Однако сервер BTX настраивает механизм для эффективного использования обработчиков, предоставляемых BIOS:

Следующий блок создает IDT (таблицу дескрипторов прерываний). IDT в защищенном режиме аналогична IVT в реальном режиме. То есть, IDT описывает различные обработчики исключений и прерываний, используемые, когда процессор работает в защищенном режиме. По сути, она также состоит из массива пар сегмент/смещение, хотя структура несколько сложнее, поскольку сегменты в защищенном режиме отличаются от реального режима, и применяются различные механизмы защиты:

Каждая запись в IDT имеет длину 8 байт. Помимо информации о сегменте/смещении, они также описывают тип сегмента, уровень привилегий и присутствует ли сегмент в памяти. Структура организована так, что векторы прерываний от 0 до 0xf (исключения) обрабатываются функцией intx00; вектор 0x10 (также исключение) обрабатывается intx10; аппаратные прерывания, которые позже настраиваются начиная с вектора 0x20 и до вектора 0x2f, обрабатываются функцией intx20. Наконец, вектор прерывания 0x30, используемый для системных вызовов, обрабатывается intx30, а векторы 0x31 и 0x32 обрабатываются intx31. Необходимо отметить, что только дескрипторы для векторов прерываний 0x30, 0x31 и 0x32 имеют уровень привилегий 3, такой же, как у клиента boot2, что означает, что клиент может выполнить программно-генерируемое прерывание к этим векторам через инструкцию int без ошибки (это способ, которым boot2 использует сервисы, предоставляемые сервером BTX). Также обратите внимание, что только программно-генерируемые прерывания защищены от кода, выполняющегося на более низких уровнях привилегий. Аппаратно-генерируемые прерывания и исключения, генерируемые процессором, всегда обрабатываются корректно, независимо от фактических привилегий.

Следующий шаг — инициализация TSS (сегмента состояния задачи). TSS — это аппаратная функция, которая помогает операционной системе или исполнительному ПО реализовать многозадачность через абстракцию процессов. Архитектура IA-32 требует создания и использования как минимум одного TSS, если используются механизмы многозадачности или определены различные уровни привилегий. Поскольку клиент boot2 выполняется на уровне привилегий 3, а сервер BTX работает на уровне привилегий 0, необходимо определить TSS:

Обратите внимание, что в TSS указано значение для указателя стека и сегмента стека уровня привилегий 0. Это необходимо, потому что если прерывание или исключение получено во время выполнения boot2 на уровне привилегий 3, процессор автоматически переключается на уровень привилегий 0, поэтому требуется новый рабочий стек. Наконец, полю базового адреса карты ввода-вывода TSS присваивается значение, которое представляет собой 16-битное смещение от начала TSS до битовой карты разрешений ввода-вывода и битовой карты перенаправления прерываний.

После создания IDT и TSS процессор готов к переходу в защищённый режим. Это выполняется в следующем блоке:

Сначала вызывается setpic для программирования 8259A PIC (программируемого контроллера прерываний). Этот чип подключен к нескольким источникам аппаратных прерываний. При получении прерывания от устройства он сигнализирует процессору соответствующим вектором прерывания. Это можно настроить так, чтобы определенные прерывания были связаны с конкретными векторами прерываний, как объяснялось ранее. Затем регистры IDTR (Interrupt Descriptor Table Register) и GDTR (Global Descriptor Table Register) загружаются инструкциями lidt и lgdt соответственно. Эти регистры загружаются базовым адресом и предельным адресом для IDT и GDT. Следующие три инструкции устанавливают бит Protection Enable (PE) в регистре %cr0. Это фактически переключает процессор в 32-битный защищенный режим. Затем выполняется дальний переход на init.8 с использованием селектора сегмента SEL_SCODE, который выбирает сегмент кода супервизора (Supervisor Code Segment). После этого перехода процессор фактически работает на уровне CPL 0 — наиболее привилегированном уровне. Наконец, для стека выбирается сегмент данных супервизора (Supervisor Data Segment) путем присвоения селектора сегмента SEL_SDATA регистру %ss. Этот сегмент данных также имеет уровень привилегий 0.

Наш последний блок кода отвечает за загрузку TR (Регистра Задач) с селектором сегмента для TSS, который мы создали ранее, и настройку окружения пользовательского режима перед передачей управления исполнения клиенту boot2.

Обратите внимание, что среда клиента включает селектор сегмента стека и указатель стека (регистры %ss и %esp). Действительно, как только TR загружается соответствующим селектором сегмента стека (инструкция ltr), указатель стека вычисляется и помещается в стек вместе с селектором сегмента стека. Затем значение 0x202 помещается в стек; это значение, которое EFLAGS получит при передаче управления клиенту. Также в стек помещаются селектор сегмента кода пользовательского режима и точка входа клиента. Напомним, что эта точка входа прописывается в заголовке BTX во время компоновки. Наконец, селекторы сегментов (хранящиеся в регистре %ecx) для регистров сегментов %gs, %fs, %ds и %es помещаются в стек вместе со значением из %edx (0xa000). Примите во внимание эти значения, помещенные в стек (они скоро будут извлечены). Затем значения для оставшихся регистров общего назначения также помещаются в стек (обратите внимание на цикл loop, который помещает значение 0 семь раз). Теперь начнётся извлечение значений из стека. Сначала инструкция popa извлекает из стека последние семь помещённых значений. Они сохраняются в регистрах общего назначения в порядке %edi, %esi, %ebp, %ebx, %edx, %ecx, %eax. Затем различные селекторы сегментов, помещённые в стек, извлекаются в соответствующие регистры сегментов. В стеке остаются ещё пять значений. Они извлекаются при выполнении инструкции iret. Эта инструкция сначала извлекает значение, которое было помещено из заголовка BTX. Это значение является указателем на точку входа boot2. Оно помещается в регистр %eip — регистр указателя инструкций. Затем селектор сегмента кода пользователя извлекается и копируется в регистр %cs. Помните, что уровень привилегий этого сегмента — 3, наименее привилегированный уровень. Это означает, что мы должны предоставить значения для стека этого уровня привилегий. Именно поэтому процессор, помимо дальнейшего извлечения значения для регистра EFLAGS, выполняет ещё два извлечения из стека. Эти значения попадают в указатель стека (%esp) и сегмент стека (%ss). Теперь выполнение продолжается с точки входа boot0.

Важно отметить, как определяется сегмент пользовательского кода. Базовый адрес этого сегмента установлен на 0xa000. Это означает, что адреса памяти кода являются относительными к адресу 0xa000; если код, который выполняется, извлекается из адреса 0x2000, фактический адрес в памяти будет 0xa000+0x2000=0xc000.

boot2 определяет важную структуру, struct bootinfo. Эта структура инициализируется boot2 и передается загрузчику, а затем ядру. Некоторые узлы этой структуры устанавливаются boot2, остальные — загрузчиком. Эта структура, среди прочей информации, содержит имя файла ядра, геометрию жесткого диска в BIOS, номер диска в BIOS для загрузочного устройства, доступную физическую память, указатель envp и т.д. Ее определение выглядит так:

boot2 входит в бесконечный цикл, ожидая ввода пользователя, затем вызывает load(). Если пользователь ничего не нажимает, цикл прерывается по таймауту, и load() загружает файл по умолчанию (/boot/loader). Функции ino_t lookup(char *filename) и int xfsread(ino_t inode, void *buf, size_t nbyte) используются для чтения содержимого файла в память. /boot/loader — это ELF-бинарный файл, но с заголовком ELF, перед которым добавлена структура struct exec из a.out. load() анализирует ELF-заголовок загрузчика, загружает содержимое /boot/loader в память и передаёт управление на точку входа загрузчика:

Загрузчик также является клиентом BTX. Я не буду подробно описывать его здесь, существует исчерпывающая man-страница, написанная Майком Смитом: loader(8). Основные механизмы и BTX были рассмотрены выше.

Основная задача загрузчика — загрузить ядро. Когда ядро загружено в память, загрузчик вызывает его:

Давайте рассмотрим команду, которая компонует ядро. Это поможет определить точное местоположение, где загрузчик передает выполнение ядру. Это местоположение является фактической точкой входа ядра. Данная команда теперь исключена из sys/conf/Makefile.i386. Интересующее нас содержимое можно найти в /usr/obj/usr/src/i386.i386/sys/GENERIC/.

Вот несколько интересных наблюдений. Во-первых, ядро представляет собой динамически связанный бинарный файл ELF, но динамический компоновщик для ядра — это /red/herring, что явно является фиктивным файлом. Во-вторых, взглянув на файл sys/conf/ldscript.i386, можно понять, какие параметры ld используются при компиляции ядра. Читая первые несколько строк, видим, что строка

говорит, что точка входа ядра — это символ btext. Этот символ определён в locore.s:

Сначала регистр EFLAGS устанавливается в предопределённое значение 0x00000002. Затем инициализируются все сегментные регистры:

btext вызывает подпрограммы recover_bootinfo() и identify_cpu(), которые также определены в locore.s. Вот описание их функций:

Следующие шаги включают активацию VME, если процессор поддерживает эту функцию:

Затем, включение подкачки:

Следующие три строки кода необходимы, потому что была установлена подкачка, поэтому требуется переход для продолжения выполнения в виртуализированном адресном пространстве:

Функция init386() вызывается с указателем на первую свободную физическую страницу, после чего следует вызов mi_startup(). init386 — это архитектурно-зависимая функция инициализации, а mi_startup() — архитектурно-независимая (префикс 'mi_' означает Machine Independent, то есть «независимая от машины»). Ядро никогда не возвращается из mi_startup(), и, вызывая её, завершает загрузку: