Определение загрузочного устройства.

я осей много знаю. и секретные даже(военной авиации). и свою писал.
да и загрузочный dvd у меня почему-то с эмуляцией.

 

Изначально был задан совсем другой вопрос. Мне хватает значения DL, чтобы определять загрузочное устройство. Да, возможны накладки, но опять-таки они возникают редко. Основным средством детекта действительно является функция 48h, но далеко не единственным. Об этом уже много говорил - не хочу повторять. И с USB проблем нет - вникаем в EDD Spec. - я пока законченную загрузку с USB выполнить не могу (дров нет), поэтому не опишу полную картину, но когда экспериментировал с первичным детектом разнообразных загрузочных устройств, получал в том числе и структуру, описывающую устройство с USB-интерфейсом, т.е. при наличии соответствующего драйвера был бы шанс загрузиться с USB-девайса и у текущей сборки ядра. Эмуляцию при загрузке с CD/DVD не использую, но это уже вопрос в сфере стандартов конкретной оси - для загрузки моей оси нужно делать образ без эмуляции.

 

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

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

 

Phantom_84

Именно. Первоначально, все выглядело красиво. Получаем Dl, по EDD находим порты, и так узнаем с какого устройства загрузились.
Простейший тест показал, что Dl не всегда содержит 0x80, хотя проверялась загрузка только с винта. Вот и задал вопрос здесь.

Второй вариант, использование Boot Bios specification, предложенный Pavia, был опробован, правда давно. Но тогда так и не смог найти точку входа. В общем в 8м посте я уже отписывался на эту тему. Может не достаточно вник, может машина была слишком старая. Еще раз перелистал саму документацию, версии 1.1, но так и не увидел, как найти точку входа. Может кто пальцем ткнет, на какой странице это описано.

Третий вариант. Писать собственный загрузчик, который бы гарантированно передавал Dl моему коду не представляется возможным.
Некоторые ОС переписывают код в MBR при установке. Не все ОС можно загрузить передав управление их BOOT сектору. Точнее не у всех ОС загрузчик живет первом секторе раздела. Поведение меняется, но не факт, что конечный пользователь позаботится о сохранении моего кода в MBR, и не факт, что при установке своей системы он озаботится настроить ее на на загрузку через BOOT сектор, а не MBR. И самое прикольное, что не все BIOS при загрузке с флешки вызывают код из MBR. То есть загрузчик трогать нельзя.

Четвертый вариант, Делать некий ID внутри своего кода, а потом сканить все устройства на его наличие. Я во первых сильно сомневаюсь, что хватит места для кода сканера. Ведь сканить три типа USB, два (а по уму три) типа IDE, да еще FDD. Нужно учесть что диск может быть разбит без использования MBR, Что на IDE может висеть не HDD а CD/DVD-ROM или вообще райд. Короче не реал. Есть еще другая причина, по чему не хочется что-то вообще трогать внутри своего кода. Если вкратце, то два слова вдогонку "инсталятор" и "райд".

Пятый вариант, это поиск SIG из MBR даже не рассматривается, так как обладает всеми недостатками 4го, плюс добавляет несколько новых.

Если я пропустил ваш вариант, и он отличается от описанных выше, повторите пожалуйста.

И вопрос, раз разбирались с загрузкой с USB. Что передает в этом случае 13/48?

 

Dl и не должен быть всегда 80h.
для этого он и передается, чтоб ты не думал что привод именно 80h

а если bios не вызовет твой загрузчик-то не запустится твоя прога. и тебе не зачем бутет определять откуда загрузилась система(так как она не загрузится без boot)

 

abcd008 Вы хоть раз можете дочитать сообщение до конца?
Тогда может хотя бы сами себе перестанете противоречить.

 

У меня основная цель не до портов добраться, а сформировать структуру, наиболее точно описывающую местоположение устройства. Порты иногда проще получить, чем сформировать подобную структуру. Например, таблица DPTE появилась раньше, чем "Device Path", поэтому порты можно извлечь из DPTE, а вот определять "координаты устройства" приходится с помощью сканирования на шине.

Мне это давно известно, хотя к примеру в M$ еще сравнительно недавно не учитывали подобное положение дел. Попытка что-либо изменить в этом плане по-моему оказалась не слишком удачной. Они хотят, чтобы и зайцы остались целы, и волки сыты. Опять все свели к узаконенному пропатчиванию по аналогии с BPB. Только кто его будет делать? Пользователь что ли? Кстати производители BIOS тоже неравнодушны к этому вопросу. Опять начинают прикрывать возможность загрузки сразу с нескольких устройств одного и того же типа. Но прецедент уже создан, поэтому не нужно делать вид, что такой возможности никогда не существовало!

Я опираюсь на BIOS Boot Spec. только в плане содержимого регистра DL при старте загрузчика, и порядка использования int 18h/int 19h.

Я не понимаю, почему "некоторым ОС" можно переписывать код MBR, а другим нет. Также не понимаю, почему нельзя сделать код первичного загрузчика независящим от того, используется ли он на цельном устройстве или в разделе, а также не понимаю, почему нельзя использовать разбиение на разделы даже тогда, когда BIOS об этом не догадывается. И тем более не понимаю, почему нельзя считать пропуск запуска кода из MBR своеобразной опцией к принудительной загрузке с определенного раздела (причем замечу, что не с какого-либо произвольного раздела, а все-таки обычно с активного раздела). На самом деле самое прикольное заключается в том, что твои старания по адаптации процесса загрузки на основе значения регистра DL могут оказаться совершенно невостребованными в загружаемых ОС. Например, часто нет смысла использовать продвинутый MBR-загрузчик для загрузки ОС, которая все равно выберет номер загрузочного диска из BPB загрузочного раздела.

Вы не упомянули такое эффективное средство детекта в реальном режиме, как обращение к устройству через сервис BIOS (по номеру из регистра DL), а потом анализ состояния аппаратуры.

Это было не вчера, но точно помню о соответствии обнаруженных USB-устройств заявленному в EDD Spec. описанию. Хотя есть и примечательные результаты. Например, проделав сейчас похожий тест на своем ноуте, я получил следующий результат:

Код (Text):

1. size: 32
2. part: 1
3. type: 0
4. extra: 0
5. bus type: PCI
6. interface type: USB
7. interface: 00 00 00 00 00 00 00 00 ; PCI 0:0:0 (?), channel 0
8. device: 88 00 00 00 00 00 00 00

 

Здесь речь идет об MBR-загрузчиках.

 

Извини, откровенно почти ничего не понял в твоем посте.

Место положение чего и где, а главное зачем?

Вот это про "вообще", или о чем?

Да это ему просто было по барабану. Есть инсталятор, который скажет коду с какого логического устройства он должен грузится, и по этому ему начхать на DL. Код в MBR знает, что грузится можно только с 0x80. Для BOOT (FAT) секторов явно прописывается 0x00 / 0x80 в зависимости от устройства на которое записывается. Про ZIP речи нет, там своя песня.

Что значит одним можно, а другим нет? Всем можно.

То же не понял. Что за цельное устройство?

А BIOS не обязан догадываться о разделах. Загрузил код с первого сектора, нашел там сигнатуру, все в перед, передал управление.
Не нашел, значит устройство не загрузочное, поехали дальше. Разделы это уже не его забота. Про ZIP речи нет, там своя песня.

Я на эту тему уже не однократно говорил. Не факт, что есть таблица разделов в MBR. Не факт, что загрузочный раздел активен. Не факт, что загрузочный раздел вообще прописан в MBR. Кроме того, если не запускать код из MBR, то откуда пускать загрузчик ОС бедному BIOSу? Из BOOT сектора? А его там может и не быть вообще.

Я так понял, это простое лирическое отступление было.

А как вы себе это физически представляете? Про то, что практически не реально затолкнуть сканер всего поддерживаемого оборудования в один сектор я уже писал.
А тут еще придется писать ИИ для анализа и предсказания ответов. Ведь устройства могут поменять свое состояние с течением времени. Флешка ушла в ловповер, флопик выключил мотор, а винт занялся рекалибровкой. CD-ROM наконец догадался, что он один на шине, и с матером его обманули. А еще ошметки от старых команд могут придти. А главное смысл этого действа? Ну узнал я допустим, что вот этому DL соответствует вот эта железяка вот с этими портами. Это же не ответит на вопрос, с какой железяки я загрузился.

То есть, мягко скажем, информация из EDD идет лесом.

Возвращаясь, к моим баранам, мне в принципе теперь начхать на порты. Мне нужен только DL, и этого будет вполне достаточно.
В общем я уже решил вопрос, и тема приобрела чисто академический интерес. И пошел я по обходному пути, и он оказался короче, стоило только отказаться от первой загрузки (она же выполняла инсталляцию) с винта из раздела. Единственная была проблема, что программа могла затереть свой собственный код. Вот для этого мне то же нужны были порты. Но убрав свой код из юзер спесайса, я и эту проблему решил. Винты предполагается использовать только одного семейства, а у него минимум 16 треков свободно, 10ти метров мне хватит за глаза.

 

Я же написал, что местоположение устройства. Основная цель сформировать структуру, по формату похожую на структуру "Device Path", возвращаемую функцией 48h, причем даже тогда, когда функция 48h этого не делает. Затем, чтобы продолжать использовать это устройство в качестве загрузочного в защищенном режиме.

Ситуация: есть DPTE, нет "Device Path". Выход из ситуации: ищем устройство с такими же портами, которые указаны в DPTE.

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

Кстати я ошибся. В MBR-загрузчике висты/севен уже используется регистр DL, а пропатченная таблица разделов (первый байт в дескрипторе активного раздела может содержать отличный от 80h номер загрузочного диска) поддерживается еще со времен Windows 98/2K/XP, а может и раньше. Интересно, может и в первичном загрузчике висты/севен отказались от использования поля BS_DrvNum в пользу трансляции номера через MBR-загрузчик в регистре DL. Финальный код MBR-загрузчика выглядит многообещающе:

Код (Text):

1.         pop     dx
2.         xor     dh,dh
3.         jmp     0:7C00h

Хотя конечно нужно смотреть код первичного загрузчика.

Вот именно.

Не разбитое на разделы устройство.

Вот именно. Хотя с USB-загрузкой не все так гладко.

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

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

У меня трансляция значения DL, полученного от BIOS, распространяется вплоть до ядра (или вторичного загрузчика, который его может подменить), запускаемого в реальном режиме. Т.е. данное значение проходит и через MBR-загрузчик, и через первичный загрузчик. Детект (т.е. построение упомянутой выше структуры) выполняется уже в ядре, но еще в реальном режиме.

Почему?

Вы бы изначально нормально сформулировали свое "ТЗ", тогда бы взаимного недопонимания и оскорблений было в ветке значительно меньше. Я так и не понял, причем здесь юзер спэйс, под какой/какую платформу вы пишите и что в итоге должно получиться.

 

Платформа x86.
Специфичная задача, которая к этому форуму отношения не имеет, и не обсуждается за пределами фирмы.
Для ее реализации, нужен универсальный имидж. Который записывается в раздел HDD, или как вы говорите "цельное устройство" FDD/HDD/Flash/CD/DVD.
Задача, которую решаю я сейчас, это создание загрузчика, который считает программу из имиджа в память, и передаст ей управление.
Я подчеркну, имидж для всех подзадач один.

В принципе эту задачу можно разбить на несколько.
1) Это загрузка с CD/DVD. Тут проще. Или собственный загрузчик, который работает только с CD/DVD в режиме отсутствия эмуляции. Тут можно гарантировать получение и верность Dl. Если BIOS отдает неправильный Dl, то отследить это довольно просто, и вероятность такого поведения почти равна нулю (Иначе в частности ХРюша с CD не поставится, а занчит БИОСо писатели это должны были вылизать). Или сделать режим эмуляции, что сводится к задаче 2.
2) Загрузка с FLASH, тут задача определить, на какое устройство отмапили флешку (0x00/0x80). В принципе доверять DL можно, но стоит проверить конечно.
3) Загрузка с FDD. В принципе отмирающая, и вряд ли нужная функция, но частный случай второй задачи.
4) Это самая сложная задача, это загрузка из радела. Так как на прямую получить от BIOS Dl не получится, (наиболее вероятно, что управление передаст бут менеджер установленной ОС, и практически не вероятно, что код сидящий в MBR, то вот тут и возникает огромная проблема с вычислением, с какого же именно винта произошла загрузка. Доверять Dl практически не реально.

Это было для загрузчика. То есть загрузчику необходимо знать, Dl, или вычислить его, что бы не мучатся с загрузкой программы через порты, а использовать INT 0x13. В принципе то же не большая проблема, перебрал все Dl, и нашел нужный.... Если бы не одно но. В системе может быть более одной копии программы. То есть ситуация, что загружаемся с флешки, она мапится на 0x00, при этом на 0x80 живет винт с еще одной копией. Вообще, я подумал, что если на 0x00 есть копия программы, то можно смело считать, что загрузились с нее. Иначе с 0x80. Вариант с CD-ROM вообще обходится.

Это все, что касается загрузчика. В самой программе на входе уже можно ожидать корректного Dl, полученного от моего загрузчика.
Остается лишь сопоставить DL с физическим устройством. Тут главное определить, откуда произошла загрузка, что бы знать, где живут данные. Если не с винта то по барабану, окуда грузились. Если с винта то данные живут на винте. И причем на том, с которого грузились. Вот тут сразу встает вопрос, а можно ли доверять данным полученным через INT 0x13/0x48. То есть тип устройства. И если это винт, то номерам портов. Если винт в системе только один, то вопросов нет, данные на нем, и не важно, откуда грузились. А вот если их два? Если загрузка произошла с винта, то данные на загрузочном винте. Если нет, то только спрашивать пользователя. Вот тут я думаю опять схалтурить, и если винтов больше одного, спросить у пользователя, а не мучатся с вычислением устройства.

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

 

Ну вот опять. Вы толком задачу сформулировать не можете. Где тут задача определения загрузочного устройства? Её тут нет. Отсюда вывод вы нету задачу решаете.
Если имедж лежит на том устройстве с которого грузимся используем DL он будет всегда правильным.

Если он лежит на HDD, а вы загрузились с некоторого устройства. То ищем по всем HDD. Для поиска используем порты.

Это вы много хотите. Dl будет указывать на ваш загрузчик в любом случае. А этого достаточно. И не надо указывать пользователю на то, что он должен делать, а чего не должен.

 

Pavia Такое ощущение, что полностью и все мои посты читает один Phantom_84, остальные, же начинают отвечать удивив первое знакомое слово, и выливают полностью весь поток сознания, не взирая на то, что таких потоков было уже несколько.

Правильно. Ее тут нет. Она описана ниже. Что бы ее увидит, нужно было прочитать весь пост целиком.

Это уже наверно 6й или даже 7й пост, с подобным утверждением. Не понимаю цели повторения, но я уже отвечал, что не будет, и почему. Что бы не повторятся, вполне было достаточно прочитать другие мои посты в этой ветке.

 

А эта фирма случаем не вирусы выпускает? )))

Сразу возникает вопрос о размерах программы, в каком режиме процессора должна работать программа, должна ли она выбирать дополнительные данные из образа или достаточно, чтобы она сама была прочитана и запущена из образа. Сразу приходит на ум использование GRUB'а или по крайней мере используемой им технологии загрузки на основе int 13h в реальном (и/или нереальном) режиме процессора совместно с собственным форматом тома, совпадающим с форматом вашего образа. Это чтобы не париться с поддержкой различных ФС и и различных устройств на низком уровне. Кстати в этой ситуации использование эмуляции флоппика/харда на CD/DVD не выглядит уж таким неприемлемым вариантом.

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

Какие данные? Так все-таки требуется дополнительное считывание данных из образа в рамках программы? Или нужно просто путем сравнения понять, откуда выполнялась загрузка, чтобы знать, куда можно/нужно инсталлировать программу. Если я правильно понял, то фактически вам нужно сопоставлять DL с физическим устройством только для харда, чтобы выполнять низкоуровневое взаимодействие с ним для сокрытия данных, а с другими устройствами можно продолжать работать посредством BIOS. В BIOS Data Area вроде бы есть ячейка, в которой хранится номер последнего харда (наверное тоже самое возвращается функцией 8, но необходимы дополнительные проверки из-за багов некоторых BIOS - я об этом где-то читал).

Защищать видимо нужно дополнительный код? Иначе как ты собираешься загружаться с образа, который физически находится за пределами "юзер спэйс".

Непонятен еще один момент. Как я понял, ты хочешь на разбитом на разделы диске иметь возможность хранить образ совместно с установленной сторонней ОС. Но как ты собираешься его грузить, если изначально была настроена загрузка именно этой ОС? Получается, что нужно сделать "твой" раздел активным или установить собственный загрузчик, позволяющий выбирать загрузочный раздел. Причем чтобы не вносить изменения в текущий активный раздел, "собственный" загрузчик лучше установить в MBR (целиком или хотя бы его стартовую часть). А раз на практике нужно в любом случае вносить изменения в MBR, почему бы туда не инсталлировать "собственный" MBR-загрузчик, гарантирующий трансляцию значения DL.

Ой, я так польщен... ))) Но теперь для поддержания репутации придется читать ваши посты еще более внимательно... ((( Можно, я тоже буду невнимательным читателем? )))

 

По моему это повод для вас задуматься. Что же вы делаете не так.

 

)))
надо не загрузчик писать. а сразу BIOS свой. тогда точно dl дойдет)

 

Не не вирусы. Для вирусов есть более дешевые и менее технологически емкие приемы.
Хотя код, очень специфичный для вирусов будет использован, но для защиты от шаловливых ручек.

Знаешь, ты задал столько вопросов, что ответить на них просто не реально. Описание задач всех модулей занимает более 20 страниц машинописного текста.
Естественно, имеется три точки входа, живущих по строго определенным адресам. Из этих трех точек загружается 4й блок, который оценивает ситуацию, и принимает решение, какой следующий блок грузить. И вот этот самый 4й блок должен определить тип устройства с которого загрузились для принятия дальнейшего решения. Вариантов там масса. Но все упирается, в две простых проблемы. ГДЕ ВЗЯТЬ DL! Если на входе его нет. Все остальное вторично.

По барабану. Меньше, чем размер флешки но больше чем размер сектора.

В принципе можно сразу все в память затолкать. А можно и не заталкивать.

Навязывание пользователю Груба не входит в мои планы, и не возможно по ТЗ. Но пользователь сам, добровольно может захотеть поставить себе груб, и решение под него будет предоставлено. То же касается LILO, SysLinux, MsWindows, самопальных загрузчиков, и прочей лабуды. Использовать груб и подобное внутри своего имиджа бессмысленно.

А я и не собираюсь парится с ФС. Я всегда знаю, что и где лежит, и это жестко определяется при сборке имиджа.
Для блока данных ФС то же не нужна.

Данные лежат отдельно, и только на винте. В имижде их нет.

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

Чуть изменяя файлы конфигурации бот менеджера ОС. Или например, пользователь уже пользуется твоим загрузчиком. Создаем еще один раздел, туда посекторно льем имидж, твоему загрузчику объясняем, что альтернативную загрузку делать вот с этого раздела. Для большинства ос поступаем так же. Для продвинутых с SysLinux/Grub скармливаем имидж на прямую, без раздела. Даже для MS-DOS 6.22 и старше есть решения, и очень простые. И вот цена за эти простые решения, и есть секс с моим загрузчиком.

Неа Вроде выше объяснил, по чему. Или еще раз, практически все ОС имеют встроенный загрузчик, позволяющий грузить альтернативную ОС.

Вот он корень преткновения, добрались на конец, в который раз На практике вообще ни когда не придется вносить изменения в код MBR. Единственное исключение, что никакой ОС еще нет И вот это исключение, меня меньше всего радует.

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

В принципе, это грустно, особенно когда видно, что человек не очень хорошо разбирается в теме вопроса.
Я например, могу поспорить, что этот человек, не буду показывать пальцем, даже не сможет написать словесного алгоритма, как заполнить ТР в MBR для винта с 4мя первичными разделами, и как потом прочитать первый сектор активного раздела.

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

 

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

Вот упрощенный пример. Две точки входа. Первая находится по нулевому смещению и является загрузчиком образа для устройств, работающих через int 13h с 512-байтными секторами. В этом случае, думаю, можно использовать значение DL, переданное на точку входа (можно даже определять номер загрузочного, хотя и не активного раздела, если будет обеспечена поддержка "моей" Boot Spec.). Вторая находится по смещению (адресу), описанному в Multiboot Header'е файла-образа и является точкой входа реального и/или защищенного режима для GRUB'а или другого Multiboot Spec.-совместимого загрузчика. Здесь свои правила передачи номера загрузочного устройства. Любой из включенных загрузчиков предоставляет для "4го блока" единый интерфейс (передаваемые параметры и окружение).

 

Т.е. фактически в образе должно находиться несколько загрузчиков (по каждой точке входа)
Не "должно находиться", а находится.

Первая находится по нулевому смещению и является загрузчиком образа для устройств, работающих через int 13h с 512-байтными секторами. В этом случае, думаю, можно использовать значение DL, переданное на точку входа
Рыба и мочало, начинай с начало. Нет там корректного DL.

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