OSDev

Всем доброго времени суток!
Вообще, цель изначально стоит в написании эдакого продвинутого загрузчика, который будет проверять наличие USB ключа, спрашивать его пароль ну и там дальше уже при правильном вводе пароля переходить на загрузчики ОС, собственно.
Изначально была написана ОС для защищённого режима, т.к. опыт работы в ЗР у меня уже был, и никакого особо подвоха в его использовании я не узрел.
Потом ВНЕЗАПНО открылась проблема с USB клавой. Ведь если искать USB девайсы, то придётся сбрасывать все порты, и придётся писать драйвер клавы.
Написал драйвер клавы. Далее открылась ещё одна проблема - BIOS после отработки моей программы управление хост-контроллерами, естественно, не заберёт, и клаву не переинициализирует. Т.е. получится, что в нативных загрузчиках, на которые мы будем прыгать, клава работать не будет, и если там будет выбор какой-то опции (например, выбор ОС или выбор режима загрузки для винды), то пользователь ничего сделать не сможет.
Путём долгих раздумий решили сделать следующее:
1. Переписать загрузчик под реальный/нереальный режимы
2. Не сбрасывать контроллеры после отработки нашей программы, чтобы драйвер клавиатуры работал и перенаправлял всё, что получит от клавы, в порт 8042. Т.е. по сути, должно работать прерывание BIOS int 16h.

Это было вступление. А теперь, собственно, вопросы =)

1. Будет ли вообще это работать? Если нет, то почему? И какие есть варианты в данном случае и использовать USB клаву в нашей программе, и оставить её рабочей дальше?
2. Адреса EHCI и OHCI находятся в верхней памяти (выше 1 Мб), т.е. без нереального режима с ними общаться не получится. Я правильно понимаю?
3. Я пишу загрузчик на fasm, а ядро на GCC (иногда с ассемблерными вставками). Есть ли что-то, чего стОит опасаться? Особенно интересует GCC, как хорошо он поддерживает 16-битный код.
4. Адресуюсь к верхним адресам через fs. ds и cs - 16-битной границе. Чую, где-то неправильно делаю, может стоит снять границы с ds и cs, и уже работать тогда, как будто мы в защищённом режиме, т.е. не ориентируясь ни на какие сегментные регистры?

Пока вроде всё. Очень расчитываю на поддержку опытных мира сего =)

Я думаю стоит загрузчик писать на чистом асме и в реальном режиме. BIOS поддерживает работу с флешками через int 0x13 наравне с жёсткими дисками. Разумеется, будет и клавиатура USB работать.И с драйверами пока не будет запущена ОС возиться не придёться.

Через int 0x13 BIOS работает с флэшками. Мне нужно работать с USB ключом, который Legacy устройством не является. Т.е. BIOS при инициализации его не находит вообще, и мне по-любому придётся его искать вручную со всеми вытекающими.

Чтобы компьютер мог включить только хозяин, в настройках BIOS можно задать пароль.
Существуют и специальные решения, с использованием флешки-ключа и шифрования системного диска http://technet.microsoft.com/ru-ru/maga ... ocker.aspx
Без шифрования диска защита компьютера бессмысленна.

Вместо Flash можно попробовать использовать другие носители: Mini-CD, Floppy.

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

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

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

4. По идее BIOS должно быть пофиг, какие сегментные регистры ты используешь для работы в нереальном режиме. В нереальном режиме базовые адреса сегментов должны устанавливаться корректными для реального режима. А лимиты ты можешь задать произвольно, но естественно код, указатель стека и параметры для BIOS должны оставаться в рамках 16-разрядных смещений, поэтому увеличивать лимит cs особого смысла нет - появится соблазн выполнять код со смещениями > 0xFFFF, что недопустимо.

Ещё раз повторяю, ЭТО НЕ ФЛЭШКА! Это аппаратный ключ, т.е. по сути USB криптомодуль

А пароль БИОС - это, пардон, фуфло, и едва ли тянет на минимальный уровень безопасности.
Шифрование диска будет, но это потом.


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


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


Ну вот хотелось бы обойтись без написания на ассемблере.


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

BitLocker должен уметь его использовать. Это же специализированное решение.

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

Понятно, тогда как насчет софт-ресета?

А разве BIOS выполняет эмуляцию не в режиме SMM? У меня почему-то USB-клавиатура продолжает работать и в PM через 8042-интерфейс.

Тогда защищенный режим.

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

BIOS использует cs, ds и es. Они должны быть строго 16-битными, поэтому продолжай использовать регистры fs и gs.
Касательно "нереального" режима, подвох может быть вот в чём. Поскольку BIOS тоже использует этот режим для работы с USB, значит он тоже перепрограммирует сегментные регистры (ds, es, fs, gs временно или постоянно). Соответственно, твоя система должна быть устойчива к возможным изменениям регистров, и при необходимости их перенастраивать. Например, BIOS может после каждого использования сбрасывать fs в 16-битный режим.