OSDev

Раз ты сделал две версии загрузчика для FAT32, значит не удалось. Кроме того, возможно, "удалось" только путем выбрасывания полезного кода. Те же дополнительные проверки размера памяти и т.п. могут стать критическими для текущего размера загрузчика.

Ты видимо хочешь сказать, что VolID можно использовать для идентификации раздела не только в пределах одного диска. Но мой BDI конвертируется ядром в структуру размером 32 байта (минимум) еще в реальном режиме, при этом в ней не остается номера диска BIOS, только - физическое местоположение диска и номер раздела на диске.

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

OK. Если я правильно понял, ты считаешь память размером 600h+608 кб гарантированно присутствующей (это приемлемо, хотя лично я без проверки иногда еще могу заюзать участок 7E00h-7FFFh, но не выше), тогда ты должен проверять доступность лежащей выше этой отметки памяти для ее использования в служебных целях (или для загрузки еще немного более крупного образа). Но если ты не делаешь проверки, как понять, доступна она или нет? А если даже станешь делать проверку и окажется, что эта память недоступна или доступна в недостаточном количестве, тогда какую память использовать для служебных целей?

Какой нехороший пользователь :))) Не делает то, что ему предписано! От этого программы и работают с глюками! Ты хотя бы загружай только первые 608 кб файла (уже нужна проверка его размера), если уж не выдаешь сообщение об ошибке.

Понятно, что "вверх" (у тебя перед адресом загрузки образа только 256 байт свободных остается), но тут возвращаемся к тому, о чем я уже говорил. Чтобы что-то не трогать, нужно знать где это что-то находится, а ты проверку размера доступной (базовой) памяти не выполняешь. И как ты не трогаешь EBDA, если считаешь 32 кб доступными для служебных целей? (1,5+608+32=641,5 кб!!!)

Даже у простого загрузчика могут быть потребности в памяти для служебных целей (примеры я уже приводил: стек, буферы для кэширования секторов CD/DVD, FAT и т.п.). Ты вроде бы не возражал против этого. Я оставил для этих целей 30,75 кб. Даже если ты откажешься от твоих гарантированных 608 кб для загрузки образа при сохранении такого маленького адреса загрузки, то тебе придется делать адрес области памяти для служебных целей плавающим, что менее удобно, чем иметь фиксированную область для этих целей.

OK. А я загрузчики, не превосходящие по размеру 1 кб могу не перемещать вообще, а превосходящие перемещать частично или даже сделать так, чтобы лежащий выше отметки 8000h код отработал до выполнения загрузки образа. Как понимаешь, проблем еще меньше.

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

Не вопрос, хотя некоторая связь все-таки есть. BIOS возвращает размер доступной базовой памяти в килобайтах. Адрес загрузки ядра кратен 1 кб (8000h=32 кб). Размер ядра кратен 1 кб. Можно вести подсчет доступной базовой памяти в килобайтах:
количество_памяти_для_обоих_файлов_кб = количество_доступной_памяти_кб-32;
количество_памяти_для_драйвера_кб = количество_доступной_памяти_кб-32-размер_ядра_кб.
У тебя файл только один, поэтому кратность размера тебе не нужна (если ты не собираешься хоть как-то проверять корректность загружаемого файла; неужели ты его даже на нулевой размер не проверяешь?). А кратность адреса загрузки не помешает.

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

Эммм, давай рассуждать так. Я пробовал сделать одну версию. В 512 не вписывается при всём старании. Значит либо делать два сектора, либо два разных варианта. Сначала я сделал вариант с двумя секторами (иначе очень сложно отлаживать, в 512 отладочную часть уже не впихнуть). Но тут возникают свои тонкости, я уже говорил - формально FAT32 может не иметь места для второго сектора. Значит ЭТОТ случай надо решать отдельно, как ты писал, либо хранить второй сектор в каких-то других рамках (файл) с риском, например, потерять его (пользователь стёр) либо всё же вжиматься в 512. Полезный код в данном случае не выброшен. Просто один автоматизм перенесен без малейшего риска в другой автоматизм. Автоматическое определение доступа CHS/LBA можно без риска похерить, если есть утилита, которая всегда корректно автоматически определяет, какую именно версию загрузчика вписать. Если раздел полностью вписывается в лимиты CHS, то CHS доступ гарантированно будет работать. Если раздел не вписывается в лимиты CHS, то нет смысла писать что-то отличное от LBA, т.к. доступ ко всему разделу всё равно требует поддержки LBA со стороны BIOS. Поэтому я и утверждаю, что задачу решить удалось.
Иными словами, расширение кода загрузчика до двух секторов, с моей точки зрения, вполне возможное (и даже применявшееся!), но менее общее решение, в котором в данный момент нет необходимости.


Конечно. VolID однозначно указывает раздел среди всего месива установленных носителей.


Только эта структура, вероятно, создаётся не бут-лоадером, а фрагментом кода загруженного с диска образа? В таком случае имеет право на жизнь. Одно другому не мешает :) Кому-то VolID будет полезен, кто-то сам создаст структуры.


Но ведь это не означает ненужность VolID в общем случае, правда? Это только означает, что конкретно в твоём случае ты, возможно, успешно обходишся без него. :)


Скажем так. Формально, EBDA (ведь о ней идёт речь, а не о физическом объёме памяти:) конечно в размерах ничем не ограничена. Однако, она располагается в самом критическом участке памяти - базовой памяти. Поэтому производители BIOS-ов делают её минимально возможного размера, в которой хранятся только действительно важные данные. (Этот вопрос в своё время меня остро волновал). Мои исследования (полтора десятка разных ПК и несколько ноутбуков) и анализ имеющихся данных в интернет на эту тему привёл к следующему заключению. В большинстве случаев EBDA имеет размер 1-2к. Иногда до 4к. Отдельные экземпляры (мне таковые не встречались) - 6к. Максимум, известный на сегодня по отзывам - 8к. Таким образом, технически, конечно можно потратить ещё несколько команд на проверку на размер. Но давай подумаем, что я выиграю? Несколько килобайт области нестабильности? Так ведь именно нестабильности я и пытаюсь избежать. Мне кажется более разумным в данном случае оставить верхние "к" в покое с некоторым запасом и забыть про них.


Разумная мысль. Пожалуй, я переработаю этот фрагмент.


1.5 входят в 32. Там не верхние 32, а всего 32. Тут чисто количественное соображение, причём с запасом примерно в 20к, я уже говорил. Но с введением проверки я, пожалуй, увеличу лимит размера загружаемого образа. Посмотрим.


- Нет проблем...
- А у меня проблем ещё меньше.
:)))


По поводу кратностей, проверок, контрольных сумм и пр. Я ставил задачей дать максимальную гибкость в использовании загрузчика, а не наложить максимум ограничений на пользователя. Че-ку вполне достаточно будет написать свой "Hello, World!\n" и расслабиться, а я заставлю его штудировать спецификации подсчёта и генерации контрольной суммы и следить за кратностью размера файла. Да он просто плюнет на такой загрузчик!
С другой стороны, если тебе нужна кратность, КС и база 8000h, добавь в начало маааленький кусочек кода - релокатор и верифайер, это ведь не проблема. Проверка будет вполне нормально работать, ничего не сломается.


Вот и пусть релокатор/верифайер его не запускают :) Вопрос на самом деле лишён смысла. То ты предлагаешь расширить бут за счёт внешнего хранения части кода (в т.ч. в отдельном файле), то вдруг категорически протестуешь против хранения пары десятков байт в загружаемом образе :) А я же говорю, что ФАКТИЧЕСКИ это и делаю - гружу заданный образ и поручаю ему дальнейшую работу, как ему будет удобно. Т.е. переношу кусочек кода из одного сектора в другой, подгружаемый, вот и всё.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Я делаю простые проверки и при загрузке bootex.bin. Что касается "верифайера" в самом образе, то ты мне предлагаешь его запускать вообще без каких-либо проверок (он же находится в начале и запускается первым)? А если на месте файла ядра случайно оказался одноименный текстовый файл? Вообще-то при запуске любого исполняемого файла выполняют простейшие проверки на наличие сигнатур, непротиворечивость значений полей и т.п. И чем их больше, тем надежнее. От того что загружаемые нашими первичными загрузчиками бинарники не имеют какого-то определенного формата исполняемых файлов, они не перестаю быть исполняемыми файлами. Времена com-файлов прошли и, надеюсь, прошли безвозвратно. Конечно, я вряд ли когда-нибудь стану проверять контрольную сумму загружаемого файла в первичном загрузчике, но при использовании "родного" вторичного загрузчика я это делаю. Меня даже не смущает, что сумма пересчитывается два раза - во вторичном загрузчике и в самом ядре, т.к. для "родного" вторичного загрузчика пока не определено какой-то специальной точки входа, позволяющей обойти "верифайер". Кстати, сложность использования простого (не использующего расширенную память) вторичного загрузчика - еще одно следствие малого количества доступной (базовой) памяти для служебных нужд (во я придираюсь! :D не воспринимай это, как желание всеми способами принизить твою работу, просто походу пришло на ум). Конечно я не призываю тебя что-то исправлять, "делать как делаю я", а даю пищу для размышлений. Тем более что я сам имею упрощенные загрузчики, в которых не проверяется ничего кроме размера загружаемого файла. Кстати, ты ничего не ответил на мой вопрос насчет проверки файла на нулевой размер. Думаю, уж это точно нужно делать всем. Уж слишком по-ламерски передавать управление по адресу памяти, куда ничего не загружено. Можешь ввести и более конкретное ограничение на минимальный размер файла, т.е. не просто >0.

Это как?? 8-0
"Вот идёшь ты по пустыне и вдруг из-за угла появляется танк" (с) армейский юмор )))
Я могу сказать одно: есть проверка или нет, результат будет один, - система не загрузится, причём текстовый файл вместо ядра - это не просто "ещё не отформатированный пользователем раздел", а результат какой-то системной катастрофы. Проверка ситуацию не изменит, нужно хирургическое вмешательство. Проверка реально необходима только там, где она обеспечивает работоспособность и устойчивость системы.
Однако, сказанное не означает, что я против проверки вообще. Моё ИМХО на эту тему таково: проверка целостности должна быть обязательно! Только не простенькая, типа контрольной суммы, а стопудово надёжная. Например, это должна быть цифровая подпись. И вот почему. Пока мы пишем простенькую ось для тетриса - это одно. Но как только ось начинает использоваться для банковских, военных, космических, медицинских, правительственных и прочих критических целей, попытка проникновения в систему (а где начинать внедрение, как не в ядре?) может стоить очень дорого. Может, даже, чьих-то жизней.


Это проверяется.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

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

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

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

Вышла версия 1.1.

В новой версии:

• VolumeID теперь передаётся в EBX вместо CX:BX.
  Все загрузочные секторы:
  
  • Устранена ошибка загрузки на некоторых системах;
  • Добавлен контроль верхней границы загружаемого файла в 620к;
  • Добавлено получение параметров диска BIOS для загрузки в режиме CHS независимо от способа трансляции;
  • Оптимизирован код.
  FAT32:
  
  • Устранена ошибка загрузки больших файлов.
  boot.exe:
  
  • Добавлена поддержка Vista/Windows 7;
  • Добавлена поддержка логических дисков;
  • Добавлена блокировка файла/логического диска при записи сектора;
  • Улучшено распознавание файловой системы.

Честно говоря, не думал, что так придётся потеть над начальной загрузкой. Все эти две недели вместо работы над CDFS, как я планировал, дотачивал имеющийся код. Действительно процесс ловли тонких багов на разных системах превращается в адский труд. Столкнулся с двумя ошибками в BIOSах. Узнал много нового про работу многих BIOSов.


Мне сложно ответить на этот вопрос, т.к. я не много знаю MBR-загрузчиков. Полагаю, основное отличие в том, что он использует и передаёт по цепочке Drive number, полученный в DL от BIOS. Правда, в свете проведенных исследований польза от этого в определённой степени сомнительна.


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


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

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

+1. Это нужно было сделать сразу. Я сохраненные на диске CHS-координаты/параметры вообще никак не использую. В некоторых бета-версиях может присутствовать проверка на соответствие CHS-координат/параметров текущей трехмерной геометрии BIOS, но это только в целях тестирования.

Такое поведение сейчас можно считать стандартным (MBR-загрузчик Vista/Seven делает это целенаправленно, другие пользуются тем, что функции дискового сервиса BIOS не разрушают номер диска в dl). Т.е. получается, что твой MBR-загрузчик нужен только для "полного комплекта", ну и для собственного самообразования )))

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

Edited: Кстати, 0xAA54 это не только 0xAA55-1, но и 0xAA54-0 ;)

Ну да. В первую очередь для комплекта.
Ума не приложу, что туда ещё можно разместить общественно полезного. Разве что выбор активного раздела, если их больше одного. Правда больше одного активного раздела противоречит спецификациям и считается недопустимым.


Пользы нет в том смысле, что сейчас все BIOSы шибко умные. Прежде, чем начать загрузку с устройства, они смотрят первый сектор диска на предмет, что там лежит. Если это загрузочный сектор FAT, они предлагают грузится с диска 0. Мало того, они после загрузки ещё и патчят сектор, вписывая туда BS_DrvNum напрямую. Так вот, если они обнаруживают там MBR, они всегда используют для загрузки диск 80h. Таким образом, 80h можно легко и без опаски хардкодить в MBR, ничего другого там никогда не будет.


Да, пропатчить можно легко.


Разбираешь на запчасти? :)))
Формально - да. А реально такого никак быть не может, т.к. функции BIOS, которые не поддерживаются, не должны трогать никаких регистров, кроме бита C.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

Эту тему легко можно развить, добавив что-нибудь новое. Например, у меня есть jumbo (выбор любого раздела по введенному номеру при нажатом Alt'е, загрузка из дополнительных разделов внутри расширенного) и alter (выбор альтернативного загрузочного раздела при нажатом Alt'е). Есть идея объединить основные функции этих загрузчиков в одном. Можем обсудить.

Это верно в подавляющем большинстве случаев, но не всегда. Существуют BIOS'ы, которые не сбрасывают номер диска в 80h для второго и последующих жестких дисков в загрузочной цепочке, которые используют для флешки (трактуемой как USB-HDD) отличный от 80h номер, даже если она находится первой в загрузочной цепочке. Поэтому в плане универсальности польза все-таки есть.

Что касается сброса номера диска в 0, то это возможно, когда у тебя явно задана опция USB-FDD или Super Floppy (здесь у меня есть небольшие сомнения), либо когда BIOS путем автодетекта выбирает эту опцию. Пропатчивания BS_DrvNum в ноль не замечал, может из-за того, что никакого негативного влияния на мою схему загрузки это не оказывает (в первичных загрузчиках я использую исключительно переданное в dl значение).

Не ))) Просто отладчиком прошелся. ...В поисках новых идей и ответа на вопрос, который уже успел задать здесь(насчет дополнительных возможностей).

Этот механизм может использоваться не только для отсеивания старых версий BIOS, но и для дальнейшего развития и идентификации новых версий. Конечно очень мала вероятность, что текущий интерфейс будет изъят и заменен на новый, в котором в ответ на 55AAh будет возвращаться 0AA54h, но она есть. Что касается старых версий BIOS, то их поведение в случае неверных входных параметров очень трудно предсказать, даже если речь идет о значении регистра ah, хотя в общем тут ты прав.