Снова про MBR: загрузка с USB/CD

Сейчас это RAM, защищенная от записи. BIOS сам и строит - часто это почти точная копия ROM-BIOS. Возможно, есть и варианты аппаратного проецирования отдельных участков System BIOS под первым мегом, но я об этом не знаю.

 

А когда он успевает?

Поясняю вопрос. После cold start проц в RM, теневая база CS = 0FFFF0000h, EIP = 0FFF0h, т.е. LA первой инструкции = 0FFFFFFF0h (согласно мануалам). Там far jmp, перегружающий CS. И собсна все. После фар джампа мы в любом случае под первым метром (ибо RM), где ничего нет. В рамкам 16 байт построить свою копию и сделать тот же фар джамп сложновато, да и не делается ничего подобного (пример - биос qemu/bosch).

Или я совсем туплю?

 

Воот, этот вопрос меня тоже волновал) Вроде как аппаратно чипсетом он смапирован дважды. Во всяком случае после того как отработал ПОСТ, в эмуле биос остался в двух местах примапирован - на реальном железе пока не проверял, ибо это надо лезть в ПМ чтобы добраться до начального адреса...

Про то что на планки можно класть тоже предполагал, собственно и думал что это дело контроллера, просто что то вдруг задумался - а вдруг нет) Про то что другие устройства проецирутюся, это, конечно я знаю и помню... Но те же PCI вроде вообще где то в старших адресах, VGA по стандартному адресу, то есть все вроде учесть можно, если об остальном контроллер заботится. Да, БИОС вроде же сканит память, определяет сколько ее - не подскажете куда сохраняет? Что-то я в BDA не увидел такой записи.

В тему загрузчиков - сидел думал - как же это упихали в том же GRUBе загрузку с разных фатов в жалкие 512 байт, когда у меня одно определение фата и сопутствующие вычисления заняли почти половину. Решил проверить ГРУБ на вшивость, создал на флешке штук 10 файлов с именем в 255 символов, чтобы корневая директория фрагметировалась и располагалась не по соседним кластерам. Груб схавал на ура! Полез в код, и увидел читерство) Груб грузит секторами, ищет там тупо досовское имя "GRLDR " и дальше тупо от него отсчитывает смещение (09h что ли) по которому хранится номер кластера во всех фатах. Плевав на собственно ФАТ.
Правда я прервал эксперимент и так и не посмотрел, схавает ли он потом GRLDR если тот будет фрагментирован...

Я не знаю как у него реализовано дальше, но я себе наметил такой алгоритм: МБРовский лодер таким же методом ищет основной файл, а в нем драйвер для работы (нормальной!) с фатами в первом кластере умещу. В фат 32 эт 16 секторов, 8КБ - туда то влезет нормальный. А этим кодом уже спокойно пробегусь по фату, догружу лодер и ядро.

 

Авард делает так.

Нет не все куча проверок идет. И если выясняет что это холодный старт то копирует из адреса 0FFFF0000h биос во временную область разархивирует передает управление туда. А там уже код надо смотреть, но насколько я понимаю биос отключает ROM копирует себя в Shadow-RAM, хотя где именно он это делает я не нашел. Потом часть кода модифицируется.

 

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

 

P.S.
Если чисто смотреть по коду, то все таки Vic3Dexe прав - выполняется первая инструкция (джамп), потом ЦС получает новое значение в пределах 1го мега, и выполняется код биоса уже там, то есть на момент джампа мэп уже осуществлен. Далее (в древнейшем ами-биосе от 386го) идет некая настройка чипсета, потом собственно проверка на холодный старт, уже в нижнем метре.

То есть выполнить все эти действия по ремэпу можно разве что аппаратно, до первой инструкции.

 

А кто сказал, что в оригинальном варианте, хранящемся в ROM-BIOS, там far jump. Наверняка там какой-то внутрисегментный переход, а far jump мы видим уже в копии.

Есть еще EBDA. Кроме того, BIOS может под себя подмять какой-либо участок "расширенной" памяти, исключив его из карты доступной памяти.

Почему-то в своих изысканиях я так и не дошел до GRLDR (может, это GRUB 2), но то что в GRUB используется хитрая, хотя во многом и примитивная технология загрузки, это точно. Вот моя статья на эту тему: GRUB Internals.

Размер кластера может быть разным. Предпочитаю в MBR не впихивать код, работающий с файловыми системами. Просто немного расширил возможности MBR по работе с разделами, в том числе и логическими (ну те, что внутри расширенного). MBR грузит первичный загрузчик раздела, а тот целиком либо сразу ядро, либо для возможности "множественной" загрузки с одного раздела (я это называю Single Volume Multiboot) вторичный загрузчик, по формату похожий на файл ядра (различия фактически присутствуют только в именах, ну и в содержимом: файл ядра называется june.os или link.os, а вторичный загрузчик предположительно будет называться boot.os).

 

>А кто сказал, что в оригинальном варианте, хранящемся в ROM-BIOS, там far jump. Наверняка там какой-то внутрисегментный переход, а far jump мы видим уже в копии.

Ну ожидать можно всего, конечно... Но все же я дизасмил именно бинарник который шьется в РОМ. Если что еще есть, то оно уже не в биосе.
>Размер кластера может быть разным. Предпочитаю в MBR не впихивать код, работающий с файловыми системами.

Да, разным, но насколько я помню, чем меньше разрядность фата, тем больше кластер, то есть загружая 8кб я по любому окажусь в пределах первого кластера. В МБР я не буду пихать код работы с ФС, он будет в этих 8 кб.

>MBR грузит первичный загрузчик раздела, а тот целиком либо сразу ядро, либо для возможности "множественной" загрузки с одного раздела

Так в том то и вопрос - файл загрузчика/ядра может быть фрагментирован, как и корневая директория - как в таком случае загрузить из МБР (512 байт!) это ядро или стейдж два? Ну первый кластер можно найти методом груба, ок. ему не страшна фрагментированность корня. А дальше? Я вижу пока тот путь что я описал - первый кластер нашли, дальше в нем размещаем все необходимое чтобы догрузить искомый файл, будь он ядром или стейдж2 (я вообще тоже планирую этот файл сделать ядром и грузить его целиком)

 

Ты использовал реальную прошивку или образ BIOS от эмулятора? В последнем случае вполне может попасться far jump, т.к. некоторые эмуляторы начинают исполнение сразу с адресов теневой памяти под первым мегом и отображают BIOS именно туда.

А, понятно... метод grub'а. Ну тогда для нормальной работы твоего загрузчика нужна специальная процедура инсталляции, в процессе которой выполняется анализ файловой системы, чтобы понять, где именно будет находиться этот первый кластер. При этом размер загружаемого кода опять будет небольшим, т.к. ты должен ориентироваться на минимально возможный размер кластера, т.е. 512 байт.

Я же сказал. MBR грузит первичный загрузчик раздела, который уже в состоянии анализировать файловую систему раздела, в котором он находится. Этот загрузчик в состоянии загрузить файл с учетом его фрагментации. Более того, мои загрузчики загружают даже не один, а два файла, умещаясь при этом в одном или максимум в двух секторах. Для FAT32 второй сектор загрузчика можно разместить в разных местах раздела: либо - как это сделано в загрузчике от M$ - обычно во 2 секторе раздела (при нумерации от 0), либо - это уже мое ноу-хау - в начальном секторе для резервной копии загрузчика, т.е. обычно в 6 секторе раздела.

 

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

 

что-то у меня не получается..
я понимаю, это из ринг-0?

у меня код такой:
NTSTATUS DriverEntry( ... )
{
...
CheckMbr();
...
}
void CheckMbr()
{
__asm
{
mov ah, 0x08
mov dl, 0x42

int 0x13
}
}

вываливаюсь с TRAP_CAUSE_UNKNOW..
c чего бы это?

 

вау, из дрова юзать инт13.... )))

 

Medstrax
это совсем плохо? а как еще? через KINTERRUPT - это значительно сложнее...

 

Ну ты и сотворил... В виндах на этот случай уже имеются дрова. И что ты вообще хотел сделать, т.е. что ты имеешь в виду под "Check MBR"?

 

Phantom_84
хочу прочитать мбр.
что же не так-то? всмысле, а как иначе?

 

Читай PHYSICALDRIVE<N>. Это можно сделать даже в приложении.

 

Это к клерку, лень жевать

 

О! заработало! Спасибо!
я пробовал коннектиться к \Device\Harddiskdrive<n>, но у висты доступ закрыт..

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

 

всмысле, HaddiskVolume<n>

 

>Ты использовал реальную прошивку или образ BIOS от эмулятора?

Именно реальную.

>А, понятно... метод grub'а. Ну тогда для нормальной работы твоего загрузчика нужна специальная процедура инсталляции, в процессе которой выполняется анализ файловой системы, чтобы понять, где именно будет находиться этот первый кластер.

Дык первый кластер я сказал как груб ищет - он ищет ДирЭнтри по досовскому имени, от него по известному смещению во всех фатах (12,16,32) хранится искомый номер кластера.

>MBR грузит первичный загрузчик раздела
А он где должен храниться и чем ограничен размер? Как то этот вопрос я пропустил.