Почему я не могу вызвать прерывания BIOS из защищенного режима? - PullRequest
13 голосов
/ 26 апреля 2011

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

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

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

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

Ответы [ 3 ]

9 голосов
/ 03 мая 2011

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

6 голосов
/ 16 мая 2011

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

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

Например, `

  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`  

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

3 голосов
/ 26 апреля 2011

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...