Блог

Верно. Сегодня я потратил более трех часов, пытаясь понять, почему вы не можете вызвать ISR bios в защищенном режиме. Я понимаю, что после установки и IDT это не обязательно будет по обычному адресу для IVT, плюс сегменты не имеют фиксированного размера в защищенном режиме и т.д.. Но я все еще не понимаю, почему вы не можете просто создать один сегмент объемом 4 ГБ, сопоставить ваши IDT-сегменты с BIOS IVT, установить все в ring 0 и вызвать их. Разве это не должно сработать?

В большинстве статей либо говорится: «Помните, что вы не можете использовать прерывания BIOS в защищенном режиме!» без изучения предмета, либо они чрезвычайно описательны и ссылаются на ловушки, исключения, повторное отображение изображений, отсутствие прав и проблемы с сегментными регистрами в качестве причины этого.

Было бы чрезвычайно полезно, если бы кто-нибудь мог придумать более понятное для человека объяснение… Я не сомневаюсь в том, что говорится в статьях, я просто хочу понять, почему это такая «боль»!

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

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

Макс, возможно, вы могли бы создать драйвер устройства, работающий в кольце 0, который вызывает более простой ISR BIOS, если ОС работает в 16-разрядном защищенном режиме. Но в 32-разрядном режиме первое 16- или 32-разрядное смещение адреса или немедленное значение будет интерпретировано неправильно, и поток команд выйдет из синхронизации. В реальном или 16-разрядном защищенном режиме значения мгновенного действия и смещения по умолчанию имеют длину 16 бит, в 32-разрядном защищенном режиме они имеют длину 32 бита, а в 64-разрядном (long) режиме они имеют длину 32 или 64 бита. Таким образом, в ISR могут использоваться только смещения, представленные в байтах (< 128, если я правильно помню), и значения byte immediate.

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

Например, `

   mov ah, 0B8h  
  mov al, 000h  
  mov es, ax  
  mov byte ptr es:0, 'o'  
  mov byte ptr es:2, 'k'`
  

в реальном режиме в верхнем левом углу экрана текстового режима будут отображаться буквы «ok», но для того, чтобы это работало в 16-разрядном или 32-разрядном защищенном режиме, запись таблицы глобальных дескрипторов со смещением 0xB800 должна иметь базовый адрес 0x000B8000.

Но если вас устраивает запуск только в 16-разрядном защищенном режиме, то более распространенный код: `

   mov ax, 0B800h   
  mov es, ax  
  mov dword ptr es:0, 0076b076fh`  
  

должно работать так же хорошо.

Я возвращаюсь к старому материалу, так что это может быть немного не так, но одна из основных целей «защищенного» режима — изолировать конфиденциальный / безопасный код от кода приложения. В исходной спецификации было 4 уровня с 0 по 3. На практике я видел только кольцо 0 для операционной системы и кольцо 3 для приложений. Разрешение приложениям изменять или вызывать прерывания потенциально может открыть им черный ход в операционную систему. Таким образом, такие операции доступны только для кода, запущенного в кольце 0, а именно операционной системе. Единственный способ заставить ваш код выполняться в кольце 0 — это создать драйвер. Windows в основном загружает драйверы в свою собственную память ядра (хотя это имеет / меняется в Windows Vista / 7), запущенную в кольце 0.