OSDev

Решил сделать полное разделение памяти ядра и дров, т.е. дрова не имеют вообще никакого доступа к ядру. Решил все сегменты настроить так, чтобы дровам была доступна память выше 1МБ. Но тут встают проблемы в виде lgdt и wrmsr. Можно ли как-то запретить выполнение этих инструкций без запрета выполнения привилегированного кода? С запретом придется эмулировать привилегированные инструкции, что даст тормоза, поэтому хотелось бы избежать.

Заранее спасибо

Насколько я знаю, упомянутые команды относятся к выполняемым только в нулевом кольце, и запретить их без запрета других привилегированых команд не получится. Для выполнения привилегированного кода вам всё равно придется реализовывать системные вызовы, так что прослойка между пользовательским и привилегированным кодом будет в любом случае.
По поводу механизмов защиты х86 можно прочесть учебник Зубкова по ассемблеру, главу "Механизмы защиты". И речь там идет о том, что можно разрешить выполнение некоторых привилегированныхкоманд из режима пользователя настройкой флагов, например запрет прерываний и обращение к портам ввода-вывода.

Спасибо за ответ. Может, ещё кто чего напишет полезного.

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

Спасибо, но тогда другой вопрос. Ну вот засунул я все дрова в третье кольцо, выставил IOPL и т.д.. Но остается проблема с портами I/O. Можно также сделать системный вызов, который будет читать из порта и писать в него. Можно настроить битовую карту портов. Карта портов будет, конечно же, быстрее. Но вот как определить, к каким портам давать доступ, а к каким - нет? Например, запретили доступ к портам PCI, а драйвер, как раз, с ними работает. Или запретили доступ клавиатурному драйверу к портам клавиатуры. В общем, всё в таком духе.

Карты I/O плохи ещё тем что при переключении задач их придётся тоже переключать, а это весьма так повышает накладные расходы (кто не понял - стоит почитать про то почему аппаратное переключение задач никто не использует, а используют программное).

Сам в своё время думал про такое разделение прав, но в итоге пришёл к выводу что получается уж слишком много гемора и мало профита. Лучше разделять драйвера железа на требующие ring0 мелкие части (и вот их-то верифицировать) + основное тело, не требующее такого. У многих вещей (драйвера ФС, большая часть сетевого стека, cache manager) тогда даже может и не быть ring0 составляющей. Правда, тогда нужен продуманный быстрый IPC, чтобы не заниматься постоянным копированием между ядром и пользовательским пространством.

Конечно проще и надежнее (для системы в целом) работу с портами запихнуть в нулевое кольцо (вместе с инструкциями cli/sti и первичной обработкой прерываний). Но ради эксперимента можно сделать разделение портов с защитой между разными драйверами по принципу "кто первый попросит, тому и отдать". Я у себя использую именно такой принцип раздачи портов, но без защиты (не отслеживаю даже принадлежность портов), т.е. делаю это чисто в информационных целях, чтобы дрова знали о возможных конфликтах и могли во избежание неприятностей отказаться от использования "чужих" портов или даже полностью завершить свою работу.