Рассмотрение загрузочного сектора под микроскопом плюс маленький десерт в виде ассемблерного кода.

Введение

Здравствуйте, уважаемые подписчики!
Сразу разберемся с организационным вопросами.

С этого выпуска у рассылки будет 4 со-ведущих. И уже этот выпуск пишу я, Khimov Roman(khimov@osrc.info). Каждый выпуск будет
готовить кто-то один, передавая эстафету следующему. Надеюсь, что это позволит нам выдержать
строгую периодичность - раз в неделю по пятницам, чтобы Вам было что почитать на выходных
После меня, следующий выпуск будет делать commrade, потом Doberman, и потом Wanderer, после
чего опять моя очередь. Чем то напоминает принцип ротации выпускающих редакторов журнала "Компью"...

В этом выпуске мы обещали познакомить вас поближе с загрузочными секторами. А значит, пора приступать!

Что есть bootsector?

Bootsector, он же загрузочный сектор, - это то, что позволяет нам загрузить непосредственно
операционную систему. Как писал в предыдущем выпуске Wanderer, после выполнения POST, BIOS
смотрит в список очередности загрузки и пытается найти "" загрузочный сектор.
Правильным, с точки зрения BIOS, будет загрузочный сектор, содержащий 55AAhсо смещением на 510 байт от начала загрузочного сектора. Весь загрузочый сектор должен умещаться в 512 байт, поэтому при его разработке, как
правило, используется ассемблер.

Где живет bootsector?

Bootsector всегда можно найти по адресу: "нулевой цилиндр, нулевая головка, первый " . Это
означает, что bootsector всегда находится в самом начале того диска, с которого производится
загрузка. Однако есть одно важное исключение: на всех HDD по адресу, данному выше, располагается
MBR - Master Boot Record - Головная Загрузочная Запись (по версии Lingvo 8.0, честное слово, к
английским терминам так привыкаешь, что порой не можешь подобрать адекватный перевод, да и есть вопрос:
"а нужен ли он?", т.к. английская терминология точнее, да и это все-таки... Хотя,
для понимания перевод нужен...). MBR состоит из трех основных частей:

• Код, который позволит запустить загрузочный сектор с одного из четырех возможных
  разделов (partition).
• Таблица разделов (partition table), записанная со смещением на 446 байт.
  Она содержит четыре записи, по 16 байт каждая
• "" числа 55h и AAh в 510 и 511 байте соответственно.

Про "" числа мы уже знаем, что это признак "" загрузочного сектора, который
очень любит BIOS.
Записи в таблице разделов имеют очень простую структуру:

Смещение	Размер	Описание
00h	1 байт	Флаг типа раздела (0=не загрузочный, 80h=загрузочный, или '')
01h	1 байт	Головка, на которой начинается раздел
02h	2 байта	Первые десять бит содержат номер цилиндра, с которого начинается раздел, последние шесть - номер сектора, с которого начинается раздел.
04h	1 байт	Индикатор/указатель/код файловой системы или операционной системы, находящейся на этом разделе.
05h	1 байт	Головка, на которой раздел заканчивается
06h	2 байта	Первые десять бит - номер последнего цилиндра раздела, последние шесть - номер сектора, на котором раздел заканчивается.
08h	4 байта	32-битный LBA номер первого сектора раздела
0Ch	4 байта	32-битный LBA количество секторов в разделе

Оччень просто, правда?

О самом "", о коде, который грузит загрузочный сектор чуть дальше.

И одно маленькое замечание: теоретически винчестер может и не содержать MBR, а иметь по этому
адресу, как и старая добрая дискетка (жизненное наблюдение владельца ноутбука БЕЗ floppy
привода - хоть раз в месяц, но случаются ситуации, когда тот самый флоппи-драйв нужен позарез! а нету...), самый настоящий загрузочный сектор. Но на сегодняшний день это экзотика, так что не расстраивайтесь
не зря читали, все что выше про MBR

Как загружается bootsector?

Самый простой процесс загрузки bootsector'a - при загрузке его с дискеты. В этом случае
BIOS просто читает первый сектор дискеты в память со смещением 0000:7C00h, после чего
проверяет его на "" (обращается по абсолютному адресу 0000:7DFEh (0000:7C00h + 510)
в поисках знакомого нам "" числа. Если все в порядке, начинается выполнение кода bootsector'а
с адреса 0000:7C00h, если нет, то выдается сообщение об ошибке.

Все выглядит несколько веселее, если загрузка идет с HDD. Как мы уже выяснили, винчестер в первом секторе содержит MBR,
но BIOS все равно грузит его по тому же адресу, что и для дискеты: 0000:7C00h.
Как правило (хотя это не стандарт!) код MBR перемещает сам себя ниже, с адреса 0000:0600. Уже
оттуда код MBR начинает проверять таблицу разделов на предмет наличия в ней раздела, помеченного как "active" или
"bootable", то есть того, с которого должна начаться загрузка. Как только он находит такой раздел, он загружает его
первый сектор по адресу 0000:7C00h и передает туда управление (вот почему MBR смещает собственный код
ниже!).

Еще одна маленькая особенность: после поиска активного раздела, MBR оставляет в регистре DL(младший байт регистров DX, EDX)значение 80h, которое он использовал при сравнении, прочитанного флага
типа раздела. При загрузке с дискеты DL будет содержать 00h, таким образом
загрузчик может узнать, откуда он был запущен.

Основные задачи загрузочного сектора

Загрузочный сектор, в первую очередь, должен инициализироват все необходимые ему регистры процессора, так
как разные версии BIOS от разных производителей могут оставлять в регистрах различные значения.
Далее задача загрузочного сектора проста: подготовить все, чтобы стартовать "родную" ОС. Но вся
проблема в том, что ОС может быть и не одна, а значит загрузчик должен уметь "" и с
другими операционными системами. Код должен уметь разбираться с разными файловыми системами, чтобы
читать оттуда и иметь меню для выбора ОС, тогда это будет загрузчик, называемый уже
Boot Manager, т.е. загрузки! Для простейшего случая - одна ОС, один раздел - это все,
конечно, излишества, но, повторюсь, загрузчик должен уметь это делать. А еще
учтите, что он должен умещаться в 512 байт! Неплохая задачка, не правда ли?

В качестве примера хорошего загрузчика я бы привел GRUB, он помещается в 512 байт и умеет работать с
FAT, FAT32, EXT2, EXT3, ReiserFS. Хотя, он может и не ограничиваться отведенным ему местом и
будет рад обнаружить конфигурационны файл на своем разделе (про GRUB можно писать долго, если
интересно - сходите на www.gnu.org/software/grub/).
И на этом мы переходим к более интересным случаям: когда загрузчик
не помещается целиком в отведенные ему 512 байт.

В этом случае возникает необходимость загрузить вторую часть загрузчика (частенько
ее называют просто "вторичным "). И здесь есть три случая:

• Диск не имеет файловой
  В этом случае предполагается, что вторая часть загрузчика располагается сразу за первой, то есть
  в следующем секторе, вывод простой - надо читать! При этом загрузчик должен знать, сколько
  секторов ему необходимо прочитать.
  
• Диск может быть имеет, а может и нет, файловую
  Используется специальный блок, который находит вторичный загрузчик. Это, пожалуй, самый сложный случай,
  приходится "" очень много - и сколько читать, если диск не имеет файловую систему, и знать
  откуда брать, если имеет, да еще надо уметь контактировать с разными ФС. А у нас всего 512 байт под загрузочный
  сектор, становится грустно...
  
• Диск имеет файловую
  Используется файловая система. Лучше, конечно, чем предыдущий случай, но тоже не сахар - надо
  знать разные ФС. Хотя, повторюсь, мы рассматриваем пример загрузчика, в простейшем
  случае ФС одна.
  

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

Грузим ядро

Загрузчик должен прочитать ядро в память и передать ему управление. При этом
читать мы узнаем на предыдущем шаге (через ФС, или посекторно), а должен знать загрузчик.
Продвинутые загрузчики позволяют пройтись по ФС (случай с диском без ФС не рассматриваем -
это крайняя редкость) самому (т.е. предоставляют командную строку!) и выбрать нужное ядро.
Казалось бы все просто, но нет и тут может быть множество подвохов, да и было бы неинтересно,
если бы все было бы так просто.

Во-первых, ядро надо проверить! Умеет ли загрузчик с ним работать, т.е. знает ли он его формат?
Нужен ли ядру 32-битный режим
работы процессора? Включать/выключать A20? Необходима ли релокация в памяти? Хватит ли памяти вообще???
Только после выяснения всех этих вопросов загрузчик может что-то делать.

После выяснения всего этого загрузчик готовится к загрузке и соотвественно включает/выключает A20,
переводит/выводит процессор из 32-битного режима и т.д.
Только после этого всего ядро может быть загружено. И оно грузится!
Загрузчик должен посмотреть, сжато ли ядро? Если да, то распаковать его. После этого приходим к вопросу:
надо ли ядро копировать (перемещать) в памяти? Если да, то копируем.

Загрузчик также может передавать какую-то информацию ядру, например,
параметры загрузки ОС.

Некоторые загрузчики, при "" файловой системы, тем не менее предлагают загрузить с нее ОС. В этом случае
управление передается предполагаемомузагрузчику, который должен находиться в начале соответствующего раздела.

А может хватит?

Фуф! Неплохо, правда? На самом деле, как правило, загрузка
идет по простейшему пути, и ядро ни коим образом не проверяется, однако, файловая система используется.

На десерт: в приложении к этому письму (Доступно ) Вы найдете программку wba.com, она умеет записывать загрузочные
сектора на дискеты. Таким образом, у Вас есть возможность "побаловаться" с загрузочным сектором и
написать загрузчик, который будет что-то делать, что - на Ваше усмотрение!

Ну и чтобы было еще интереснее, в приложении еще один файл - sampleboot.asm,
это пример загрузчика, который загружает стороннюю программу (можете подсунуть ядро ОС! правда
какой, чтобы уместилась на дискете?). Сама программа - отдельный .asm файл - loadable_program.asm, а для того, чтобы все записать на дискету последовательно(!), приложен еще один файл - Disk_img.asm, он подобьет в кучу загрузчик и программку. Записать же все на дискету поможет wba.com. Все ассемблерные программки прекрасно компилируются с
помощью Nasm, удачи в творческих поисках! Только помните, что за любые последствия, связанные
с использованием этих файлов, мы ответственностине несем! Так что осторожнее, не перепишите
MBR своего любимого диска!