Программирование процессоров Intel x86 в защищённом режиме

Историческая справка

В 1982 году, с появлением процессора 80286, фирма Intel ввела понятие «режим работы процессора». Режим, совместимый с процессором 8086, был назван режимом реальной адресации (Real-Address Mode) или просто реальным (Real Mode), новый режим – защищённым (Protected Mode). Программный интерфейс процессора в разных режимах отличается весьма существенно, так, при работе в защищённом режиме, 80286 поддерживает управление памятью, виртуальную память (пока только для сегментов), переключение задач и уровни привилегий, то есть практически всё, что необходимо для реализации многозадачной операционной системы.

На этом прогресс не остановился, и в 1985 году был выпущен 32-разрядный процессор Intel386, который работал уже в трёх режимах:

• Оставшийся почти без изменений реальный режим.
• Творчески переработанный и расширенный защищённый режим (хотя и с сохранением обратной совместимости). Основные изменения: 32 разряда везде, где можно, возможность страничной адресации памяти, большое количество новых регистров.
• Режим виртуального 8086 (Virtual-8086 Mode, V86). Позволяет ОС, работающей в защищённом режиме, запускать программы, предназначенные для реального режима.

Последующие поколения процессоров добавили к программному интерфейсу защищенного режима несколько новых понятий, флагов и команд, но никаких фундаментальных изменений не принесли.

Обзор защищённого режима

Основное предназначение главы – описание задач, стоявших перед разработчиками защищённого режима и некоторых следствий из них. Задумываться на тему «зачем же они всё это придумали?» чрезвычайно полезно, так как только взгляд с этой точки зрения позволяет объяснить причины принятия тех или иных архитектурных решений. Как это ни странно, несмотря на не слишком большую сложность такого анализа, я не встретил ничего подобного ни в одном из источников.

В качестве примера – наиболее простая из виденных мною программ, переключающаяся в защищённый режим.

Управление памятью: сегменты и дескрипторы

Описание базового механизма управления памятью в защищённом режиме – сегментации (segmentation). Объясняются основные понятия, описывается упрощённый формат дескриптора сегмента (segment descriptor), глобальная таблица дескрипторов (Global Descriptor Table; GDT), упрощённый формат селектора (selector).

Примеры: unreal-mode и переключение сегмента кода.

Программные прерывания

Основные сведения об обработке прерываний в защищенном режиме: программные прерывания, таблица дескрипторов прерываний (Interrupt Descriptor Table, IDT), упрощённый формат дескриптора шлюза ловушки (trap gate descriptor).

Пример – обработка программного прерывания int 0.

Исключения

Рассуждения на тему «а зачем вообще нужны исключения», перечисление существующих типов исключений, описание отличий механизма обработки исключений от программных прерываний. Длинная, но несложная глава.

Пример – программа, приводящая к исключению #GP (General Protection) и успешно его обрабатывающая.

Внешние прерывания

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

Пример – программа, обрабатывающая прерывание от RTC (Real Time Clock, часы реального времени).

Теоретическое введение в защиту

Да, вы угадали. Начинается всё с рассуждений на тему «а зачем вообще нужна защита». Дальше всё как обычно: дескрипторы, уровни привилегий, DPL, CPL, RPL.

Пример – программа, приводящая к #GP из-за высокого уровня RPL, и успешно исправляющая ситуацию в обработчике исключения.

Введение в многозадачность: одна задача

Кратко описан сегмент состояния задачи (task state segment, TSS), его дескриптор, инструкция ltr. Глава-врезка. Всего пять страниц (вместе с кодом!), никаких рассуждений, очень простой пример, заданий нет вообще.

Защита: передача управления

Защита: ввод-вывод

Страничная адресация

Многозадачность

Приложение

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

• Исключение Double fault и связанные с ним вопросы.
• Немаскируемые прерывания (Nonmaskable Interrupt, NMI).
• Флаг Segment Present
• 32-х разрядные сегменты кода
• Всякие мелочи

Уровень детализации

Сначала два общеизвестных утверждения:

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

В приложении к курсу, это будет звучать так:

• Для того чтобы понять, как работает ОС, нужно спуститься на уровень глубже, и разобраться с защищённым режимом.
• Для того чтобы понять, зачем защищённый режим такой, какой он есть, нужно подняться на уровень выше, и посмотреть, как его использует ОС.

Именно это – выбранный уровень детализации. Описано, зачем вообще нужен защищённый режим, почему он именно такой, и как на его основе реализуются необходимые для работы ОС механизмы. Следующий шаг «вглубь» не делается, рассмотрение базы, на которой построен сам защищённый режим (особенностей реализации процессора) находится далеко за рамками курса.

Новая жизнь

Для системного программиста защищённый режим очень, очень сильно отличается от реального.

защищённый режим нужен для того, чтобы разрабатывать многозадачные операционные системы

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

Новые мысли

Как уже было сказано, основная мысль – поддержка многозадачных ОС. Чуть более подробно о том, что такое многозадачная ОС, что ей надо, и о чем ещё пришлось побеспокоиться разработчикам.

Мысль #1: Многозадачная ОС

Основное предназначение многозадачной ОС – позволять одновременное выполнение нескольких пользовательских приложений и не позволять им мешать друг другу. Кроме этого, ОС должна обеспечивать некоторое удобство программирования, иначе она вряд ли будет пользоваться успехом. Разберём по пунктам.

«Позволять одновременное выполнение нескольких пользовательских приложений» это:

• Поддерживать запуск нескольких приложений.
• Незаметно для приложений переключать процессор с одной задачи на другую.

«Не позволять им мешать друг другу»:

• Приложения могут использовать только ту часть оперативной памяти, которую им разрешает ОС.
• Приложения не должны иметь прямого доступа к прерываниям
• Приложения не должны иметь прямого доступа к портам ввода-вывода.

Но, очевидно, что сама ОС должна иметь доступ и к портам, и к памяти, и к прерываниям, иначе она просто не сможет работать. Отсюда вытекает:

• Отделение кода ОС от кода пользовательских приложений, предоставление коду ОС дополнительных привилегий.

«Удобство программирования»:

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

Окончательный список основных требований к ПО, которое, по предположениям разработчиков Intel, будет выполняться на их процессоре (да, ещё раз почти то же самое, но всё вместе и иногда другими словами; повторение – мать учения):

• Отделение кода ОС от кода пользовательских приложений, предоставление коду ОС дополнительных привилегий.
• Незаметное для приложений переключение процессора с одной задачи на другую.
• У каждого приложения своё защищённое адресное пространство, желательно большое. Приложения не имеют возможности обратиться за его пределы и тем самым нарушить работу ОС или других приложений.
• Поддержка ОЗУ большого объёма.
• Поддержка виртуальной памяти, так как даже самой большой ОЗУ не хватит.
• Поддержка страничной адресации (иначе память фрагментируется и сложно обеспечить многократную загрузку-выгрузку различных приложений).
• Механизм системных вызовов, позволяющий обращаться только к тем функциям, которые разрешает вызывать ОС.
• Системные механизмы (такие как прерывания, порты ввода-вывода, управление памятью) недоступны приложениям напрямую. При желании, приложение может обратиться к ним через системные вызовы.

Новая архитектура

Эмерсон, с присущей ему изобретательной памятью, приписал Гёте идею о том, 
что архитектура – это застывшая музыка. Это изречение и наша личная
 неудовлетворённость созданиями современной эпохи внушает нам порой мечту об
 архитектуре, которая, подобно музыке, была бы прямым языком страстей, не
 стесненным требованиями, предъявляемыми к жилью или общественным зданиям.

Хроники Бустоса Домека

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

Блок #1: Многозадачные ОС

Именно эта часть называется защищённым режимом (Protected Mode; наконец-то я ввёл термин, который уже столько раз использовал!). Единственное, что стоит сказать об этом блоке в этой главе – он есть. То есть, в архитектуре процессора поддержаны все пункты, перечисленные выше в разделе «Мысль #1: Многозадачная ОС» и реализованы ещё кое-какие детали. Подробностям посвящены все остальные главы.

Как и обещалось в разделе «Обратная совместимость в новом режиме», старые регистры и команды сохранены.

Блок #2: Режим полной совместимости

А это – режим реальной адресации (Real-Address Mode) или просто реальный режим (Real Mode). Он не только существует, но именно в нём начинает свою работу процессор после включения питания, для переключения в защищённый режим необходимо выполнить специальные действия. «Правильное» переключение режимов нетривиально и описывается на протяжении всего курса, начало этому положено ниже, в разделе «Переключение режимов».

Регистры

Регистры являются неотъемлемой частью процессоров Intel x86 и объединяют оба блока, не относясь к какому-либо одному, поэтому краткая сводка по ним приведена здесь.

Все регистры можно поделить на следующие группы (FPU/MMX/SSE/… - не рассматриваем! Ни здесь, ни далее):

• Общего назначения
• Флагов
• Указатель команд
• Сегментные
• Новые системные регистры, которых в 8086 не было.

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

• Регистры общего назначения, регистр флагов и указатель команд стали 32-х разрядными, к их названию спереди добавилась буква «E». То есть EAX, EBX, ECX, EDX, ESI, EDI, EBP, ESP, EFLAGS, EIP. «Старые» имена (без «E») сохранили свою актуальность, но теперь они относятся к младшим 16-ти битам соответствующего регистра.
• Сегментные регистры не изменились, зато увеличились в количестве – добавлены FS и GS.

Переключение режимов

Под капотом

Переключение режима работы процессора выполняется изменением флага PE, который находится в младшем бите регистра CR0.

Примерно так:

; Устанавливает флаг PE, переводит процессор в защищённый режим
set_PE:
        mov     eax, cr0 ; прочитать регистр CR0
        or      al, 1    ; установить бит PE,
        mov     cr0, eax ; с этого момента мы в защищенном режиме
        ret

; Сбрасывает флаг PE, переводит процессор в реальный режим
clear_PE:
        mov     eax, cr0 ; прочитать CR0
        and     al, 0FEh ; сбросить бит PE
        mov     cr0, eax ; с этого момента мы в реальном режиме
        ret

Как это обычно бывает при изменении флагов, в результате некоторым образом меняется логика работы процессора (а иначе зачем этот флаг?). Отличие от известных вам по реальному режиму флагов (Carry, Direction, Overflow, Interrupt Enable, …) только в том, что в данном случае «изменение логики работы процессора» по масштабу напоминает революцию, так как в него вовлечены практически все механизмы управления системой.

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

В результате, между фактическим переключением режима процессора (установка/сброс флага) и окончательной инициализацией соответствующих системных структур, есть некоторое количество команд, которые выполняются в «не до конца инициализированном» режиме. Но у процессора такого состояния нет! Он может находиться либо в реальном режиме, либо в защищённом, никаких «промежуточных» режимов не предусмотрено. Поэтому, с точки зрения процессора, эти команды выполняются в нормальном, полноценном режиме, хотя им и не доступны все его возможности (доступны только те, которые уже успели инициализировать).

Отсюда следует, что, если все возможности не нужны, вполне можно ограничиться «не до конца инициализированным» режимом. А, поскольку «правильная» (как советует [Intel 2004]) инициализация защищённого режима дело трудное и неблагодарное, мы будем активно использовать этот факт, инициализируя защищённый режим лишь настолько, насколько нам необходимо.

Ещё один важный момент: в реальном режиме любая программа может переключить процессор в защищённый режим, но обратное переключение может выполнить только ОС (иначе о надёжности и безопасности можно было бы забыть), при попытке изменить флаг PE пользовательской программой будет выброшено исключение. Подробнее эта тема рассмотрена в главе «Теоретическое введение в защиту».

Алгоритм в первом приближении

Как уже было сказано выше, «переключение режимов – непростой, довольно длительный, многоступенчатый процесс». Пока что мы сократим его до минимума, оставив всего две ступени. Точно так же окажутся урезанными и возможности нашей программы, но зато она будет проста, понятна и работоспособна.

Последовательность действий:

1. Запрет маскируемых и немаскируемых прерываний (Nonmaskable Interrupt, NMI; что такое NMI в общем-то не важно, но если интересно – смотрите описание в приложении).
2. Переключение процессора в защищённый режим (установка флага PE).
3. Ура, мы в защищённом режиме.
4. Переключение процессора в реальный режим (сброс флага PE).
5. Разрешение прерываний.

В данном случае, пункты (1), (2) это переключение из реального в защищённый режим, а пункты (4), (5) – из защищённого в реальный.

Запрет/разрешение прерываний

С маскируемыми прерываниями всё просто – достаточно вызвать cli/sti. Про немаскируемые в [Intel 2004] написано, что они должны блокироваться «внешней схемой» (NMI interrupts can be disabled with external circuitry). В [Зубков 1999] описан следующий вариант:

; Запрещает маскируемые и немаскируемые прерывания
disable_interrupts:
        cli              ; запретить маскируемые прерывания
        in      al, 70h  ; индексный порт CMOS
        or      al, 80h  ; установка бита 7 в нем запрещает NMI
        out     70h, al
        ret

; Разрешает маскируемые и немаскируемые прерывания
enable_interrupts:
        in      al, 70h  ; индексный порт CMOS
        and     al, 7Fh  ; сброс бита 7 отменяет блокирование NMI
        out     70h, al
        sti              ; разрешить маскируемые прерывания
        ret

Пример

Теория это, конечно, хорошо, но надо же когда-то начинать программировать. Для начала, по традиции, напишем небольшой Hello world.

Hello, world! [Protected Mode version]

; hello.asm
; Программа, выполняющая переход в защищенный режим и немедленный возврат.

        .model  tiny
        .code
        .386p           ; все наши примеры рассчитаны на 80386
        org     100h    ; это COM-программа
start:
        ; подготовить сегментные регистры
        push    cs
        pop     ds              ; DS - сегмент данных (и кода) нашей программы
        push    0B800h
        pop     es              ; ES - сегмент видеопамяти

        ; запретить прерывания
        call    disable_interrupts
        ; перейти в защищенный режим
        call    set_PE

        ; Мы в защишённом режиме!

        ; вывод на экран
        xor     di, di                   ; ES:DI - начало видеопамяти
        mov     si, offset message       ; DS:SI - выводимый текст
        mov     cx, message_l
        rep movsb                ; вывод текста
        mov     ax, 0720h        ; пробел с атрибутом 07h
        mov     cx, rest_scr     ; заполнить этим символом остаток экрана
        rep stosw
        
        ; переключиться в реальный режим
        call    clear_PE
        ; разрешить прерывания
        call    enable_interrupts

        ; подождать нажатия любой клавиши
        mov     ah, 0
        int     16h

        ; выйти из COM-программы
        ret

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Служебные функции
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

; Запрещает маскируемые и немаскируемые прерывания
disable_interrupts:
        cli              ; запретить прерывания
        in      al, 70h  ; индексный порт CMOS
        or      al, 80h  ; установка бита 7 в нем запрещает NMI
        out     70h, al
        ret

; Разрешает маскируемые и немаскируемые прерывания
enable_interrupts:
        in      al, 70h  ; индексный порт CMOS
        and     al, 7Fh  ; сброс бита 7 отменяет блокирование NMI
        out     70h, al
        sti              ; разрешить прерывания
        ret

; Устанавливает флаг PE
set_PE:
        mov     eax, cr0 ; прочитать регистр CR0
        or      al, 1    ; установить бит PE,
        mov     cr0, eax ; с этого момента мы в защищенном режиме
        ret

; Сбрасывает флаг PE
clear_PE:
        mov     eax, cr0 ; прочитать CR0
        and     al, 0FEh ; сбросить бит PE
        mov     cr0, eax ; с этого момента мы в реальном режиме
        ret

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Данные
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

; текст сообщения с атрибутом после каждого символа для прямого вывода на экран
message db      'H',7,'e',7,'l',7,'l',7,'o',7,',',7,' ',7,'w',7
        db      'o',7,'r',7,'l',7,'d',7,'!',7,
; его длина в байтах
message_l = $ - message
; длина оставшейся части экрана в словах
rest_scr = (80*25) - (message_l / 2)

        end     start

А был ли мальчик?

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

К сожалению, на текущем этапе наших знаний недостаточно для получения «положительного» подтверждения, то есть мы пока не можем сделать что-либо, недоступное в реальном режиме. Зато можно получить «отрицательное»! Для этого достаточно записать число больше 7 (почему больше 7 – в следующей главе) в любой сегментный регистр, скорее всего, это закончится повисанием компьютера или аварийной перезагрузкой. Чувствуете мощь? В реальном режиме добиться такого результата значительно сложнее! :)

Для большинства прикладных программистов основные преимуществами защищённого режима (из тех, о которых они слышали…) это значительное увеличение объёма адресуемой памяти и возможность практически отказаться от сегментации. Системные программисты видят ситуацию с несколько другой стороны. Погрузившись в защищённый режим глубже, они понимают, что сегменты размером 4 Гб и плоский (flat) режим адресации это, конечно, замечательно и очень полезно с практической точки зрения, но для ОС это далеко не главное. Куда важнее то, что памятью теперь действительно можно управлять.

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

Управление памятью в защищённом режиме разбивается на две почти независимые части:

• Сегментация (segmentation)
• Страничная адресация (paging)

Необходимой является только сегментация, и именно она рассмотрена в этой главе.

Ликбез

Перед тем, как переходить к собственно управлению памятью, надо выяснить, что такое «память», и в каком виде она доступна программисту.

Адреса

В защищённом режиме существует три различных типа адресов и три соответствующих им адресных пространства (address space):

• логическое (logical)
• линейное (linear)
• физическое (physical).

Логический адрес

Логическим адресом называется пара <сегмент>:<смещение>, на практике встречающаяся в виде <сегментный регистр>:<смещение>. Так как разрядность сегментного регистра 16, а смещения 32 бита, теоретически, таким образом можно было бы адресовать 2⁴⁸ байт (256 Тб). Но из-за некоторых особенностей сегментных регистров защищённого режима, это число уменьшается до 2⁴⁶ байт (64 Тб), что, конечно, тоже немало.

Линейный адрес

32 разряда, плоское (несегментированное) адресное пространство размером 4 Гб.

Физический адрес

Физический адрес это число, выставляемое процессором на шину адреса. Разрядность зависит от модели процессора:

• Intel386SX («облегчённая» версия Intel386 c 24-разрядной шиной адреса) – 24 бита (16 Мб)
• До Intel Pentium Pro – 32 бита (4 Гб)
• Intel Pentium Pro и старше – 36 бит (64 Гб)

Фактически, это множество адресов, к которым может обращаться процессор.

Преобразование адресов

Поскольку программист использует логические адреса, а процессор физические, необходимо преобразование. Оно происходит в два этапа: логический – линейный и линейный – физический. Первый этап выглядит так:

<линейный адрес> = <базовый адрес сегмента> + <смещение>

Если страничная адресация не используется (наш случай), второй этап получается вырожденным:

<физический адрес> = <линейный адрес>

Сегменты

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

• Расположение блока памяти в линейном адресном пространстве
• Размер блока памяти
• Те самые свойства

Базовый адрес и размер сегмента

Как уже было сказано, логический адрес <сегмент>:<смещение> преобразуется процессором в линейный адрес по формуле:

<линейный адрес> = <базовый адрес сегмента> + <смещение>

Поскольку смещение 32-х разрядное, таким образом можно адресовать область линейного адресного пространства, начинающуюся от базового адреса (base address) сегмента и имеющую размер 4 Гб. Но допустимые смещения ограничиваются вторым параметром – размером сегмента (segment size). Процессор считает, что к сегменту относится непрерывная область линейного адресного пространства, начинающаяся с базового адреса сегмента и содержащая количество байт, равное его размеру. Логические адреса со смещением, равным или превосходящим размер сегмента, выходят за пределы сегмента, обращение к таким адресам приводит к исключению #GP (General Protection Fault; подробнее об исключениях в соответствующей главе).

Взаимосвязь между всеми этими понятиями продемонстрирована на Рис.1.

Рисунок 1. Сегмент, размер сегмента, смешение байта.

Свойства сегмента

Свойства сегмента определяют его тип и правила использования (попытка использовать сегмент не по правилам обычно приводит к исключению #GP). Не вдаваясь в детали, можно выделить следующие типы сегментов:

• Сегмент кода (code segment). Допустимо исполнение, может быть разрешено чтение.
• Сегмент данных (data segment). Допустимо чтение, может быть разрешена запись.

Как видите, в списке нет сегментов стека. Вообще-то, специально для этого предназначены упомянутые выше expand down сегменты, но с точки зрения классификации они являются частным случаем сегмента данных. Кроме того, к сожалению, они обладают тремя недостатками:

• не все программисты понимают их правильно :)
• для того чтобы использовать их «правильно», нужно написать довольно много кода (подробнее об этом – в приложении). Использовать их «по простому» можно, но тогда и преимуществ не будет.
• в большинстве случаев, те же задачи проще и красивее решаются при помощи страничной адресации.

К счастью, использование expand down сегментов не обязательно, сегментом стека может быть любой доступный для чтения и записи сегмент данных.

Дескрипторы сегментов кода/данных

Логически, дескриптор (descriptor) это структура, описывающая некую системную сущность. В частности, дескриптор сегмента (segment descriptor; сегментный дескриптор) описывает сегмент. Физически дескриптор занимает восемь байт и имеет вполне определённый формат, зависящий от типа дескриптора.

Формат дескриптора сегмента кода/данных (code or data segment descriptor, это официальное название) таков:

Графически это выглядит так:

Рисунок 2. Формат дескриптора сегмента кода/данных.

И обещанный алгоритм вычисления размера сегмента (на языке «псевдо-С»):

<количество блоков> = <Segment Limit> + 1;
if (G == 1) // Если флаг гранулярнсти установлен
{
    <размер блока> = 4096;
}
else 
{
    <размер блока> = 1;
}
<размер сегмента> = <размер блока> * <количество блоков>;

В результате:

• Если Segment Limit – 0, G – 0, то размер сегмента 1 байт.
• Если Segment Limit – 0, G – 1, то размер сегмента 4096 байт.
• Если Segment Limit – FFFFFh (максимальное 20-ти битное число), G – 0, то размер сегмента 100000h байт (1 Мб).
• Если Segment Limit – FFFFFh, G – 1, то размер сегмента 100000000h байт (4 Гб).

Примеры

Дескриптор сегмента данных, размер сегмента 4 Гб, базовый адрес 0, Read/Write:

    db      0FFh        ; Segment Limit
    db      0FFh 
    db      0           ; base address
    db      0 
    db      0 
    db      10010010b   ; 1001, C/D – 0, 0, R/W – 1, 0
    db      10001111b   ; G - 1, 000, Limit - 1111
    db      0           ; base address

Дескриптор сегмента данных, размер сегмента 64 Кб, базовый адрес 0, Read/Write:

    db      0FFh        ; Segment Limit
    db      0FFh 
    db      0           ; base address
    db      0 
    db      0 
    db      10010010b   ; 1001, C/D – 0, 0, R/W – 1, 0
    db      00000000b   ; G - 0, 000, Limit - 0000
    db      0           ; base address

Дескриптор сегмента кода, размер сегмента 64 Кб, базовый адрес 12345678h, Execute/Read:

    db      0FFh        ; Segment Limit
    db      0FFh 
    db      78h         ; base address
    db      56h
    db      34h
    db      10011010b   ; 1001, C/D – 1, 0, R/W – 1, 0
    db      00000000b   ; G - 0, 000, Limit - 0000
    db      12h         ; base address

Как видите, определять дескрипторы таким образом вполне возможно и даже не слишком сложно. Но всё-таки, когда основной принцип уже понятен, удобнее использовать вот такую структуру:

segment_descriptor struct
    limit_low   dw      0    ; Младшие два байта поля Segment limit
    base_low    dw      0    ; Младшие два байта поля Base Address
    base_high0  db      0    ; Второй байт поля Base Address
    type_and_permit db  0    ; Флаги. Этот байт отвечает за то, кто и как может
                             ; использовать дескриптор. Подробнее – в следующих
                             ; главах.
    flags       db      0    ; Ещё одни флаги
    base_high1  db      0    ; Старший байт поля Base Address
segment_descriptor ends

Глобальная таблица дескрипторов

Если внимательно посмотреть на примеры дескрипторов, приведённые выше, несложно заметить, что это всего лишь объявления некоторых восьмибайтных структур. Но просто объявить в своей программе такую структуру и мысленно назвать её дескриптором совершенно недостаточно для того, чтобы начать использовать описываемый этим дескриптором сегмент. Потому что процессор читать мысли не умеет и задумку не поймёт... Для того чтобы процессор понял, дескриптор должен находиться в глобальной таблице дескрипторов (Global Descriptor Table, GDT).

Таблица дескрипторов состоит из двух частей:

• Собственно таблица – область памяти, содержащая дескрипторы.
• Специальный регистр, содержащий указатель на таблицу и объясняющий процессору, что это не просто какая-то «область памяти», а именно таблица дескрипторов.

Рассмотрим по частям.

Область памяти

Формат области памяти – массив дескрипторов, в котором нулевой дескриптор начинается со смещения 0, первый – 8, второй – 16 и т.п. Подобный массив, содержащий 3 дескриптора, мог бы выглядеть так (дескрипторы взяты из примера выше):

    ; сегмент данных, 4 Гб, базовый адрес 0, Read/Write
    segment_descriptor <0ffffh, 0, 0, 10010010b, 10001111b,  0>
    ; сегмент данных, 64 Кб, базовый адрес 0, Read/Write
    segment_descriptor <0ffffh, 0, 0, 10010010b, 0,  0> 
    ; сегмент кода, 64 Кб, базовый адрес 12345678h, Execute/Read
    segment_descriptor <0ffffh, 5678h, 34h, 10011010b, 0,  12h>

Регистр

Местоположение и размер GDT задаёт регистр GDTR (очевидно, от GDT Register; это не ключевое слово ассемблера, а условное название, которое применяется в документации для обозначения этого регистра), вот описание его формата:

Рисунок 3. Регистр GDTR

Для загрузки регистра GDTR существует специальная команда lgdt

                lgdt    pointer_to_new_gdtr

Здесь pointer_to_new_gdtr это указатель на шестибайтную структуру, повторяющую формат GDTR.

Инициализация GDT может выглядеть так:

        …
        ; Вычисляем линейный адрес начала массива дескрипторов
        mov     eax, 0
        mov     ax, ds
        shl     eax, 4                
        add     eax, offset GDT
        ; Записываем его в структуру 
        mov     dword ptr gdtr + 2, eax

        ; Загружаем GDTR. 
        ; fword ptr – указатель на шестибайтную структуру
        lgdt    fword ptr gdtr
        …

; Global Descriptor Table
GDT     label   byte
        db      …  ; Дескриптор #0
        …
        db      …  ; Дескриптор #N

gdt_len equ     $ - GDT      ; размер GDT

gdtr    dw      gdt_len – 1  ; 16-битный размер GDT – 1
        dd      ?            ; Место для 32-х битного базового адреса GDT
        …

Опять же, для удобства можно определить структуру:

table_register struct
    limit   dw	0    ; Table Limit
    base    dd	0    ; Linear Base Address
table_register ends

Селекторы и сегментные регистры

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

Защищённый режим позволяет разумной ОС более-менее контролировать этот процесс:

• Сегменты описываются дескрипторами сегментов, которые расположены в GDT. GDT формируется ОС и пользовательские приложения не имеют к ней доступа (это должна обеспечить ОС, поместив GDT в недоступную для приложений область памяти).
• ОС инициализирует GDT только такими дескрипторами сегментов, используя которые приложения никому не могут помешать (несколько упрощая…).
• Приложение указывает выбранные дескрипторы при помощи селекторов (selector), хранящихся в сегментных регистрах. Использовать какие-то другие дескрипторы сегментов, кроме предложенных ОС, оно не в состоянии.

Селекторы

Селектором называется 16-ти битная структура, используемая для ссылки на находящийся в GDT дескриптор. Формат селектора:

Рисунок 4. Формат селектора

Примеры:

        8  ; 0..01000 – первый дескриптор GDT
        16 ; 0..10000 – второй дескриптор GDT
        0  ; 0..00000 – нулевой дескриптор, см. про него ниже

Сегментные регистры

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

Начиная с 80286, сегментные регистры состоят из двух частей: видимой и скрытой (visible part, hidden part). Видимая часть это доступный для чтения/записи 16-ти разрядный регистр, скрытая часть недоступна никак, её наличие можно определить только по некоторым косвенным признакам и документации. Содержимое видимой части зависит от режима работы процессора, а вот в скрытой части регистра в обоих режимах находится некоторый аналог дескриптора, полностью описывающий сегмент. Работает это примерно так (для защищённого режима):

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

В результате поиск дескриптора, его чтение, и проверка его корректности выполняется всего один раз, что значительно ускоряет обращения к памяти. Но появляются некоторые побочные эффекты:

• (Документированный) Изменение значения дескриптора в таблице дескрипторов никак не повлияет на свойства сегмента, адресуемого сегментным регистром. Чтобы процессор «заметил» изменения, сегментный регистр надо перезаписать (можно тем же самым значением).
• (Недокументированный) При переключении режимов (в обе стороны) скрытые части сегментных регистров не сбрасываются, то есть в защищённом режиме можно пользоваться сегментными регистрами, сохранившимися из реального режима, и наоборот.

Второй «побочный эффект» нуждается в нескольких комментариях:

• Это не дыра, а особенность архитектуры, без которой переключение режимов было бы невозможно. Потому что между фактическим переключением (сброс/установка флага PE) и перезагрузкой сегментных регистров есть некоторое количество команд, которые находятся в сегменте кода старого режима. Конечно, можно было сделать исключение для CS, а остальные сбрасывать… Но, видимо, не захотели.
• В примере из первой главы в защищённом режиме были использованы сегментные регистры из реального режима. Практической ценности этот трюк не имеет, но несколько упрощает написание примеров.
• Использование в реальном режиме сегментных регистров из защищенного режима имеет огромную практическую ценность: таким образом можно получить в реальном режиме сегмент размером 4 Гб. Эта возможность довольно широко известна (в частности, она упоминается в [Гук 1999] и [Зубков 1999]), чаще всего её называют Unreal Mode (официального названия, естественно, нет). Самое интересное, что после переключения в реальный режим даже перезапись сегментного регистра не приведёт к сбросу его скрытой части и возврату к «нормальным» 64-х килобайтным сегментам. По каким-то причинам при перезаписи процессор меняет только базовый адрес сегмента, оставляя в неприкосновенности его флаги и размер.
• Этот же приём позволяет не только увеличить размер сегментов, но и наоборот, уменьшить их. Правда, после этого стандартные программы реального режима, да и сам MS-DOS, скорее всего, откажутся работать. Особенно ярко это проявляется при уменьшении размера сегмента стека.

Совместное существование

Есть несколько простых правил совместного использования селекторов и сегментных регистров, соблюдение которых убережёт вас от лишних исключений GP# и связанных с ними неприятностей.

Нулевой селектор

Селектор, указывающий на нулевой дескриптор GDT, отличается от прочих. Он имеет три особенности:

• всегда вызовет исключение при попытке загрузить его в CS или SS
• никогда не вызывает исключения при загрузке в сегментные регистры данных (DS, ES, FS, GS)
• всегда вызовет исключение при попытке использовать такой сегментный регистр

Предназначение нулевого селектора – явно «пометить» сегментные регистры, использование которых не планируется. Если этого не сделать, случайное использование таких сегментных регистров может привести к непонятным и плохо воспроизводимым ошибкам.

Регистр SS

Селектор, загруженный в SS, должен быть селектором сегмента данных, доступного для чтения/записи.

Регистр CS

Селектор, загруженный в CS, должен быть селектором сегмента кода.

Регистры DS, ES, FS, GS

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

Всё вместе

Итак, к данному моменту рассмотрены все основные понятия и артефакты, относящиеся к сегментации, осталось выяснить только две вопроса:

• Как всё это работает вместе?
• Как это инициализировать?

Получение линейного адреса

Иголка в яйце, яйцо в утке, утка в зайце..

К. Бессмертный, «Современные системы безопасности», V в. н.э.

Для начала рассмотрим «концептуально чистый» случай. Пусть на входе логический адрес в виде пары <селектор>:<смещение>, а на выходе нужно получить соответствующий линейный адрес. Алгоритм работы процессора:

1. Если хранящийся в <селекторе> индекс дескриптора выходит за границы GDT (определяются по содержимому GDTR), выбрасывается исключение.
2. По адресу начала GDT (расположен в GDTR) и индексу дескриптора определяется адрес начала дескриптора, дескриптор считывается.
3. Анализируется дескриптор и характер запроса с принципиальной точки зрения. На этом этапе отсекаются попытки использовать дескриптор способами, для которых он не предназначен, например, исполнять сегмент данных или читать/писать нечитаемый сегмент кода. Если проверка не проходится, генерируется исключение. Это уровень загрузки селектора в сегментный регистр: пока что не важно, как именно будет применяться этот регистр, есть только имя регистра и селектор.
4. Анализируется дескриптор и характер запроса с конкретной точки зрения. Если по каким-то причинам обращение невозможно (например, попытка записи в Read-Only сегмент или выход <смещения> за пределы сегмента) генерируется исключение.
5. Из дескриптора извлекается базовый адрес сегмента и складывается со <смещением>.

Нарисовать это можно так:

Рисунок 5. Алгоритм получения линейного адреса.

Более «правильный» алгоритм должен учитывать то, что селекторы «в свободном виде» встречаются только в командах загрузки адреса (lds, les, lfs, lgs, lss) и дальнего перехода, в остальных же случаях используется селектор, загруженный в сегментный регистр. А, поскольку во время загрузки сегментного регистра процессор уже проверил корректность селектора, нашёл соответствующий дескриптор и сохранил его в скрытой части сегментного регистра, то есть, фактически выполнил шаги (1), (2) и (3), алгоритм можно начинать сразу с (4).

Переключение режимов: инициализация системы управления памятью

С учётом существования дескрипторов сегментов и GDT, можно усложнить процедуру переключения режимов, немного приближаясь к эталону и, соответственно, получая больше возможностей.

Переключение из реального режима в защищённый:

1. Запретить маскируемые и немаскируемые прерывания.
2. Инициализировать GDT и загрузить её адрес в GDTR.
3. Установить флаг PE (младший бит регистра CR0).
4. Выполнить дальний переход (jmp или call) для перезагрузки регистра CS.
5. Перезагрузить все сегментные регистры.

Обратное переключение:

1. Сделать текущим сегментом кода доступный для чтения сегмент с пределом FFFFh байт.
2. Загрузить во все сегментные регистры селекторы дескрипторов доступных для записи сегментов данных с пределом FFFFh.
3. Сбросить флаг PE
4. Выполнить дальний переход (jmp или call) для перезагрузки регистра CS.
5. Перезагрузить сегментные регистры.
6. Разрешить прерывания.

Приведённые ниже примеры выполняют эти требования по частям: первый пример демонстрирует работу с сегментом данных, второй – с сегментом кода.

Вентиль A20

Как известно, процессор 8086 имел 20-ти разрядную шину адреса, поэтому мог адресовать ровно 1 Мб памяти. 80286 имел уже 24-х битную шину адреса, что, теоретически, позволяло ему обращаться к 16 Мб памяти. Но, по замыслу разработчиков, вся эта «роскошь» должна была быть доступна программисту только из защищённого режима, в реальном режиме 80286 должен был полностью повторять 8086. Однако разработчики 80286 не учли, что механизм адресации памяти реального режима (<адрес> = <16-ти битный адрес сегмента> * 16 + <16-ти битный адрес смещения>) позволяет адресовать несколько больше, чем 1 Мб. Например, так:

FFFFh * 16 + 11h = FFFF0h + 11h = 100001h

В подобной ситуации 8086 будет обращаться к младшим байтам всё того же первого мегабайта, а 80286 – к младшим байтам второго. Отличие вызвано тем, что 8086 при всём желании не может выставить на свою 20-ти разрядную адресную шину 1 в 20-ом разряде (они тоже нумеруются от 0), а 80286 не только может, но и выставляет.

Программисты всего мира с восторгом приветствовали эту ошибку: ещё бы, почти 64 Кб дополнительной оперативной памяти! И, когда разработчики процессора спохватились, было поздно – ошибка уже широко использовалась. В результате ошибка стала «особенностью» (it is not a bug, it is a feature), а для полной совместимости с 8086 в процессор был добавлен вентиль A20 (gate A20), принудительно обнуляющий 20-й бит шины адреса.

По умолчанию вентиль A20 закрыт, поэтому перед работой с адресами старше 100000h его нужно открыть. Именно для этого предназначена следующая функция:

; Открывает вентиль A20
open_A20:
        in      al, 92h 
        or      al, 2
        out     92h, al
        ret

Примеры

Сегмент данных размером 4 Гб

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

; fs4gb.asm
; Программа, устанавливающая размер сегмента, адерсуемого регистром FS, 4 Гб

        .model tiny
        .code
        .386p
        org     100h

;;;;;;;;;;;;;;;;;;;;;;;;;;;        
;
; Структуры
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;

; Сегментный дескриптор
segment_descriptor struct
    limit_low   dw      0    ; Младшие два байта поля Segment limit
    base_low    dw      0    ; Младшие два байта поля Base Address
    base_high0  db      0    ; Второй байт поля Base Address
    type_and_permit db  0    ; Флаги
    flags       db      0    ; Ещё одни флаги
    base_high1  db      0    ; Старший байт поля Base Address
segment_descriptor ends

; Регистр, описывающий GDT
table_register struct
    limit       dw      0    ; Table Limit
    base        dd      0    ; Linear Base Address
table_register ends

;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; Код
;
;;;;;;;;;;;;;;;;;;;;;;;;;;

start:
        ; Подготавливаем DS
        push    cs
        pop     ds

        ; Открываем вентиль A20
        call open_A20

        ; Инициалиируем GDT
        call initialize_gdt

        call disable_interrupts
        call set_PE

        ; загрузить новый селектор в регистр FS
        mov     ax, 8
        mov     fs, ax

        call clear_PE
        call enable_interrupts

        ret

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Данные
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

; Глобальная таблица дескрипторов
GDT     label   byte
        ; Нулевой дескриптор
        segment_descriptor <> 

        ; Дескриптор сегмента данных, базовый адрес 0, размер 4Gb, Read-Write
        segment_descriptor <0ffffh, 0, 0, 10010010b, 10001111b, 0>
        		; 10010010b - 1001, C/D - 0, 0, R/W - 1, 0
        		; 10001111b - G - 1, 000, Limit - 1111           

; Данные для загрузки в GDTR
gdtr    table_register <$ - GDT - 1, 0>

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Служебные функции
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

; Открывает вентиль A20
open_A20:
        in      al, 92h
        or      al, 2
        out     92h, al
        ret

; Инициализирует GDT
initialize_gdt:
        ; Вычисляем линейный адрес начала массива дескрипторов
        call    cs_to_eax
        add     eax, offset GDT
        ; Записываем его в структуру
        mov     dword ptr gdtr.base, eax

        ; Загружаем GDTR
        lgdt    fword ptr gdtr
        ret

; Запрещает маскируемые и немаскируемые прерывания
disable_interrupts:
        cli              ; запретить прерывания
        in      al, 70h  ; индексный порт CMOS
        or      al, 80h  ; установка бита 7 в нем запрещает NMI
        out     70h, al
        ret

; Разрешает маскируемые и немаскируемые прерывания
enable_interrupts:
        in      al, 70h  ; индексный порт CMOS
        and     al, 7Fh  ; сброс бита 7 отменяет блокирование NMI
        out     70h, al
        sti              ; разрешить прерывания
        ret

; Устанавливает флаг PE
set_PE:
        mov     eax, cr0 ; прочитать регистр CR0
        or      al, 1    ; установить бит PE,
        mov     cr0, eax ; с этого момента мы в защищенном режиме
        ret

; Сбрасывает флаг PE
clear_PE:
        mov     eax, cr0 ; прочитать CR0
        and     al, 0FEh ; сбросить бит PE
        mov     cr0, eax ; с этого момента мы в реальном режиме
        ret

; Вычисляет линейный адрес начала сгмента кода
cs_to_eax:
        mov     eax, 0
        mov     ax, cs
        shl     eax, 4
        ret

        end     start

После выполнения этой программы можно делать, например, такие вещи:

        …
        mov     eax, 10000000 ; десять мегабайт
        mov     word ptr fs:[eax], 1234h
        …

И оно будет работать! Примерно это и называется unreal-режимом.

Сегмент кода

С сегментом кода есть одна проблема: после переключения, выполнение должно продолжаться с того адреса, с которого нужно, а не с того, с которого получится. Проиллюстрировать проблему может следующий кусок псевдокода:

        …
        call disable_interrupts
        call set_PE
        ; Дальний переход. После него в CS должен оказаться
        ; селектор первого дескриптора GDT, то есть 8,
        ; а выполнение должно родолжиться с метки next_command_PM.
        jmp <8> : ????

next_command_PM:
        …
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Данные
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

; Глобальная таблица дескрипторов
GDT       label   byte
          ; Нулевой дескриптор
          segment_descriptor <> 
          ; Дескриптор сегмента кода, размер 4 Gb
          ; Адрес начала - ????
           segment_descriptor <0ffffh, ?, ?, 10010010b, 10001111b, ?>
          …

Поскольку программа загружается DOS по произвольному адресу, адрес next_command_PM не известен на этапе компиляции, и мы не можем просто прописать какие-то константы в качестве базового адреса сегмента и смещения. Есть два решения:

• Зафиксировать смещение, во время выполнения вычислять и устанавливать базовый адрес сегмента кода.
• Зафиксировать базовый адрес сегмента кода, во время выполнения вычислять и устанавливать смещение.

В примерах продемонстрированы оба варианта, первый в «практичном» примере, второй – в «пафосном».

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

[Пафосный вариант] Сегмент кода 4 Гб

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

; cs4gb.asm
; Программа, устанавливающая размер сегмента кода 4 Gb, а потом обратно 64 Kb

        .model tiny
        .code
        .386p
        org     100h

;;;;;;;;;;;;;;;;;;;;;;;;;;;        
;
; Структуры
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;

; Сегментный дескриптор
segment_descriptor struct
    limit_low   dw      0    ; Младшие два байта поля Segment limit
    base_low    dw      0    ; Младшие два байта поля Base Address
    base_high0  db      0    ; Второй байт поля Base Address
    type_and_permit db  0    ; Флаги
    flags       db      0    ; Ещё одни флаги
    base_high1  db      0    ; Старший байт поля Base Address
segment_descriptor ends

; Регистр, описывающий GDT
table_register struct
    limit       dw      0    ; Table Limit
    base        dd      0    ; Linear Base Address
table_register ends

;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; Код
;
;;;;;;;;;;;;;;;;;;;;;;;;;;

start:
        ; Подготавливаем DS
        push    cs
        pop     ds

        ; Вычисляем и устанавливаем правильное смещение в long-jmp-to-PM
        call    cs_to_eax
        add     eax, offset next_command_PM
        mov     cs:pm_offs, eax

        ; Устанавливаем правильный сегмент в long-jmp-to-RM
        mov     ax, cs
        mov     cs:rm_cs, ax

        ; Прописываем адрес начала cs в качестве базового адреса сегмента
        call    cs_to_eax
        mov     dsc64kb.base_low, ax
        shr     eax, 16
        mov     dsc64kb.base_high0, al

        ; Инициализируем GDT
        call initialize_gdt

        ; Открываем вентиль A20
        call open_A20

        call disable_interrupts
        call set_PE

        ; 32-разрядный дальний переход. Перключает содержимое cs из нормального
        ; для реального режима (адрес) в нормальное для защищённого (селектор).
        ; 32-разрядность нужна для потому, что смещение может занимать
        ; больше 16-ти разрядов.

        ; Базовый адрес целевого сегмента 0, поэтому смещение вычисляется и
        ; записывается время выполнения
        db      66h  ; префикс изменения разрядности операнда
        db      0EAh ; код команды дальнего перехода
pm_offs dd      0    ; смещение
        dw      8    ; селектор

next_command_PM:

        ; В данный момент сегмент кода - 4 Гб, базовый адрес 0

        ; 16-разрядный дальний переход. Переключает сегмент кода с 
        ; сегмента размером 4 Гб на сегмент размеров 64 Кб.
        ; Базовый адрес сегмента вычисляется во время выполнения,
        ; поэтому смещение можно прописать заранее
        db      0EAh  ; код команды дальнего перехода
        dw      $ + 4 ; смещение
        dw      16    ; селектор

        ; В данный момент сегмент кода - 64 Кб, базовый адрес равен
        ; адресу сегмента кода до переключения в защищённый режим

        call clear_PE

        ; Мы в реальном режиме, осталось разобраться с
        ; значением регистра cs

        ; 16- разрядный дальний переход. Перключает содержимое cs из нормального
        ; для защищённог режима (селектор) в нормальное для реальног (адрес).
        ; Адрес сегмента вычисляется и прописывается во время выполнения.
        db      0EAh   ; код команды дальнего перехода
        dw      $ + 4  ; смещение
rm_cs   dw      0      ; сегмент

        call enable_interrupts

        ret

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Данные
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

; Глобальная таблица дескрипторов
GDT     label   byte
        ; Нулевой дескриптор
        segment_descriptor <> 
        ; Дескриптор сегмента кода, размер 4 Gb
        segment_descriptor <0ffffh, 0, 0, 10011010b, 10001111b, 0>
        		; 10011010b - 1001, C/D - 1, 0, R/W - 1, 0
        		; 10001111b - G - 1, 000, Limit - 1111
           
        ; Дескриптор сегмента кода, размер 64 Kb
dsc64kb segment_descriptor <0ffffh, 0, 0, 10011010b, 0, 0>
        		; 10011010b - 1001, C/D - 1, 0, R/W - 1, 0
        		; 0         - G - 0, 000, Limit - 0
        		
; Данные для загрузки в GDTR
gdtr    table_register <$ - GDT - 1, 0>

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Служебные функции
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

        ...     ; Служебные функции – те же, что и ранее

        end     start 

[Практичный вариант] Сегмент кода 64 Кб

4 Гб это, конечно, здорово, но, поскольку на протяжении курса мы не будем писать таких больших программ, нам нигде не потребуется сегмент кода размером более 64 Кб. Поэтому переключение сегмента кода можно упростить:

; cs64kb.asm
; Программа, переключающаяся в защищённый режим 
; и устанавливающая сегмента кода такой же ка был в реальном

        .model tiny
        .code
        .386p
        org     100h

;;;;;;;;;;;;;;;;;;;;;;;;;;;        
;
; Структуры
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;

; Сегментный дескриптор
segment_descriptor struct
    limit_low   dw      0    ; Младшие два байта поля Segment limit
    base_low    dw      0    ; Младшие два байта поля Base Address
    base_high0  db      0    ; Второй байт поля Base Address
    type_and_permit db  0    ; Флаги
    flags       db      0    ; Ещё одни флаги
    base_high1  db      0    ; Старший байт поля Base Address
segment_descriptor ends

; Регистр, описывающий GDT
table_register struct
    limit       dw      0    ; Table Limit
    base        dd      0    ; Linear Base Address
table_register ends

;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; Код
;
;;;;;;;;;;;;;;;;;;;;;;;;;;

start:
        ; Подготавливаем DS
        push    cs
        pop     ds

        ; Устанавливаем правильный сегмент в long-jmp-to-RM
        mov     ax, cs
        mov     cs:rm_cs, ax

        ; Прописываем адрес начала cs в качестве базового адреса сегментов
        call    cs_to_eax
        mov     dsc64kb.base_low, ax
        shr     eax, 16
        mov     dsc64kb.base_high0, al

        ; Инициализируем GDT
        call initialize_gdt

        ; Открываем вентиль A20
        call open_A20

        call disable_interrupts
        call set_PE

        ; 16-разрядный дальний переход. Перключает содержимое cs из нормального
        ; для реального режима (адрес) в нормальное для защищённого (селектор).
        ; Базовый адрес целевого сегмента совпадает с cs,
        ; поэтому смещение можно прописать сразу
        db      0EAh   ; код команды дальнего перехода
        dw      $ + 4  ; смещение
        dw      8      ; селектор

        ; В данный момент сегмент кода - 64 Кб, базовый адрес равен
        ; адресу сегмента кода до переключения в защищённый режим,
        ; потому можно без проблем переключаться обратно

        call clear_PE

        ; Мы в реальном режиме, осталось разобраться с
        ; значением регистра cs

        ; 16-разрядный дальний переход. Перключает содержимое cs из нормального
        ; для защищённог режима (селектор) в нормальное для реальног (адрес).
        ; Адрес сегмента вычисляется и прописывается во время выполнения.
        db      0EAh   ; код команды дальнего перехода
        dw      $ + 4  ; смещение
rm_cs   dw      0      ; сегмент

        call enable_interrupts

        ret

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Данные
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

; Глобальная таблица дескрипторов
GDT     label   byte
        ; Нулевой дескриптор
        segment_descriptor <> 
        ; Дескриптор сегмента кода, размер 64 Kb
dsc64kb segment_descriptor <0ffffh, 0, 0, 10011010b, 0, 0>
        		; 10011010b - 1001, C/D - 1, 0, R/W - 1, 0
        		; 0         - G - 0, 000, Limit - 0
       		
; Данные для загрузки в GDTR
gdtr    table_register <$ - GDT - 1, 0>

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Служебные функции
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

        ...     ; Служебные функции – те же, что и ранее

        end     start 

Задания

• Попробуйте задать некорректный размер GDT (не равный 8n-1). Проверьте приведенные данные о нулевом селекторе и дескрипторе. Игнорируется ли содержимое нулевого дескриптора?
• Проверьте необходимость открытия вентиля A20
• Проверьте необходимость последнего jmp-а при переключении в реальный режим в программе cs4gb.asm (тот, который меняет селектор на адрес).
• Попытайтесь обратиться за пределы сегмента. Попытайтесь писать в read-only сегмент данных, в сегмент кода, читать execute-only сегмент кода. Попробуйте исполнять сегмент данных. То есть передать управление сегменту данных командой jmp.
• Проверьте работоспособность программы fs4gb.asm. Проверьте, нужна ли она вообще.
• Создайте два перекрывающихся сегмента с разными базовыми адресами. Проверьте совпадение данных в общей области.
• Проверьте, что изменение дескриптора в GDT без перезаписи сегментного регистра не приводит к изменению параметров сегмента. Проверьте, что перезапись ставит всё на свои места.
• Посмотрите, что произойдёт при переполнении линейного адреса. То есть, что будет, если писать/читать по такому логическому адресу, что сумма базового адреса сегмента и смещения превосходит 2³². При помощи unreal-mode проверьте это же для реального режима. Лично у меня получились разные результаты, и я до сих пор не знаю, почему :)
• Посмотрите, что произойдёт при попытке обратиться по несуществующему физическому адресу (за пределы ОЗУ; это возможно только если у вас меньше 4 Гб ОЗУ). При помощи unreal-mode проверьте это же для реального режима.

Any time at all, any time at all, any time at all,
All you've gotta do is call and I'll be there.

John Lennon

Конечно же, вы знаете, что такое прерывание (interrupt), слышали о таблице векторов прерываний (interrupt vector table) и вообще довольно неплохо представляете, как прерывания обрабатываются в реальном режиме :)

Но, тем не менее, пару общих слов сказать нужно, так как тема важная и непростая.

Общие слова

Программные прерывания (software generated interrupts) вызываются инструкциями int x, где x – любое число от 0 до 255 (int 3 несколько отличается от прочих, подробнее эта тема освещена в следующей главе). Это, в общем-то, почти и не прерывания вовсе, так как ничего непонятного в них нет :) Фактически это просьба к процессору вызвать определённую подпрограмму, которая должна быть специальным образом зарегистрирована в системе, она называется обработчик прерывания (interrupt handler)

Естественно, защищённый режим, так же как и реальный, предоставляет возможность обработки прерываний, не менее естественно, что, по сравнению с реальным режимом, в нём многое изменилось. Но, что приятно, сохранились основные положения:

• Прерывания нумеруются, диапазон номеров от 0 до 255.
• Обработчик прерывания это некоторая подпрограмма.
• Где-то в памяти находится таблица, устанавливающая соотношение между номерами прерываний и их обработчиками.
• В таблице в некотором формате хранится адрес обработчика прерывания.

Таблица дескрипторов прерываний

Аналог таблицы векторов прерываний, существующий в защищённом режиме, называется таблицей дескрипторов прерываний (Interrupt Descriptor Table, IDT).

По формату и способу инициализации IDT практически идентична GDT. Основные отличия:

• Содержимое. В IDT находятся дескрипторы другого типа (рассмотрены ниже).
• Регистр, определяющий размер и положение таблицы называется IDTR, команда для его загрузки – lidt.
• В отличие от GDT, нулевой дескриптор IDT это обычный, полноценный дескриптор, к которому вполне возможно обращение.
• Размер IDT не должен превышать 256 дескрипторов.

Таким образом, слегка модифицируя код из предыдущей главы, получаем пример инициализации IDT:

        …
        ; Вычисляем линейный адрес начала массива дескрипторов
        mov     eax, 0
        mov     ax, ds
        shl     eax, 4                
        add     eax, offset IDT
        ; Записываем его в структуру 
        mov     dword ptr offset idtr + 2, eax

        ; Загружаем IDTR. fword ptr – указатель на шестибайтную структуру
        lidt    fword ptr idtr
        …

; Interrupt Descriptor Table
IDT     label   byte
        db      …  ; Дескриптор #0
        …
        db      …  ; Дескриптор #N

idt_len equ     $ - IDT      ; размер IDT

idtr    dw      idt_len – 1  ; 16-битный размер IDT – 1
        dd      ?            ; Место для 32-х битного базового адреса IDT

Несложно заметить, что та же самая структура table_register подходит и для загрузки в IDTR.

Дескриптор шлюза ловушки

Дескриптор – не шлюза, а порядочная девушка!

Надпись маркером в лифте.

Как уже говорилось в предыдущей главе, дескриптор это структура, описывающая некую системную сущность. Очередным типом дескрипторов, с которым вам придется познакомиться, будет дескриптор шлюза ловушки (trap gate descriptor; в [Гук 1999] слово «gate» переводится как «вентиль», это стандартный перевод для схемотехники, программисты обычно говорят «шлюз»), описывающий обработчик прерывания. Он имеет следующий формат:

То же самое на картинке:

Рисунок 1. Формат дескриптора шлюза ловушки.

Основная информация, которую несёт в себе дескриптор шлюза ловушки, это:

• Указание на то, что данный дескриптор действительно является дескриптором шлюза ловушки.
• Адрес обработчика прерывания в формате <селектор>:<смещение>.

Поскольку формат практически прозрачен, остаётся только привести пример:

    db      04h         ; Offset – два младших байта
    db      03h 
    db      8           ; Segment selector 
    db      0 
    db      0           ; 0
    db      10001111b   ; 10001111 – магическое число..
    db      02h         ; Offset – два старших байта
    db      01h

Это дескриптор шлюза ловушки, селектор сегмента указывает на первый дескриптор GDT, смещение – 01020304h. В виде структуры дескриптор шлюза выглядит так:

gate_descriptor struct
    offset_low  dw      0    ; Два младших байта поля Offset
    selector    dw      0    ; Поле Segment Selector
    zero        db      0
    type_and_permit db  0    ; Флаги. Этот байт отвечает за то, кто и как может
                             ; использовать дескриптор. Подробнее – в следующих
                             ; главах.
    offset_high dw      0    ; Старшие байты поля Offset
gate_descriptor ends

[Лирическое отступление] Классификация дескрипторов

Сегмента-кода-или-данных/системный

Первый признак классификации дескрипторов – значение 4-го бита пятого байта дескриптора. Полное название этого бита – флаг «descriptor type», краткое – флаг «S» (довольно странное сокращение, но везде применяется именно оно). В соответствии с этим признаком, дескрипторы делятся на два класса:

• Если флаг установлен, то это дескриптор сегмента кода/данных. Они были более-менее рассмотрены в предыдущей главе
• Если флаг сброшен – системный дескриптор (system descriptor). В том числе, к этому классу относится и дескриптор шлюза ловушки.

Принципиальное отличие системных дескрипторов от дескрипторов сегмента кода/данных в том, что селекторы первых не могут быть загружены в сегментные регистры и участвовать в формировании логического адреса <сегмент>:<смещение>. Даже если системный дескриптор описывает сегмент (вы познакомитесь с таким дескриптором в главе «Введение в многозадачность»), для доступа к данным придётся использовать сегмент кода/данных (с соответствующим дескриптором и селектором), проецирующийся на нужную область памяти.

Системные дескрипторы имеют различный формат и единственное общее отличие их формата от формата дескрипторов сегмента кода/данных – младшие четыре бита пятого байта. Для обоих видов дескрипторов это поле называется «Type» и уточняет тип дескриптора, но при этом используются разные подходы:

• Для дескрипторов сегмента кода/данных поле состоит из четырёх однобитовых флагов (два из них – флаги C/D и W/R – были рассмотрены в предыдущей главе).
• Для системных дескрипторов это просто номер, задающий тип дескриптора. Как уже было сказано, для дескриптора шлюза ловушки значение должно быть равно 1111b.

Сегмента/шлюза

Второй признак классификации – характер сущности, описываемой дескриптором. Это может быть:

• Сегмент. О том, что такое сегмент было подробно написано в предыдущей главе, соответствующий дескриптор называется дескриптором сегмента. К ним относятся дескрипторы сегмента кода/данных и несколько типов системных дескрипторов.
• Шлюз. В данном случае это слово следует трактовать как «точка входа», то есть (несколько упрощая) адрес начала некоторой подпрограммы. Дескриптор называется дескриптором шлюза (gate descriptor), к ним относятся остальные системные дескрипторы, в частности дескриптор шлюза ловушки.

Дескрипторы, описывающие похожие сущности, имеют близкие форматы. Так, любой дескриптор сегмента по формату похож на дескриптор сегмента кода/данных, а любой дескриптор шлюза – на дескриптор шлюза ловушки.

Всё вместе

Объединим всё, уже известное про прерывания и добавим недостающие детали.

Вызов обработчика прерывания

Целью всего механизма обработки прерываний является своевременный вызов обработчика. В нашем случае (остальные случаи – в остальных главах, описывать всё сразу совершенно ни к чему) вызов происходит примерно так:

1. По номеру прерывания в IDT отыскивается нужный дескриптор, из него извлекается селектор сегмента и смещение начала обработчика.
2. Проверяется корректность селектора (указывает на дескриптор в пределах GDT, это дескриптор сегмента кода, и т.п.) и смещения (попадает в сегмент).
3. В стеке сохраняются регистр EFLAGS и дальний указатель на команду, следующую за int x, то есть регистр CS и значение регистра EIP, увеличенное на размер команды int x. На каждый из регистров в стеке выделяется по 4 байта, рядом с CS находятся два «лишних» байта.
4. CS и EIP загружаются новыми значениями.
5. Начинается выполнение обработчика. Дескриптор шлюза ловушки не предназначен для обработки внешних (аппаратных) прерываний, поэтому аппаратные прерывания не маскируются автоматически при входе в обработчик.
6. После своего завершения обработчик возвращает управление командой iretd. В отличии от iret, она предназначена для случая, когда в стеке сохранены 32-х разрядные EIP и EFLAGS, а не 16-ти разрядные IP и FLAGS (подробнее про 16-ти и 32-х разрядность см. в приложении).
7. Возврат к исходной программе. В регистры EFLAGS, CS и EIP загружается значение из стека, при этом происходит обращение к GDT и проверка корректности устанавливаемого селектора и смещения.

Упрощённая версия алгоритма в виде комикса:

Рисунок 2. Немного упрощенный алгоритм вызова обработчика прерывания.

Ключевые признаки, отделяющие «наш» случай от «не нашего»:

• Происходит программное прерывание.
• Соответствующая ячейка IDT содержит именно дескриптор шлюза ловушки.
• Несколько условий, связанных с защитой. Если дескрипторы в GDT и IDT такие, как рекомендовано (то есть, в описанные части дескрипторов записано что-то разумное, для «пока неважных» частей взяты значения, приведённые в таблицах), все условия выполняются. Подробнее эта тема рассмотрена в главах, посвящённых защите.

Переключение режимов: инициализация IDT

Добавим к алгоритмам переключения ещё несколько шагов. Из реального режима в защищённый:

1. Запретить маскируемые и немаскируемые прерывания.
2. Сохранить значение IDTR для реального режима.
3. Инициализировать IDT и загрузить её адрес в IDTR.
4. Инициализировать GDT и загрузить её адрес в GDTR.
5. Установить флаг PE (младший бит регистра CR0).
6. Выполнить дальний переход (jmp или call). Это нужно для перезагрузки регистра CS.
7. Перезагрузить все сегментные регистры.

Обратное переключение:

1. Сделать текущим сегментом кода какой-либо доступный для чтения сегмент с пределом FFFFh байт.
2. Загрузить во все сегментные регистры селекторы дескрипторов доступных для записи сегментов данных с пределом FFFFh.
3. Сбросить флаг PE
4. Выполнить дальний переход (jmp или call).
5. Перезагрузить сегментные регистры.
6. Восстановить в IDTR значение для реального режима.
7. Разрешить прерывания.

Сохранение значения IDTR

Для этого предназначена команда sidt.

         sidt	pointer_to_idtr

Пример использования:

         …
         ; Сохраняем IDTR
         sidt    fword ptr old_idtr
         …

old_idtr table_register <>

Пример

Обработчик int 0

Практически минимальная программа, устанавливающая обработчик нулевого прерывания и вызывающая его командой int 0.

; int0.asm
; Программа, устанавливающая и вызывающая обработчик нулевого прерывания

        .model tiny
        .code
        .386p
        org     100h

;;;;;;;;;;;;;;;;;;;;;;;;;;;        
;
; Структуры
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;

; Сегментный дескриптор
segment_descriptor struct
    limit_low   dw      0    ; Младшие два байта поля Segment limit
    base_low    dw      0    ; Младшие два байта поля Base Address
    base_high0  db      0    ; Второй байт поля Base Address
    type_and_permit db  0    ; Флаги
    flags       db      0    ; Ещё одни флаги
    base_high1  db      0    ; Старший байт поля Base Address
segment_descriptor ends

; Дескриптор шлюза
gate_descriptor struct
    offset_low  dw      0    ; Два младших байта поля Offset
    selector    dw      0    ; Поле Segment Selector
    zero        db      0
    type_and_permit db  0    ; Флаги
    offset_high dw      0    ; Старшие байты поля Offset
gate_descriptor ends

; Регистр, описывающий таблицу
table_register struct
    limit       dw      0    ; Table Limit
    base        dd      0    ; Linear Base Address
table_register ends

;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; Код
;
;;;;;;;;;;;;;;;;;;;;;;;;;;

start:
        ; Подготавливаем DS
        push    cs
        pop     ds

        ; В es - начало видеобуфера. Можно было сделать то же
        ; самое средствами защищённого режима, но так проще
        push    0b800h
        pop     es

        ; Устанавливаем правильный сегмент в long-jmp-to-RM
        mov     ax, cs
        mov     cs:rm_cs, ax

        ; Прописываем адрес начала cs в качестве базового адреса сегмента
        call    cs_to_eax
        mov     dsc64kb.base_low, ax
        shr     eax, 16
        mov     dsc64kb.base_high0, al

        ; Сохраняем IDTR реального режима
        sidt    fword ptr old_idtr

        ; Инициализируем IDT
        call initialize_idt

        ; Инициализируем GDT
        call initialize_gdt

        ; Открываем вентиль A20
        call open_A20

        call disable_interrupts
        call set_PE

        ; 16-разрядный дальний переход. Перключает содержимое cs из нормального
        ; для реального режима (адрес) в нормальное для защищённого (селектор).
        ; Базовый адрес целевого сегмента совпадает с cs,
        ; поэтому смещение можно прописать сразу
        db      0EAh   ; код команды дальнего перехода
        dw      $ + 4  ; смещение
        dw      8      ; селектор

        ; В данный момент сегмент кода - 64 Кб, базовый адрес равен
        ; адресу сегмента кода до переключения в защищённый режим.

        int 0 ; вызываем прерывание

        call clear_PE

        ; Мы в реальном режиме, осталось разобраться с
        ; значением регистра cs

        ; 16-разрядный дальний переход. Перключает содержимое cs из нормального
        ; для защищённог режима (селектор) в нормальное для реальног (адрес).
        ; Адрес сегмента вычисляется и прописывается во время выполнения.
        db      0EAh   ; код команды дальнего перехода
        dw      $ + 4  ; смещение
rm_cs   dw      0      ; сегмент

        ; восстанавливаем IDTR реального режима
        lidt    fword ptr old_idtr

        ; разрешаем прерывания
        call enable_interrupts

        ret

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Обработчик прерывания
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

; Обработчик прерывания int 0, меняет символы и их атрибуты по всему экрану
; Предпологает, что база es - начало видеобуфера
int0_handler:

        ; В данный момент, в стеке:
        ; esp + 0 - EIP
        ; esp + 4 – CS и два байта мусора
        ; esp + 8 - EFLAGS

        push   eax
        push   ecx

        mov    eax, 0         ; Текущий символ
        mov    ecx, 80 * 25   ; Колическтво сиволов на экране

screen_loop:
        inc    byte ptr es:[eax]          ; Меняем символ
        inc    eax
        inc    byte ptr es:[eax]          ; Меняем атрибут
        inc    eax
        loop   screen_loop

        pop    ecx
        pop    eax
        iretd                 ; 32-х разрядный возврат из прерывания

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Данные
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

; Глобальная таблица дескрипторов
GDT     label byte
        ; Нулевой дескриптор
        segment_descriptor <>
        ; Дескриптор сегмента кода, размер 64 Kb
dsc64kb segment_descriptor <0ffffh, 0, 0, 10011010b, 0, 0>
        		; 10011010b - 1001, C/D - 1, 0, R/W - 1, 0
        		; 0         - G - 0, 000, Limit - 0
       		
; Данные для загрузки в GDTR
gdtr    table_register <$ - GDT - 1, 0>


; Таблица дескрипторов прерываний
IDT     label byte
        ; Дескриптор шлюза ловушки. 
        ; Обработчик прерывания находится в сегменте, соответствующем первому
        ; дескриптору GDT. Поскольку базовый адрес сегмента такой же, как
        ; в реальном режиме, смещение обработчика тоже совпадает.
        gate_descriptor <int0_handler, 8, 0, 8Fh, 0>

; Данные для загрузки в IDTR
idtr    table_register <$ - IDT - 1, 0>

; Место для IDTR реального режима
old_idtr table_register <>  

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Служебные функции
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

; Открывает вентиль A20
open_A20:
        in      al, 92h
        or      al, 2
        out     92h, al
        ret

; Инициализирует IDT
initialize_idt:
        ; Вычисляем линейный адрес начала массива дескрипторов
        call    cs_to_eax
        add     eax, offset IDT
        ; Записываем его в структуру
        mov     idtr.base, eax

        ; Загружаем IDTR
        lidt    fword ptr idtr
        ret

; Инициализирует GDT
initialize_gdt:
        ; Вычисляем линейный адрес начала массива дескрипторов
        call    cs_to_eax
        add     eax, offset GDT
        ; Записываем его в структуру
        mov     gdtr.base, eax

        ; Загружаем GDTR
        lgdt    fword ptr gdtr
        ret

; Запрещает маскируемые и немаскируемые прерывания
disable_interrupts:
        cli              ; запретить прерывания
        in      al, 70h  ; индексный порт CMOS
        or      al, 80h  ; установка бита 7 в нем запрещает NMI
        out     70h, al
        ret

; Разрешает маскируемые и немаскируемые прерывания
enable_interrupts:
        in      al, 70h  ; индексный порт CMOS
        and     al, 7Fh  ; сброс бита 7 отменяет блокирование NMI
        out     70h, al
        sti              ; разрешить прерывания
        ret

; Устанавливает флаг PE
set_PE:
        mov     eax, cr0 ; прочитать регистр CR0
        or      al, 1    ; установить бит PE,
        mov     cr0, eax ; с этого момента мы в защищенном режиме
        ret

; Сбрасывает флаг PE
clear_PE:
        mov     eax, cr0 ; прочитать CR0
        and     al, 0FEh ; сбросить бит PE
        mov     cr0, eax ; с этого момента мы в реальном режиме
        ret

; Вычисляет линейный адрес начала сгмента кода
cs_to_eax:
        mov     eax, 0
        mov     ax, cs
        shl     eax, 4
        ret

        end     start

Задания

• Перепишите программу так, чтобы вызывалось 29-е прерывание, но она продолжала бы работать.
• Вызовите прерывание, номер которого выходит за границы IDT
• Объявите IDT, содержащую более 256 дескрипторов. Есть ли в этом смысл?
• Запишите в IDT нулевой дескриптор, дескриптор сегмента данных, сегмента кода, вызовите соответствующие прерывания.
• Запишите в IDT дескриптор шлюза ловушки такой, что содержащийся в нём селектор: нулевой, ссылается за пределы GDT, ссылается на сегмент данных. Вызовите прерывание.
• Запишите в IDT дескриптор шлюза ловушки такой, что: содержащееся в нём смещение выходит за пределы сегмента, не соответствует началу обработчика. Вызовите прерывание.
• Замените в обработчике прерывания iretd на iret.
• Посмотрите, что находится в IDTR в реальном режиме. Запишите туда что-нибудь другое.
• Реализуйте в обработчике аналог 9-й функции стандартного DOS-прерывания int 21h (вывод на экран строки, завершённой символом «$»). Для простоты не заботьтесь об управляющих символах (табуляции, перевода строки и т.п.).
• В обработчике выведите на экран значения EIP, CS и EFLAGS из стека. Проверьте, что это именно они.

Мне и больно, мне и сладко, что он не такой как все

Сергей Чиграков

Приложение выполнило недопустимую операцию и будет закрыто

Microsoft Windows

Человеку свойственно ошибаться

Истина

Очередная особенность защищённого режима – важность исключений. В отличие от реального режима, в котором исключения используются довольно слабо, для ОС защищённого режима они важны так же, как и остальные виды прерываний, то есть исключительно важны. Уважающая себя ОС защищённого режима просто вынуждена корректно обрабатывать все возможные исключения. Причины три:

• Необработанные исключения приводят к краху системы, а этого (уважающая себя) ОС позволить не может (в реальном режиме обрушить систему настолько просто, что обработка исключений никак не покрывает потребностей в надёжности).
• Некоторые возможности, необходимые (уважающей себя) ОС, доступны только через механизм исключений (из описываемых в курсе – виртуальная память).
• Некоторые возможности, необходимые пользовательскому ПО, доступны только через механизм исключений (отладка, в курсе не описана). Поскольку разрешать пользовательскому ПО самостоятельно обрабатывать исключения (уважающая себя) ОС не может, разумно будет обрабатывать соответствующие исключения и предоставлять пользователям аналогичный сервис.

Глава начинается с абстрактных (не относящихся к конкретному процессору) размышлений на тему «Исключения: что, зачем и почему?», продолжается описанием реализации обработки исключений на базе Intel x86 и завершается примером программы, обрабатывающей исключение #GP.

Что, зачем и почему

Знаете, почему стиральная машина лучше персонального компьютера? Вот почему:

• Стиральная машина умеет стирать :)
• Большинство стиральных машин никогда не выполняют «недопустимую операцию».

И, если первая проблема решается разработкой соответствующих периферийных устройств, не представляет интереса и не рассматривается в курсе, то вторая напрямую связана с темой главы, зато, видимо, практически не решаема.

Завидная устойчивость стиральных машин к программным сбоям, связана не с тем, что они «проще» (это может быть не так, особенно если сравнивать с PC XT), а с тем, что они всегда работают по одному из нескольких предопределённых сценариев, и никогда не исполняют «пользовательское программное обеспечение». Примерно то же можно сказать и про холодильники, пылесосы, телефоны, автомобили и т.п.

В отличие от всей перечисленной техники, компьютеры задуманы относительно универсальными.

На компьютере исполняются самые разные программы, написанные ещё более разными людьми, имевшими совершенно различные цели (иногда – деструктивные) и квалификацию (часто – недостаточную). И ни кому из них процессор ни в коем случае не должен доверять слишком сильно. Что характерно, защищённый режим всё только усложняет: в случае работы под управлением многозадачной ОС, процессор должен доверять пользовательским программам ещё меньше, так как некорректное поведение одной программы ставит под угрозу не только её, но и все остальные запущенные программы.

Ошибки

Поскольку объекты «пользователь» и «процессор» обладают очень разными характеристиками, понятие «ошибка» для пользователя и для процессора – очень разные вещи. Поясняю на примере:

• Если написанный вами калькулятор на ввод «2+2» даёт ответ «5» вместо запланированного «4», то это ошибка с точки зрения пользователя. С точки зрения процессора всё нормально: программа состоит из корректных команд, каждую команду процессор в состоянии выполнить. А то, что эти команды в совокупности образуют неверный алгоритм, его абсолютно не волнует. Он же не знает, какой алгоритм верный.
• Если написанный вами калькулятор пытается вывести результат в файл «ответ.txt», а ваша любимая ОС не поддерживает русские буквы в именах файлов, и файл открыть не удаётся, то это ошибка с точки зрения ОС. Процессор ничего не знает ни про файлы, ни про буквы и, естественно, не считает это ошибкой.
• А вот если тот же самый калькулятор, работающий в защищённом режиме, попытается напрямую модифицировать собственный сегмент кода (писать такие калькуляторы гораздо интереснее), процессор окажется в сложной ситуации: программа пытается изменить read-only сегмент и, с одной стороны, этого делать нельзя, с другой стороны, что-то делать всё-таки надо. Это и будет ошибкой с точки зрения процессора.
• Но и это ещё не всё. Если такое поведение калькулятора и соответствующая реакция процессора предполагались пользователем заранее, то, с точки зрения пользователя, это не ошибка, всё идёт по плану.

Отсюда можно сделать два вывода:

• Для процессора «ошибка» это состояние, когда он по какой-либо причине не может выполнить текущую команду.
• Поскольку все остальные ситуации процессор ошибками не считает, их обработка остаётся на совести ОС и прикладного ПО. Процессор тут помочь не может, не зависимо от своей архитектуры: у него нет механизма, позволяющего отличить «правильную» программу от «неправильной».

Случилось страшное. Ну, и?..

Мама, мама, что мы будем делать,
Когда настанут зимние холода.

Из фильма «Кин-дза-дза»

Поскольку ошибки неизбежны, на них надо как-то разумно реагировать. Рассмотрим варианты (для определённости, предположим, что команда mov пытается писать в read-only сегмент).

[Лирическое отступление] Плохие варианты

а) Физическое самоуничтожение. В соответствии с кодексом чести самурая, процессор, не способный выполнить поставленную перед ним задачу, делает себе харакири (сеппуку, если получится). Без комментариев.

б) Автоматически перезагрузиться или, наоборот, зависнуть до аппаратного сброса. В некоторых ситуациях, такая реакция допустима для (почти?) любых процессоров. А какой-нибудь микроконтроллер вполне может «обрабатывать» так вообще все ошибки. Процессор компьютера общего назначения не должен использовать подобный подход слишком часто, так как пользователи хотят работать/играть/…, но уж точно не любоваться каждые пять минут на загрузку любимой ОС.

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

г) Проигнорировать команду. Представьте себе, что в вашей программе некоторые ассемблерные команды иногда (не стабильно) просто не исполняются. И никому об этом не сообщают… И все последующие команды полагают, что всё в порядке… Сомневаюсь, что такой процессор завоюет популярность. В некоторых ситуациях такая стратегия обработки ошибок работает, но, видимо, процессоры – не тот случай.

д) Проигнорировать команду и выставить флаг ошибки. Несколько лучше… Но теперь после каждого mov придётся проверять, успешно ли он выполнился. Печально? Это ещё цветочки, ведь ошибка может быть не только в mov. Например, push и pop могут выйти за границу сегмента, call и jmp могут попытаться передать управление по «неправильному» адресу, и т.п. Фактически, придётся проверять все команды, кроме тех, которые имеют дело только с регистрами общего назначения (с прочими регистрами тоже не всё просто). В принципе, с учётом того, что сейчас большая часть кода генерируется компиляторами, это допустимый вариант. Но у него слишком много недостатков:

• При последовательном применении значительно увеличится размер кода, так как почти после каждой команды будет следовать проверка.
• По тем же причинам и примерно во столько же раз уменьшится скорость выполнения.
• Поскольку такие ошибки происходят относительно редко, большую часть времени проверки будут просто лишними.
• Ну, допустим, вы обнаружили, что предыдущая команда не выполнилась, и что дальше? В случае таких ошибок очень сложно вести себя разумно, а, скорее всего, уже всё, можно завершаться.
• Есть ещё и «меньшая часть кода», которую приходится писать руками.

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

Хороший вариант

Help me if you can, I'm feeling down
And I do appreciate you being round.
Help me, get my feet back on the ground,
Won't you please, please help me. 

John Lennon

Поскольку, как видите, сам по себе процессор практически не способен адекватно реагировать на ошибки, остаётся последний вариант:

ё) Обратиться за помощью к программисту. Примерно так:

• Вызывается некоторая зарегистрированная в системе подпрограмма.
• Этой подпрограмме как-то сообщается причина ошибки и, возможно, адрес ошибочной команды.
• Действия, предпринимаемые подпрограммой, оставляются на усмотрение программиста (обычно, программиста, писавшего ОС). Например, она может попытаться исправить ошибку и вернуть управление на начало той же команды, может передать управление куда-либо ещё, может завершить процесс.

Это называется обработкой исключений (exception handling), и именно этот прогрессивный подход используется в процессорах Intel x86, начиная с 8086. Поэтому особого выбора у разработчиков Intel 386 не было: обратная совместимость это святое. Но, конечно, защищённый режим всё расширил и углубил.

Смотрим шире

Понятно, что подобный алгоритм можно использовать в любой ситуации, когда необходимо прервать текущий поток выполнения и вызвать некоторый системный код. Можно выделить несколько частных случаев:

• Программист сам этого хотел и выказал своё желание явно. Это программное прерывание, вызывается обработчик прерывания (они были рассмотрены ранее, в главе «Программные прерывания»).
• Судя по коду, программист этого хотел, возможно, осознанно, возможно нет («опечаточка по Фрейду»). Это ошибка, вызывается обработчик исключения.
• Программист, писавший исполняющуюся программу, ничего подобного не хотел, зато этого хочет другой программист, установивший соответствующее событие отладки (тема отладки в курсе не рассматривается, просто поверьте, что такое бывает). Отладочные события Intel относит к исключениям.
• Этого хотел разработчик аппаратуры. Это аппаратное (hardware generated) или внешнее (external) прерывание (interrupt), они рассмотрены в следующей главе.

Всё это вместе, обычно, называется прерываниями (interrupts) и, соответственно, обработкой прерываний (interrupt handling). При этом аппаратные прерывания относят к отдельному классу (они будут обсуждаться в следующей главе), а всё остальное (обычно) называют исключениями.

Основы обработки исключений

К «основам» я отнёс то, что объединяет все типы исключений: базовую терминологию и общие сведения о регистрации/обработке.

Терминология Intel

Исключение (exception) это нештатная ситуация, вызванная обработкой текущей команды. Обычно это связано с невозможностью выполнить команду по причине некорректности самой команды, параметров, или состояния системных структур, но есть несколько специальных случаев (например, команды into, bound; подробнее – ниже). Говорят, что процессор генерирует (generate) исключение.

Подпрограмма, зарегистрированная в системе и вызываемая при возникновении исключения, называется обработчиком исключения (exception handler). В различных ситуациях процессоры Intel x86 генерируют различные исключения, в результате вызываются различные обработчики. Типы и причины исключений документированы, программисту остаётся только соответствующим образом написать и зарегистрировать обработчик.

Регистрация

Обработчики исключений регистрируются точно так же, как обработчики программных прерываний: в таблице дескрипторов прерываний, при помощи дескриптора шлюза ловушки. Для исключений в IDT предназначены дескрипторы с номерами от 0 до 31, кроме 2 (о нём – в приложении, в описании NMI).

Описание наиболее интересных, на мой взгляд, исключений приведено в таблице.

Обработчики

Обработчик исключения очень похож на обработчик прерывания: более-менее обычная подпрограмма, заканчивающаяся вызовом iretd (скорее всего, действия, выполняемые обработчиками, должны отличаться по смыслу, но сейчас это нас не касается). Некоторые отличия между обработчиками связаны с тем, что процессор их немного по-разному вызывает. К началу работы обработчика прерывания на вершине стека находится содержимое регистров CS, EIP и EFLAGS (по 4 байта на регистр, и того 12 байт). Это относится и к обработчикам исключений, но:

• Сохранённое в стеке значение CS:EIP не обязательно является адресом команды, следующей за командой, вызвавшей исключение. Наоборот, для большинства исключений там будет адрес именно той команды, которая привела к возникновению исключения.
• Некоторым исключениям в стеке передаётся ещё и четырёхбайтный код ошибки. Даже если обработчик не собирается анализировать этот код, он должен вытолкнуть его из стека, иначе iretd не сможет корректно вернуть управление.

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

Классификация исключений

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

Борис Гребенщиков

Выше, в разделе «Обработчики» описаны основные отличия обработчика исключения от обработчика программного прерывания. С технической точки зрения, именно они и являются основой классификации. Правда, к первому «отличию» (значение адреса возврата в стеке) мы подойдём с неожиданной стороны, так как оно является следствием общего признака классификации: существования трёх типов исключений

Fault

Fault-исключение генерируется процессором до начала выполнения команды. Поэтому:

• Эта команда ещё не успела изменить состояние регистров/стека/памяти.
• В частности, не изменилось значение EIP, и адрес, сохранённый в стеке, это адрес команды, вызвавшей исключение.

После возврата из fault-исключения (если обработчик не поменяет в стеке адрес возврата) процессор попытается ещё раз выполнить ту же самую команду. Это наиболее часто используемый вид исключений, практически в любой ошибочной ситуации процессор с неизменным оптимизмом предлагает «попробовать ещё разик».

Trap

Trap-исключение генерируется процессором сразу после исполнения команды. Соответственно:

• Команда уже изменила всё, что могла.
• В частности, изменилось значение EIP, и адрес, сохранённый в стеке, это адрес команды, следующей за командой, вызвавшей исключение.

К типу trap (на данный момент) относятся только исключения, вызванные успешно исполнившимися командами, например int 3 или into. Сюда же можно отнести и int n, то есть все программные прерывания. По каким-то причинам (видимо, особенности реализации) bound генерирует fault-исключение.

Abort

Abort-исключение генерируется процессором в самом крайнем случае: когда, с его точки зрения, восстановление и нормальная работа уже невозможны, и системе (ну, как минимум, задаче) остаётся только красиво уйти. Поскольку значение адреса возврата в стеке не определено, скорее всего, ОС придётся смириться с диагнозом процессора.

К счастью для разработчиков ОС, пользовательские приложения не способны самостоятельно вызвать abort-исключение. Причиной такого исключения может быть либо аппаратный сбой, либо ошибка в ОС, либо серьёзный недочёт в архитектуре/реализации ОС, дающий пользовательскому ПО лишние возможности.

Код ошибки

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

Табличка

Описанные выше исключения классифицируются следующим образом:

Всё вместе

- Каждому исключению – уважительное отношение и полноценную обработку!
- Ура!!!
... 
Из популистского выступления разработчиков ОС
на собрании процессоров.

Комбинируя признаки классификации, можно насчитать шесть типов исключений:

• Fault без кода
• Fault с кодом
• Trap без кода
• Trap с кодом
• Abort без кода
• Abort с кодом

Все они вызываются немножко по-разному, и все их можно было бы рассмотреть. Но, поскольку:

• Среди исключений, определённых разработчиками Intel, на данный момент отсутствуют trap-исключения с кодом ошибки.
• Обработчики trap-исключений без кода ошибки вызываются точно так же, как обработчики программных прерываний.

Рассмотрены только fault- и abort-исключения. Оговорки те же, что и в случае программных прерываний:

• Соответствующая ячейка IDT содержит именно дескриптор шлюза ловушки.
• Несколько условий, связанных с защитой. Если дескрипторы в GDT и IDT такие, как рекомендовано (то есть, в описанные части дескрипторов записано что-то разумное, для «пока неважных» частей взяты значения, приведённые в таблицах), все условия выполняются. Подробнее эта тема рассмотрена в главах, посвящённых защите.

Fault

Примерно так:

1. По номеру исключения в IDT отыскивается нужный дескриптор, из него извлекается селектор сегмента и смещение начала обработчика.
2. Проверяется корректность селектора (указывает на дескриптор в пределах GDT, это дескриптор сегмента кода, и т.п.) и смещения (попадает в сегмент).
3. В стеке сохраняются регистр EFLAGS и дальний указатель на команду, вызвавшую исключение.
4. [Для исключений с кодом ошибки] В стеке сохраняется код ошибки.
5. CS и EIP загружаются новыми значениями.
6. Начинается выполнение обработчика.
7. [Для исключений с кодом ошибки] Во время выполнения обработчик обязан вытолкнуть из стека код ошибки, иначе корректная передача управления обратно будет невозможна.
8. После своего завершения обработчик возвращает управление командой iretd.
9. Возврат к исходной программе. В регистры EFLAGS, CS и EIP загружается значение из стека, при этом происходит обращение к GDT и проверка корректности устанавливаемого селектора и смещения.

И на картинке, на примере исключения #GP:

Рисунок 1. Алгоритм вызова обработчика fault-исключения на примере General Protection.

Abort

Так как корректный возврат даже и не планируется, алгоритм упрощается:

1. По номеру исключения в IDT отыскивается нужный дескриптор, из него извлекается селектор сегмента и смещение начала обработчика.
2. Проверяется корректность селектора (указывает на дескриптор в пределах GDT, это дескриптор сегмента кода, и т.п.) и смещения (попадает в сегмент).
3. В стеке сохраняется EFLAGS и какие-то значения на месте адреса возврата.
4. [Для исключений с кодом ошибки] В стеке сохраняется код ошибки.
5. CS и EIP загружаются новыми значениями.
6. Начинается выполнение обработчика.

Соответствующая картинка:

Рисунок 2. Алгоритм вызова обработчика abort-исключения на примере Double Fault.

Случилось страшное. Ну, и?.. - II

Итак, процессор обнаружил ошибку, сгенерировал исключение, нашёл в IDT адрес обработчика и передал ему управление… ну и что с ним делать дальше? Допустим, понятно, как обрабатывать исключения, не являющиеся ошибками (в списке это #DB, #BP и #PF, соответственно нужно либо передать управление отладчику, либо подкачивать в память требуемую страницу), но что делать с остальными? Мы уже выяснили, что процессор «сам» не в состоянии справиться с обработкой и просит помощи у ОС, но ведь и ОС тоже далеко не всегда может предложить что-то разумное (например, что вы будете делать, если произошло исключение #DE?). Однако у ОС есть преимущества:

• Если ОС предоставляет пользователям некоторый интерфейс для обработки исключений, в большинстве случаев можно просто передать управление зарегистрированному пользователем обработчику. Обработчик по умолчанию будет, например, выводить сообщение и завершать текущий процесс (в отличие от процессора, ОС в состоянии справиться с такой задачей).
• Если исключение произошло в отлаживаемом приложении, можно передать управление отладчику и переложить ответственность за выбор решения на него.
• В крайнем случае, можно более-менее корректно завершить процесс.
• В самом крайнем случае, можно более-менее корректно завершить работу системы и перезагрузиться.

Программные прерывания vs. Исключения

Остерегайтесь подделок!

Поскольку обработчики исключений регистрируются в той же таблице и по тем же правилам, что и обработчики программных прерываний, выполнение команды int n с соответствующим значением n приведёт к вызову обработчика исключения (кстати, пример из главы «Программные прерывания», обрабатывающий нулевое прерывание – по совместительству исключение #DE, именно так и поступает). А, поскольку, (насколько я знаю) простого способа определить причину вызова изнутри обработчика не существует, скорее всего, обработчик примет всё за чистую монету.

Это была завязка. А теперь представьте, что пользователь вызвал обработчик #GP через int 13. Как вы помните, #GP это fault-исключение с кодом ошибки, то есть обработчик рассчитывает увидеть в стеке код ошибки, адрес вызвавшей исключение команды и EFLAGS. К сожалению, ожидания не оправдаются: процессор, обрабатывающий команду int 13 как программное прерывание (trap-исключение без кода ошибки), положит в стек только адрес следующей команды и EFLAGS. В результате:

• Если обработчик читает и как-то интерпретирует код ошибки, вместо кода ошибки он прочитает из стека значение EIP. И начнёт действовать в соответствии…
• Если обработчик читает и как-то интерпретирует предполагаемый адрес возврата из стека, он прочитает CS и EFLAGS вместо EIP и CS. Скорее всего, адрес будет просто некорректный (несуществующий сегмент или что-то подобное).
• Даже если обработчик ничего не читает и не интерпретирует, при возврате произойдёт сразу несколько интересных эффектов. Во-первых, вместо того, чтобы вытолкнуть из стека значение кода ошибки, обработчик вытолкнет из стека значение EIP. Во-вторых, если вызвать iretd сразу после этого, управление вернётся по адресу, состоящему из CS и EFLAGS (смещение – CS и два младших байта EFLAGS, сегмент – старшие байты EFLAGS). Скорее всего, адрес будет некорректным. В-третьих, даже если обработчик меняет адрес возврата по собственному разумению, стек будет испорчен (удалено лишнее слово), а в регистр EFLAGS окажется загруженным слово, лежавшее на вершине стека перед вызовом int 13 (это упрощение, что именно будет с EFLAGS – большой вопрос, подробнее см. главу «Защита: ввод-вывод»).

Так как обработчик #GP это часть ОС, скорее всего, всё это приведёт к падению системы. Печально? Это ещё что, ведь пользователь может вызвать int 8 и обработчик #DF, который просто завершит систему!

К счастью, разработчики процессора предусмотрели решение этой проблемы: дескриптор шлюза ловушки в IDT может запрещать пользователю явный вызов обработчика прерывания командой int n, но разрешать обработку соответствующего исключения (точнее, при генерации исключения проверка прав производиться не будет). При нарушении будет сгенерировано исключение #GP.

Подробнее эта тема рассмотрена в главе «Теоретическое введение в защиту».

Пример

Обработчик #GP

Программа устанавливает обработчик исключения #GP и генерирует соответствующее исключение при попытке изменить сегмент кода. Код полностью повторяет пример int0.asm из предыдущей главы, кроме следующих отличий:

• Обработчик регистрируется в 13-й ячейке IDT, соответствующей исключению #GP.
• Для генерации исключения используется не int n, а mov cs:[0], eax.
• Поскольку #GP – исключение с кодом ошибки, перед возвратом управления нужно удалить из стека значение кода ошибки. Это достигается командой add esp, 4.
• Поскольку #GP – fault-исключение, простой вызов iretd в конце обработчика вернёт управление на начало команды, вызвавшей исключение. Иногда это именно то, что нужно, но не в нашем случае – так как обработчик даже не пытается ничего исправить, повторное выполнение команды приведёт к повторной генерации исключения и программа попадёт в бесконечный цикл. Поэтому перед завершением обработчик меняет значение адреса в стеке: увеличивает сохранённый EIP на 5 – размер команды mov cs:[0], eax, с помощью которой было сгенерировано исключение.

; gpf.asm
; Программа, устанавливающая и вызывающая обработчик исключения #GP

        .model tiny
        .code
        .386p
        org     100h

;;;;;;;;;;;;;;;;;;;;;;;;;;;        
;
; Структуры
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;

; Сегментный дескриптор
segment_descriptor struct
    limit_low   dw      0    ; Младшие два байта поля Segment limit
    base_low    dw      0    ; Младшие два байта поля Base Address
    base_high0  db      0    ; Второй байт поля Base Address
    type_and_permit db  0    ; Флаги
    flags       db      0    ; Ещё одни флаги
    base_high1  db      0    ; Старший байт поля Base Address
segment_descriptor ends

; Дескриптор шлюза
gate_descriptor struct
    offset_low  dw      0    ; Два младших байта поля Offset
    selector    dw      0    ; Поле Segment Selector
    zero        db      0
    type_and_permit db  0    ; Флаги
    offset_high dw      0    ; Старшие байты поля Offset
gate_descriptor ends

; Регистр, описывающий таблицу
table_register struct
    limit       dw      0    ; Table Limit
    base        dd      0    ; Linear Base Address
table_register ends

;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; Код
;
;;;;;;;;;;;;;;;;;;;;;;;;;;

start:
        ; Подготавливаем DS
        push    cs
        pop     ds

        ; В es - начало видеобуфера. Можно было сделать то же
        ; самое средствами защищённого режима, но так проще
        push    0b800h
        pop     es

        ; Устанавливаем правильный сегмент в long-jmp-to-RM
        mov     ax, cs
        mov     cs:rm_cs, ax

        ; Прописываем адрес начала cs в качестве базового адреса сегмента
        call    cs_to_eax
        mov     dsc64kb.base_low, ax
        shr     eax, 16
        mov     dsc64kb.base_high0, al

        ; Сохраняем IDTR реального режима
        sidt    fword ptr old_idtr

        ; Инициализируем IDT
        call initialize_idt

        ; Инициализируем GDT
        call initialize_gdt

        ; Открываем вентиль A20
        call open_A20

        call disable_interrupts
        call set_PE

        ; 16-разрядный дальний переход. Перключает содержимое cs из нормального
        ; для реального режима (адрес) в нормальное для защищённого (селектор).
        ; Базовый адрес целевого сегмента совпадает с cs,
        ; поэтому смещение можно прописать сразу
        db      0EAh   ; код команды дальнего перехода
        dw      $ + 4  ; смещение
        dw      8      ; селектор

        ; В данный момент сегмент кода - 64 Кб, базовый адрес равен
        ; адресу сегмента кода до переключения в защищённый режим.

        mov cs:[0], eax ; Вызываем обработчик исключения

        call clear_PE

        ; Мы в реальном режиме, осталось разобраться с
        ; значением регистра cs

        ; 16-разрядный дальний переход. Перключает содержимое cs из нормального
        ; для защищённог режима (селектор) в нормальное для реальног (адрес).
        ; Адрес сегмента вычисляется и прописывается во время выполнения.
        db      0EAh   ; код команды дальнего перехода
        dw      $ + 4  ; смещение
rm_cs   dw      0      ; сегмент

        ; восстанавливаем IDTR реального режима
        lidt    fword ptr old_idtr

        ; разрешаем прерывания
        call enable_interrupts

        ret

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Обработчик прерывания
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

; Обработчик исключения #GP, меняет символы и их атрибуты по всему экрану,
; Перед завершением увеличивает адрес возврата в стеке 
; на размер команды mov cs:[0] (5 байт)
gpf_handler:

        ; В данный момент, в стеке:
        ; esp +  0 - error code
        ; esp +  4 - EIP
        ; esp +  8 - CS
        ; esp + 12 - EFLAGS

        push   eax
        push   ecx

        mov    eax, 0         ; Текущий символ
        mov    ecx, 80 * 25   ; Колическтво сиволов на экране

screen_loop:
        inc    byte ptr es:[eax]          ; Меняем символ
        inc    eax
        inc    byte ptr es:[eax]          ; Меняем атрибут
        inc    eax
        loop   screen_loop

        pop    ecx
        pop    eax

        ; Удаляем из стека код ошибки
        add    esp, 4             
        ; Добавляем к адресу возврата 5 – размер команды mov cs:[0], eax
        ; В результате возврат произойдёт на начало следующей команды
        add    dword ptr [esp], 5 

        iretd

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Данные
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

; Глобальная таблица дескрипторов
GDT     label byte
        ; Нулевой дескриптор
        segment_descriptor <>
        ; Дескриптор сегмента кода, размер 64 Kb
dsc64kb segment_descriptor <0ffffh, 0, 0, 10011010b, 0, 0>
        		; 10011010b - 1001, C/D - 1, 0, R/W - 1, 0
        		; 0         - G - 0, 000, Limit - 0
       		
; Данные для загрузки в GDTR
gdtr    table_register <$ - GDT - 1, 0>


; Таблица дескрипторов прерываний
IDT     label byte

        gate_descriptor <>  ;0 - #DE
        gate_descriptor <>  ;1 - #DB
        gate_descriptor <>  ;2
        gate_descriptor <>  ;3 - #BP
        gate_descriptor <>  ;4 - #OF
        gate_descriptor <>  ;5 - #BR
        gate_descriptor <>  ;6
        gate_descriptor <>  ;7
        gate_descriptor <>  ;8 - #DF
        gate_descriptor <>  ;9 
        gate_descriptor <>  ;10
        gate_descriptor <>  ;11
        gate_descriptor <>  ;12 - #SS

        ; 13 - #GP
        ; Дескриптор шлюза ловушки. 
        ; Обработчик исключения находится в сегменте, соответствующем первому
        ; дескриптору GDT. Поскольку базовый адрес сегмента такой же, как
        ; в реальном режиме, смещение обработчика тоже совпадает.
        gate_descriptor <gpf_handler, 8, 0, 8Fh, 0>

; Данные для загрузки в IDTR
idtr    table_register <$ - IDT - 1, 0>

; Место для IDTR реального режима
old_idtr table_register <>  

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Служебные функции
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

; Открывает вентиль A20
open_A20:
        in      al, 92h
        or      al, 2
        out     92h, al
        ret

; Инициализирует IDT
initialize_idt:
        ; Вычисляем линейный адрес начала массива дескрипторов
        call    cs_to_eax
        add     eax, offset IDT
        ; Записываем его в структуру
        mov     idtr.base, eax

        ; Загружаем IDTR
        lidt    fword ptr idtr
        ret

; Инициализирует GDT
initialize_gdt:
        ; Вычисляем линейный адрес начала массива дескрипторов
        call    cs_to_eax
        add     eax, offset GDT
        ; Записываем его в структуру
        mov     gdtr.base, eax

        ; Загружаем GDTR
        lgdt    fword ptr gdtr
        ret

; Запрещает маскируемые и немаскируемые прерывания
disable_interrupts:
        cli              ; запретить прерывания
        in      al, 70h  ; индексный порт CMOS
        or      al, 80h  ; установка бита 7 в нем запрещает NMI
        out     70h, al
        ret

; Разрешает маскируемые и немаскируемые прерывания
enable_interrupts:
        in      al, 70h  ; индексный порт CMOS
        and     al, 7Fh  ; сброс бита 7 отменяет блокирование NMI
        out     70h, al
        sti              ; разрешить прерывания
        ret

; Устанавливает флаг PE
set_PE:
        mov     eax, cr0 ; прочитать регистр CR0
        or      al, 1    ; установить бит PE,
        mov     cr0, eax ; с этого момента мы в защищенном режиме
        ret

; Сбрасывает флаг PE
clear_PE:
        mov     eax, cr0 ; прочитать CR0
        and     al, 0FEh ; сбросить бит PE
        mov     cr0, eax ; с этого момента мы в реальном режиме
        ret

; Вычисляет линейный адрес начала сегмента кода
cs_to_eax:
        mov     eax, 0
        mov     ax, cs
        shl     eax, 4
        ret

        end     start

Задания

• Разные варианты нарушения работы примера: уберите из обработчика изменение адреса в стеке, уберите из обработчика удаление из стека кода ошибки, вызовите обработчик командой int 13, командой mov cs:[12345678h], eax.
• Возьмите программу int0.asm из прошлой главы, переименуйте её в de.asm и замените в ней команду int 0 на команды mov ax, 10, mov bx, 0 и div bl. Посмотрите, что получится. А теперь добавьте в обработчик команду mov bx,1.
• В обработчике #GP выведите на экран значения кода ошибки, EIP, CS и EFLAGS из стека. Где возможно – проверьте, что это именно они.
• Напишите программу, вызывающую из обработчика исключения программное прерывание.
• Напишите программу, генерирующую в обработчике исключения ещё одно исключение.
• Напишите программу, генерирующую при первом входе в обработчик исключения такое же исключение (храните количество входов в глобальной переменной или регистре, чтобы избежать вечного цикла).
• Переделайте пример gpf.asm. Во-первых, поменяйте mov cs:[0], eax на int 0 и измените в обработчике #GP размер команды на 2 (размер инструкции int 0). Убедитесь, что пример работает. Во-вторых, перепишите программу так, чтобы исключение возникало, но обработчик #GP исправлял ситуацию, возвращал управление, не меняя адреса, и вторая попытка проходила бы успешно. Например, исключение может возникать из-за того, что в нулевой ячейке IDT некорректный дескриптор, а обработчик #GP его исправляет.
• Попытайтесь сделать то же, что и во второй части предыдущего пункта, но вместо int 0 используйте деление на 0. У вас не должно получиться, так как не вызовется обработчик #GP, эта ситуация трактуется процессором как Double Fault и вызывается обработчик #DF. Не смотря на то, что «по правилам» адрес, сохранённый в стеке abort-исключения, не определён, в данной ситуации это будет адрес команды div, и исключение можно нормально обработать и вернуть управление. Ниоткуда из документации этого не следует, установлено опытным путём на одной конкретной машине, так что может и не воспроизвестись. Тем не менее, попробуйте. Подробнее про исключение #DF смотрите в приложении.

And I wait for them to interrupt
Me drinking from that broken cup
And ask me to open up the gate for you.

Bob Dylan

Что стучишься в дверь моя, видишь – дома нет никто, 
если ты моя жена – заходи по одному... 

Присказка из недалёкого детства

Как вы, без сомнения, знаете, помимо процессора и оперативной памяти, в состав компьютера входят и другие полезные устройства, с которыми ОС так или иначе приходится взаимодействовать. И, естественно, этот факт нельзя было проигнорировать при разработке процессора.

Собственно способ взаимодействия тривиален: поскольку единственное, что умеет делать процессор – обработка данных, представленных набором битов/байтов/слов, «взаимодействие» сводится к чтению или записи во внутренние регистры устройства. От устройства зависит то, как именно доступны регистры (через заданные физические адреса в памяти [команда mov], либо через порты ввода/вывода [команды in и out]), что за данные передаются, и какого протокола нужно придерживаться, но это всё детали. Конечно, настоящая ОС должна уметь работать хоть с какими-то реальными устройствами, но к архитектуре процессора адреса/порты/протоколы имеют слабое отношение, и рассмотрение программирования конкретных устройств выходит за рамки курса.

А вот что действительно интересно – возможность начинать взаимодействие по инициативе устройства. В случае Intel x86 это называется внешним (external) или аппаратным (hardware generated) прерыванием (interrupt), а результатом прерывания является исполнения зарегистрированной в системе подпрограммы – обработчика прерывания (interrupt handler).

Что и зачем

О внешних прерываниях, о том, для чего они используются, об их преимуществах и недостатках по сравнению с опросом готовности (polling; иногда называют иначе, но пусть будет «опрос готовности»), должно быть сказано в любом приличном курсе по архитектуре ОС (если не сказано – курс не приличный), надеюсь, вы прочитали/прослушали хотя бы один. Тем не менее, из-за исключительной важности темы, я попытаюсь ещё раз всё это объяснить. На всякий случай.

Что

Скорее всего, все представляют себе, что такое внешнее прерывание. Описать можно примерно так: некоторое внешнее устройство (клавиатура, таймер, COM-порт, …) хочет что-то сообщить процессору (нажата клавиша, прошло 0.001 секунды, приняты новые данные, …), причём оно не ждёт, пока процессор обратит на него внимание, а самостоятельно его «дёргает». В результате возникает особая ситуация, называемая внешним прерыванием, и, если это прерывание не заблокировано тем или иным способом, вызывается обработчик прерывания. Как и программные, внешние прерывания тоже нумеруются, и их обработчики тоже регистрируются в IDT, причём почти так же.

Это всё хорошо и верно, но совершенно недостаточно, так как не отражает должным образом важность и уникальность механизма внешних прерываний. Нужно понимать, что они, и только они:

• Позволяют прекратить (временно или нет) исполнение текущего кода, независимо от желания оного. Абсолютно необходимая возможность для многозадачной ОС.
• Вносят в работу процессора интерактивность.
• Вносят некоторую непредсказуемость. Точнее, для метасистемы «компьютер + пользователь» внешние прерывания предсказуемы и теоретически воспроизводимы (практически для этого надо научить пользователя повторять свои действия с точностью до микросекунд), но для системы «процессор + ОЗУ» – нет. Поэтому часто говорят, что они возникают асинхронно, имея ввиду «без связи, без синхронизации с исполняемым в данный момент кодом». Программные прерывания и исключения генерируются процессором и всегда связаны с текущей командой, то есть происходят только синхронно и вполне воспроизводимы.

Внешние прерывания дают возможность диалога с процессором. Без них компьютер способен работать только в режиме «пакетной обработки заданий»: загрузили ящик данных, подумал, погудел, выдал результат. Готов принять следующий ящик… Ну, то есть, это некоторое преувеличение, система типа DOS сможет более-менее прожить без внешних прерываний (от некоторых возможностей, конечно, придётся отказаться, да и программировать будет не так удобно), но ни о какой ОС с вытесняющей многозадачностью речь не будет идти точно.

Зачем

Основные области применения:

• Переключение задач по прерыванию таймера. Или, несколько шире, выполнение некоторого действия при наступлении заданного момента времени. Или, совсем широко, выполнение некоторого действия по заданному внешнему событию. Но переключение задач, пожалуй, наиболее показательный и конкретный пример, принципиально не реализуемый без использования внешних прерываний.
• Обработка критических аппаратных ошибок.
• Взаимодействие с интерактивными устройствами. Клавиатура, мышь, сетевой адаптер, COM-порт. Пришли данные – устройство «дёргает» процессор, тот ненадолго обращает на него внимание, обрабатывает данные, продолжает работать дальше.
• Взаимодействие с интеллектуальными устройствами. Например, для реализации сценария типа: «Рядовой Иванов! Приказываю немедленно приступить к запоминанию (обработке/пересылке/…) посланных Вам (запрошенных у Вас) десяти мегабайт информации! Об исполнении доложить лично мне».
• Взаимодействие с недостаточно быстрыми и не очень интеллектуальными устройствами. Например, COM-порт умеет работать с данными только по одному байту и не в состоянии обрабатывать их с той же скоростью, что и процессор. При работе с использованием прерываний, процессор не ждёт каждый раз, пока COM-порт отправит байт, а занимается какими-то другими делами (чем ОС загрузит). Когда передача текущего байта закончится и COM-порт будет готов принять следующий, он сгенерирует прерывание «COM-порт опять готов», процессор переключится на обработчик, пошлёт очередной байт и снова вернётся к работе. В сущности, то же самое, что и пунктом выше, только мороки больше, так как передача ведётся по одному байту.

Дескриптор шлюза прерывания

Элементом IDT, соответствующим внешнему прерыванию, может быть и дескриптор шлюза ловушки, но специально для этой цели предназначен дескриптор шлюза прерывания (interrupt gate descriptor). Он очень похож на дескриптор шлюза ловушки, единственное отличие – при входе в обработчик через дескриптор шлюза прерывания, автоматически сбрасывается флаг IF, маскируя внешние прерывания (как вы помните, в реальном режиме внешние прерывания маскируются при входе в обработчик любого прерывания). Форматы дескрипторов тоже практически одинаковые, отличается только один бит (0-й бит пятого байта), тем не менее, для полноты картины, привожу описание:

То же самое на картинке:

Рисунок 1. Формат дескриптора шлюза прерывания.

И, конечно, пример:

    db      04h         ; Offset – два младших байта
    db      03h 
    db      8           ; Segment selector 
    db      0 
    db      0           ; 0
    db      10001110b   ; 10001110 – магическое число..
    db      02h         ; Offset – два старших байта
    db      01h

Это дескриптор шлюза прерывания, селектор сегмента указывает на первый дескриптор GDT, смещение – 01020304h.

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

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

Как [всё по очереди]

- Приведите пример преобразователя стека в очередь.
- Автомат Калашникова!

Анекдот

Возникновение и обработка внешнего прерывания – сложный процесс, в котором задействовано несколько устройств, различные внутрипроцессорные структуры (регистры, флаги, стек) и собственно обработчик. Поэтому, чтобы не мешать всё в одну кучу, описание разделено на две части: «вне процессора» и «внутри процессора»; первая часть в основном посвящена сигналам, шинам и соединениям, вторая – более привычным вопросам: регистры, стек и обработчик.

Вне процессора

Примерно половину задач, возникающих при возникновении прерывания, берёт на себя программируемый контроллер прерываний (programmable interrupt controller, PIC; по-русски – ПКП). Схема подключения показана на Рисунке 2.

Рисунок 2. Модель реализации внешних прерываний

Последовательность действий при обработке прерывания:

1. Устройство посылает запрос на прерывание (Interrupt Request, IRQ) на вход irX ПКП.
2. ПКП заносит прерывание в список «ожидающие обработки».
3. Если это прерывание не замаскировано, и в списке «обрабатываемые в данный момент» нет прерываний с большим или равным приоритетом, ПКП устанавливает выходной сигнал int, который соединён с входом процессора intr (судя по всему, опять Interrupt Request).
4. Если прерывания разрешены (флаг IF установлен), процессор периодически проверяет значение intr. Обнаружив запрос на прерывание, процессор отвечает установкой сигнала inta (Interrupt acknowledge).
5. ПКП переводит прерывание из списка «ожидающие обработки» в список «обрабатываемые в данный момент» и выставляет на шину D соответствующий номер прерывания.
6. Процессор считывает с шины D номер прерывания, находит по IDT обработчик, прерывает текущий поток исполнения, вызывает обработчик прерывания.
7. Выполняется обработчик, что именно он делает – зависит от него, но, как минимум, он должен сообщить ПКП, что прерывание обработано.
8. (Предполагаем, что обработчик написан корректно) ПКП удаляет прерывание из списка «обрабатываемые в данный момент». До тех пор, пока это не сделано, блокируется обработка прерываний с таким же и более низким приоритетом (см. пункт 3 этого же алгоритма), то есть некорректный обработчик может нарушить всю систему обработки прерываний.
9. Управление возвращается к прерванной программе.

В результате, ПКП отвечает за:

• Отображение входного сигнала irX на номер соответствующего ему прерывания
• Маскирование/демаскирование прерываний (по запросу процессора), поддерживает список замаскированных прерываний.
• Список запрошенных прерываний
• Список обрабатываемых прерываний.
• Относительную приоритетность прерываний.

И всем этим значительно облегчает работу процессора.

Внутри процессора

После того, как ПКП передал процессору номер прерывания, в обработку включается собственно процессор. Тут всё как всегда, с минимальными отличиями:

1. По номеру прерывания в IDT отыскивается нужный дескриптор, из него извлекается селектор сегмента и смещение начала обработчика.
2. Проверяется корректность селектора (указывает на дескриптор в пределах GDT, это дескриптор сегмента кода, и т.п.) и смещения (попадает в сегмент).
3. В стеке сохраняются регистр EFLAGS и текущее значение регистров CS и EIP.
4. Сбрасывается флаг IF, маскируя внешние прерывания (если в IDT дескриптор шлюза прерывания, а не ловушки), CS и EIP загружаются новыми значениями.
5. Начинается выполнение обработчика.
6. После своего завершения обработчик сообщает ПКП, что прерывание обработано и возвращает управление командой iretd.
7. Возврат к прерванной программе. В регистры EFLAGS, CS и EIP загружается значение из стека (помимо прочего, флагу IF возвращается значение, которое у него было до вызова прерывания), при этом происходит обращение к GDT и проверка корректности устанавливаемого селектора и смещения.

На картинке:

Рисунок 3. Обработка внешнего прерывания

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

Программируемый контроллер прерываний Intel x86

Когда вошёл контролёр, 
Скорость перевалила за сто.
Он даже не стал проверять билеты,
Он лишь попросил снять пальто.

Борис Гребенщиков

В ранних моделях x86 ПКП действительно был устроен так, как написано ниже. Но, начиная с Pentium, Intel озаботилась возможностью установки нескольких процессоров на одну материнскую плату, в связи с чем ПКП был основательно переработан. Тем не менее, из соображений обратной совместимости, с ним можно работать так же, как и раньше. Возможно, это не лучший вариант, но зато самый простой и наиболее полно описанный в литературе. Итак, перенесёмся в далёкие 80-е. Представьте: Гребенщиков молодой и худенький, Цой жив и только-только записал «45», а Intel использует для реализации ПКП микросхему i8259A.

ПКП i8259A

Замечательно простое и функциональное устройство. Краткие ТТХ:

• Принимает запросы на прерывания от восьми устройств (от ir0 до ir7)
• Номер прерывания на выходе – число от 0 до 255, можно программно установить нижнюю границу, соответствующую ir0.
• Поддерживает маскирование прерываний
• Поддерживает каскадное подключение (об этом ниже, в следующем разделе).

Управляется через два регистра размером по одному байту каждый, они доступны программисту через порты ввода-вывода (команды in и out).

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

Маскирование/демаскирование прерываний

Пример маскирования всех прерываний, кроме, устройства, подключённого к ir1:

        mov al, 11111101b
        out <первый>, al

Каждый разряд числа соответствует входу микросхемы, разряды, установленные в 1 маскируют соответствующий им вход, разряды установленные в 0 демаскируют.

Для получения списка замаскированных прерываний нужно читать тот же регистр, результат возвращается в том же формате. Это даёт следующую возможность:

        in  al, <первый>
        or  al, 00000001b
        out <первый>, al

То есть замаскировать ir0, а все остальные оставить в том же состоянии.

Завершение обработки прерывания

В рамках курса – так:

        mov al, 20h 
        out <нулевой>, al

Изменения номера первого прерывания

Для этого надо заново инициализировать ПКП. Всё в тех же рамках, это должно выглядеть так:

        out <нулевой>, 00010001b 
        out <первый>, <номер обработчика для ir0> ; должен быть кратен восьми
        out <первый>, 00000100b ; или 2, см. следующий раздел
        out <первый>, 00000001b 

Команды, посылаемые ПКП при инициализации, называются ICW1 – ICW4 (Initialization Command Word). Команда ICW3 связана с каскадным соединением i8259A, более подробно она описана ниже.

Каскадное соединение ПКП i8259A в x86

Всего восемь устройств – маловато для серьёзной работы. Разработчики i8259A это понимали, поэтому предусмотрели возможность объединения нескольких микросхем в один ПКП. Грубо говоря, для этого нужно выход int одной микросхемы i8259A подать на вход irX другой, после чего они смогут работать «почти как одна», это и называется каскадным соединением.

Таким способом можно соединить до девяти микросхем (одна ведущая и восемь ведомых, многоуровневое каскадирование не поддерживается), получив возможность работать с 64-мя устройствами. При этом на уровне сигналов int/intr/inta/D достигается полная прозрачность, то есть, с точки зрения «аппаратного уровня» ничего не меняется. Но на «программном уровне» появляются отличия: каждый i8259A имеет свои собственные управляющие регистры, их надо отдельно инициализировать (ведущий и ведомые по-разному) и ими надо по отдельности командовать.

Но это теория. Практически, в компьютерах на основе 80286 используется две микросхемы i8259A, ведомая подключена к входу ir2 ведущей. Схема показана на Рисунке 4, на нём же отображено соответствие irX – IRQX и несколько наиболее полезных прерываний (при желании вы можете найти «классический» список внешних прерываний в любой книжке по ассемблеру, например в [Зубков 1999]).

Рисунок 4. Каскадное соединение i8259A в x86, IRQ, наиболее интересные прерывания

Что ещё можно сказать про ПКП:

• Номера портов, соответствующих регистрам ведущего ПКП – 20h и 21h, ведомого – A0h и A1h (очевидная закономерность: номер первого порта на 1 больше нулевого, достаточно запомнить два числа, а не четыре).
• BIOS инициализирует оба ПКП, при этом им назначаются следующие диапазоны прерываний: ведущему – от 08h до 0Fh, ведомому – от 70h до 77h. Если эти диапазоны вас устраивают, инициализировать их заново не обязательно.
• Так как Intel очень не рекомендует использовать прерывания из диапазона 0h – 1Fh для каких-то своих целей, в том числе и для внешних прерываний (см. главу «Исключения»), диапазон прерываний ведущего ПКП вас устраивать не должен. Во всяком случае, в настоящих программах.
• Для того чтобы ведомый ПКП работал, вход ir2 ведущего ПКП должен быть открыт (не замаскирован), иначе автоматически маскируются все прерывания ведомого ПКП.
• Если за прерывание отвечает ведущий ПКП, команду «прерывание обработано» нужно посылать только ему, если за прерывание отвечает ведомый ПКП, команду надо послать обоим. Во втором случае для ведущего ПКП текущим является прерывание IRQ2, и его тоже надо завершить.
• ПКП сам знает, ведущий он или нет, это решается аппаратно (для этого предназначен специальный входной сигнал, у ведомого ПКП он подключён к нулю, у ведущего – к единице). Поэтому внешне ICWx для ведущего и ведомого ничем не отличаются, отличается только смысл ICW3.

И, наконец, правильная инициализация. Для ведущего:

        out 20h, 00010001b 
        out 21h, <номер обработчика для ir0> ; должен быть кратен восьми
        out 21h, 00000100b ; битовая маска, единицей отмечены входы,
                           ; к которым подключены не обычные устройства, 
                           ; а ведомые ПКП. 
        out 21h, 00000001b 

Для ведомого:

        out A0h, 00010001b 
        out A1h, <номер обработчика для ir0> ; должен быть кратен восьми
        out A1h, 2 ; номер ведомого ПКП, совпадает с номером входа 
                   ; ведущего ПКП, к которому подключен ведомый ПКП
        out A1h, 00000001b

Программные прерывания vs. Внешние

Точно так же, как и в случае с обработчиком исключения, непредсказуемый пользователь может попытаться вызвать через int обработчик внешнего прерывания. При этом, хотя стек вызова будет правильный, если не повезёт, результат может оказаться даже более эффектным – с аппаратурой лучше не шутить. Рекомендуемое решение проблемы стандартное – запретить пользователям вызывать обработчики напрямую, дескриптор шлюза прерывания такую возможность даёт, подробнее в главах про защиту.

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

        mov al, 00001011b ; 00001011b - команда запроса списка 
                          ; обрабатываемых прерываний
        out <нулевой>, al 
        in  al, <нулевой>  ; Теперь в al маска, единицами отмечены
                          ; обрабатываемые прерывания

Пример

Часы реального времени

Счастливые часов не наблюдают.

Александр Сергеевич Грибоедов

Часы реального времени (Real Time Clock, RTC) – замечательное устройство, очень привлекательное в качестве примера:

• Оно умеет генерировать периодические прерывания
• Присоединено к ведомому ПКП, что позволяет поставить гораздо больше экспериментов.

Единственная проблема – просто так RTC работать не будет, его тоже надо немного программировать. К счастью, это не сложно. У RTC довольно много регистров, но для работы с ним используется только два порта: 70h и 71h. Порт 70h – индексный, в него записывается номер регистра RTC, который будет прочитан/записан при следующем обращении к порту 71h. Если подряд идет несколько обращений к одному и тому же регистру RTC (например, чтение – наложение маски – запись нового значение), переустанавливать значение индекса необязательно.

Ниже, с самыми минимальными пояснениями, приведён код, который используется в примере, за более подробной информацией обращайтесь, например, к [Зубков 1999].

Перевод RTC в режим периодических прерываний:

        ; Разрешение периодического прерывания RTC
        mov     al, 0bh         ; прочитать регистр 0Bh
        out     70h, al
        in      al, 71h
        or      al, 01000000b   ; Установить шестой бит в 1
        out     71h, al         ; Записать обратно

Аналогично, возврат в режим по умолчанию:

        ; Запрещение периодического прерывания RTC
        mov     al, 0bh         ; прочитать регистр 0Bh
        out     70h, al
        in      al, 71h
        and     al, 10111111b   ; Сбросить шестой бит
        out     71h, al         ; Записать обратно

Настройка частоты прерываний:

        ; Установка частоты периодического прерывания RTC
        mov     al, 0ah        ; прочитать регистр 0Ah 
        out     70h, al
        in      al, 71h
        or      al, 0fh        ; Четыре младших бита определяют частоту. 
                               ; 1111 - 2 раза в секунду.
        out     71h, al        ; Записать обратно

После возникновения прерывания, RTC устанавливает флаги (вам не важно какие :)) в регистре 0Ch, при чтении этого регистра флаги сбрасываются. А пока они не сброшены, новых прерываний не происходит (аналог списка обрабатываемых прерываний ПКП и команды завершения обработки прерывания).

        ; Читаем из регистра 0Ch RTC, иначе прерываний больше не будет
        mov     al, 0ch
        out     70h, al
        in      al, 71h

Обработчик прерывания RTC

Программа последовательно выполняет следующие действия:

• Переключается в защищённый режим, инициализируя при этом IDT. В IDT на позиции 28h находится корректный дескриптор шлюза прерывания, ссылающийся на тот самый обработчик.
• Запоминает старое значение масок обоих ПКП.
• Инициализирует ПКП, устанавливая ведущему базовый номер 20h, а ведомому – 28h.
• Маскирует все прерывания, кроме IRQ2 (на ведущем ПКП), и IRQ8 (на ведомом, это и есть прерывание RTC).
• Настраивает RTC. Разрешает периодические прерывания, устанавливает частоту на 2 раза в секунду.
• Разрешает прерывания.
• Ждёт в цикле, пока обработчик не выполнится 10 раз (обработчик при каждом вызове уменьшает на 1 значение ecx).
• Запрещает прерывания.
• Запрещает периодические прерывания от RTC.
• Ещё раз инициализирует ПКП, возвращая номерам прерываний исходные значения.
• Восстанавливает запомненные маски обоим ПКП.
• Переключается в реальный режим.

Код написан на основе примера int0.asm из главы про программные прерывания.

; int_rtc.asm
; Программа, устанавливающая и вызывающая обработчик прерывания RTC

        .model tiny
        .code
        .386p
        org     100h

;;;;;;;;;;;;;;;;;;;;;;;;;;;        
;
; Структуры
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;

; Сегментный дескриптор
segment_descriptor struct
    limit_low   dw      0    ; Младшие два байта поля Segment limit
    base_low    dw      0    ; Младшие два байта поля Base Address
    base_high0  db      0    ; Второй байт поля Base Address
    type_and_permit db  0    ; Флаги
    flags       db      0    ; Ещё одни флаги
    base_high1  db      0    ; Старший байт поля Base Address
segment_descriptor ends

; Дескриптор шлюза
gate_descriptor struct
    offset_low  dw      0    ; Два младших байта поля Offset
    selector    dw      0    ; Поле Segment Selector
    zero        db      0
    type_and_permit db  0    ; Флаги
    offset_high dw      0    ; Старшие байты поля Offset
gate_descriptor ends

; Регистр, описывающий таблицу
table_register struct
    limit       dw      0    ; Table Limit
    base        dd      0    ; Linear Base Address
table_register ends

;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; Код
;
;;;;;;;;;;;;;;;;;;;;;;;;;;

start:
        ; Подготавливаем DS
        push    cs
        pop     ds

        ; В es - начало видеобуфера. Можно было сделать то же
        ; самое средствами защищённого режима, но так проще
        push    0b800h
        pop     es

        ; Устанавливаем правильный сегмент в long-jmp-to-RM
        mov     ax, cs
        mov     cs:rm_cs, ax

        ; Прописываем адрес начала cs в качестве базового адреса сегмента
        call    cs_to_eax
        mov     dsc64kb.base_low, ax
        shr     eax, 16
        mov     dsc64kb.base_high0, al

        ; Сохраняем IDTR реального режима
        sidt    fword ptr old_idtr

        ; Инициализируем IDT
        call initialize_idt

        ; Инициализируем GDT
        call initialize_gdt

        ; Открываем вентиль A20
        call open_A20

        call disable_interrupts
        call set_PE

        ; 16-разрядный дальний переход. Перключает содержимое cs из нормального
        ; для реального режима (адрес) в нормальное для защищённого (селектор).
        ; Базовый адрес целевого сегмента совпадает с cs,
        ; поэтому смещение можно прописать сразу
        db      0EAh   ; код команды дальнего перехода
        dw      $ + 4  ; смещение
        dw      8      ; селектор

        ; В данный момент сегмент кода - 64 Кб, базовый адрес равен
        ; адресу сегмента кода до переключения в защищённый режим.

        ; Сохраняем состояние масок ПКП
        in      al, 021h
        mov     old_mask1, al
        in      al, 0A1h
        mov     old_mask2, al

        ; Инициализация ПКП, в bl и bh - базовые номера прерываний
        ; Ведущий ПКП ставим с 20h, ведомый с 28h
        mov     bl, 020h
        mov     bh, 028h
        call    initialize_pic

        mov     al, 0fbh      ; на ведущем маскируем всё, кроме IRQ2
        out     021h, al
        mov     al, 0feh      ; на ведомом маскируем все, кроме IRQ8 (RTC)
        out     0A1h, al

        ; Установка частоты периодического прерывания RTC
        mov     al, 0ah
        out     70h, al
        in      al, 71h
        or      al, 0fh ; 2 раза в секунду
        out     71h, al

        ; Разрешение периодического прерывания RTC
        mov     al, 0bh
        out     70h, al
        in      al, 71h
        or      al, 01000000b
        out     71h, al

        mov     ecx, 10       ; в ecx – счётчик прерываний
        call enable_interrupts

        ; в цикле ждём, пока прерывание произойдёт 10 раз и обнулит ecx
test_end:
        cmp      ecx, 0
        jne      test_end

        call disable_interrupts

        ; Запрещаем переодическое прерывание от RTC
        mov     al, 0bh
        out     70h, al
        in      al, 71h
        and     al, 10111111b
        out     71h, al

        ; Возвращаем стандартные номера прерываний
        mov     bl, 08h
        mov     bh, 70h
        call    initialize_pic

        mov     al, old_mask1 ; снимаем маскировку
        out     021h, al
        mov     al, old_mask2 ; снимаем маскировку
        out     0A1h, al

        call clear_PE

        ; Мы в реальном режиме, осталось разобраться с
        ; значением регистра cs

        ; 16-разрядный дальний переход. Перключает содержимое cs из нормального
        ; для защищённог режима (селектор) в нормальное для реальног (адрес).
        ; Адрес сегмента вычисляется и прописывается во время выполнения.
        db      0EAh   ; код команды дальнего перехода
        dw      $ + 4  ; смещение
rm_cs   dw      0      ; сегмент

        ; восстанавливаем IDTR реального режима
        lidt    fword ptr old_idtr

        ; разрешаем прерывания
        call enable_interrupts
        ret

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Обработчик прерывания
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

; Обработчик прерывания RTC, ведёт обратный отсчёт
intRtc_handler:
        push    eax
        push    ebx

        dec     ecx           ; уменьшение ecx

        mov     bh, 07h       ; белый текст на чёрном фоне
        mov     bl, '0'
        add     bl, cl        ; если cl меньше 10, то в bl соответствующая цифра

        mov     eax, 80 * 24 * 2
        mov     word ptr es:[eax], bx

        call    upscroll_screen  ; прокручивает экран на строчку вверх

        ; читаем из регистра 0Ch RTC, иначе прерываний больше не будет
        mov     al, 0ch       
        out     70h, al
        in      al, 71h

        mov     al, 020h      ; «неспецифичное» завершение прерывания
        out     020h, al      ; на ведущем ПКП
        out     0A0h, al      ; на ведомом ПКП

        pop     ebx
        pop     eax
        iretd                 ; 32-х разрядный возврат из прерывания

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Данные
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

; Глобальная таблица дескрипторов
GDT     label byte
        ; Нулевой дескриптор
        segment_descriptor <>
        ; Дескриптор сегмента кода, размер 64 Kb
dsc64kb segment_descriptor <0ffffh, 0, 0, 10011010b, 0, 0>
        		; 10011010b - 1001, C/D - 1, 0, R/W - 1, 0
        		; 0         - G - 0, 000, Limit - 0
       		
; Данные для загрузки в GDTR
gdtr    table_register <$ - GDT - 1, 0>


; Таблица дескрипторов прерываний
IDT     label byte

        db    32 dup (  8 dup (0)) ; 0 – 1Fh
        db    8  dup (  8 dup (0)) ; 20h – 27h, ведущий ПКП

        ; Дескриптор шлюза прерывания.
        ; Обработчик прерывания находится в сегменте, соответствующем первому
        ; дескриптору GDT. Поскольку базовый адрес сегмента такой же, как
        ; в реальном режиме, смещение обработчика тоже совпадает.
        gate_descriptor <intRtc_handler, 8, 0, 8Eh, 0>

; Данные для загрузки в IDTR
idtr    table_register <$ - IDT - 1, 0>

; Место для хранения IDTR реального режима
old_idtr table_register <>  

; Место для хранения старых значений масок ПКП
old_mask1 db 	0
old_mask2 db 	0

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Служебные функции
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

; Открывает вентиль A20
open_A20:
        in      al, 92h
        or      al, 2
        out     92h, al
        ret

; Инициализирует IDT
initialize_idt:
        ; Вычисляем линейный адрес начала массива дескрипторов
        call    cs_to_eax
        add     eax, offset IDT
        ; Записываем его в структуру
        mov     idtr.base, eax
        ; Загружаем IDTR
        lidt    fword ptr idtr
        ret

; Инициализирует GDT
initialize_gdt:
        ; Вычисляем линейный адрес начала массива дескрипторов
        call    cs_to_eax
        add     eax, offset GDT
        ; Записываем его в структуру
        mov     gdtr.base, eax
        ; Загружаем GDTR
        lgdt    fword ptr gdtr
        ret

; Запрещает маскируемые и немаскируемые прерывания
disable_interrupts:
        cli              ; запретить прерывания
        in      al, 70h  ; индексный порт CMOS
        or      al, 80h  ; установка бита 7 в нем запрещает NMI
        out     70h, al
        ret

; Разрешает маскируемые и немаскируемые прерывания
enable_interrupts:
        in      al, 70h  ; индексный порт CMOS
        and     al, 7Fh  ; сброс бита 7 отменяет блокирование NMI
        out     70h, al
        sti              ; разрешить прерывания
        ret

; Устанавливает флаг PE
set_PE:
        mov     eax, cr0 ; прочитать регистр CR0
        or      al, 1    ; установить бит PE,
        mov     cr0, eax ; с этого момента мы в защищенном режиме
        ret

; Сбрасывает флаг PE
clear_PE:
        mov     eax, cr0 ; прочитать CR0
        and     al, 0FEh ; сбросить бит PE
        mov     cr0, eax ; с этого момента мы в реальном режиме
        ret

; Вычисляет линейный адрес начала сгмента кода
cs_to_eax:
        mov     eax, 0
        mov     ax, cs
        shl     eax, 4
        ret

; Инициализация ПКП.
;    bl – базовый номер прерывания ведущего ПКП
;    bh - базовый номер прерывания ведомого ПКП
initialize_pic:
        push    eax

        mov     al, 00010001b ; ICW1
        out     020h, al
        out     0A0h, al
        mov     al, bl        ; ICW2, ведущий
        out     021h, al
        mov     al, bh        ; ICW2, ведомый
        out     0A1h, al
        mov     al, 00000100b ; ICW3, ведущий
        out     021h, al
        mov     al, 2         ; ICW3, ведомый
        out     0A1h, al
        mov     al, 00000001b ; ICW4
        out     021h, al
        out     0A1h, al

        pop     eax
        ret

; Прокручивает экран на строчку вверх
upscroll_screen:
        push   eax
        push   ecx
        push   edx

        mov    eax, 0         ; Текущий символ
        mov    ecx, 80 * 24   ; Колическтво символов на экране
                              ; (без последней строки, она отдельно)
screen_loop:
        mov    dx, word ptr es:[eax * 2 + 80*2]
        mov    word ptr es:[eax * 2], dx      ; Меняем символ
        inc    eax
        loop   screen_loop

        mov    ecx, 80        ; Длинна последней строки
        mov    dx,  0720h     ; символ, которым заполняется строка

last_line_loop:
        mov    word ptr es:[eax * 2], dx      ; Меняем символ
        inc    eax
        loop   last_line_loop

        pop    edx
        pop    ecx
        pop    eax
        ret

        end     start

Задания

• Поменяйте базовые номера прерываний так, что: базовый номер ведущего будет больше, они будут совпадать, будет начинаться с 0. Добавьте явную проверку номера прерывания (вызов int n с соответствующим номером). Не забывайте перемещать обработчик в IDT.
• Уберите маскирование прерываний вообще. Наоборот, замаскируйте все прерывания ведущего ПКП, все прерывания ведомого (это два эксперимента). Уберите завершение прерывания на ведущем ПКП, на ведомом ПКП (ещё два эксперимента).
• Перепишите программу, чтобы прерывание вызывалось не RTC, а таймером. IRQ0, ведущий ПКП, никак специально программировать таймер не надо, он по умолчанию в правильном состоянии.
• Измените обработчик так, чтобы он вёл себя по-разному при программном (int n) и аппаратном вызове. Для этого нужно получить у ПКП список обрабатываемых прерываний, как описано в разделе «Программные прерывания vs. Внешние».
• Сделайте обработчик прерывания прерываемым. Алгоритм работы обработчика примерно такой: уменьшить ecx, сохранить его значение в ebx, разрешить повторение прерываний RTC, рапортовать ПКП о завершении обработки, выполнить sti, ждать в цикле, пока ecx не станет равным 0. После этого наконец вывести цифру на экран и прокрутить экран вверх. Учтите, что upscroll_screen временно (внутри себя) меняет значение ecx, если прерывание таймера произойдёт во время выполнения upscroll_screen, счётчик количества прерываний собьется.
• Напишите обработчик прерывания клавиатуры (ведущий ПКП, IRQ1), пусть выводит код нажатой/отпущенной клавиши и завершает программу по Esc. Про то, как это сделать, можно прочитать либо в статье Stanky http://www.rsdn.ru/article/asm/keyboard.xml, либо всё в том же [Зубков 1999]. Не надо писать ничего излишне сложного, просто выводите на экран прочитанный код символа, не анализируя, расширенный он или обычный.
• Эксперименты с дескрипторами шлюза ловушки/прерывания. Убедитесь, что оба дескриптора можно использовать в обработчиках внешних и программных прерываний, что дескриптор шлюза ловушки прерывается внешним прерыванием, а дескриптор шлюза прерывания – нет.
• При использовании описанной инициализации ПКП, приоритеты прерываний будут выстроены следующим образом: IRQ0 > IRQ1 > IRQ8 == …. == IRQ15 > IRQ3 > … > IRQ7. То есть IRQ, присоединённые к ведущему ПКП, упорядочены так, что IRQ0 наиболее приоритетен, а IRQ7 наименее, IRQ ведомого ПКП вставлены на место IRQ2. Проверьте что более приоритетное прерывание (например, таймер) прервёт менее приоритетное (RTC или клавиатура), проверьте, что не происходит обратное. Не забудьте установить флаг IF, иначе прерывание не будет обработано, независимо от его приоритета с точки зрения ПКП.

Jah love, Jah love - protect us

Vincent Ford (performed by Bob Marley)
 
Ты должен быть сильным, 
Ты должен уметь сказать 
«Руки прочь, прочь от меня».
Ты должен быть сильным, 
Иначе зачем тебе быть.

Виктор Цой

Нет защиты, кроме любви.

Борис Гребенщиков

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

Зачем

- Ты хочешь поговорить об этом?

Собирательный образ психолога.

Как вы могли заметить, все описанные до сих пор возможности более-менее повторяют реальный режим: память есть и там, прерывания и исключения – тоже. Защита – первое и решающее отличие. Да, я хочу поговорить об этом :)

Лирическое наступление

Не случайно режим называется «Protected» – защищённый. Не Advanced, не Extended, не Improved, и даже не ++ или #, а именно Protected. Защита – его соль и суть. Ради неё всё и затевалось, именно она склеивает воедино всё остальное, без неё не было бы ни современных ОС, ни современных приложений. И это притом, что защита не даёт каких-то невероятных новых возможностей, наоборот, она отнимает многие старые. Нелогично? Ну, например, можно провести аналогию с переходом от «макаронного» кода, изобилующего goto, к структурному программированию. Или с ассемблера на язык высокого уровня. Только наличие правильно заданных ограничений позволяет системе оставаться управляемой и стабильной, и, как следствие, развиваться и расти дальше.

«Старый» подход упёрся в свой потолок: при появлении многозадачности, графических интерфейсов и т.п., система «компьютер + ОС + запущенное ПО» становится слишком сложной, утверждение «программисты умные, всё будет в порядке» перестаёт работать, и, если других гарантий надёжности нет, всё начинает падать с удручающим постоянством.

Для примера, допустим, что вы всё-таки написали многозадачную ОС реального режима:

• Все приложения, включая вашу ОС, разделяют общее адресное пространство, доступное на чтение и на запись. Это имеет катастрофические последствия. Во-первых, ошибочная запись в память никогда не будет обнаружена непосредственно в момент записи – писать можно везде. Во-вторых, она может привести к краху совсем другого приложения или даже ОС, то есть невозможно не только отследить момент ошибки, практически невозможно отыскать её автора, некорректное приложение.
• Одновременно нескольким приложениям срочно понадобился принтер. Или модем. Или экран. Они все попытались управлять этими устройствами, получилось плохо. А теперь представьте, что им потребовался винчестер. Тут плохо будет всем, включая ОС и пользователя. И даже если ваша ОС предоставляет специальный сервис для корректного, синхронизируемого ввода/вывода, всегда найдётся программа, которая лезет напрямую… А её автор посмотрит на вас чистыми честными глазами и скажет: «Потому что так эффективнее». И он будет прав! Каждой части в отдельности ограничения обычно мешают. Но система в целом без них существовать не может.
• И конечно кому-то захочется убрать переключение процессов. Что бы время не тратилось на какие-то лишние программы, не им написанные… Что может быть проще – перехватил прерывание таймера и рули. Пользователь ОС будет в восторге, безусловно.
• Перехват прерываний это вообще дивная тема. Особенно если несколько программ перехватывают одно прерывание. Самое интересное начнётся, когда они будут выгружаться в неправильном порядке.

• И последний штрих – приложение «выполнило недопустимую операцию». В реальном режиме это, конечно, непросто, но, допустим, процессору встретился неизвестный код инструкции. То есть, генерируется исключение #UD. Вы, конечно, его перехватите, но что делать дальше? Выгружать приложение? А вдруг оно наставило обработчиков прерываний? А вдруг из-за этой же ошибки оно уже записало в общее адресное пространство что-нибудь плохое? В общем, нет никаких гарантий, что даже после успешной выгрузки приложения система будет работоспособна.

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

• отсутствие принудительного централизованного контроля использования ресурсов (память, прерывания, ввод/вывод)
• возрастание сложности системы и связанное с этим повышение вероятности ошибки, при сохранении низкой устойчивость к ошибкам.

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

Так что защита в защищённом режиме играет одну из ключевых ролей. Пытаться абстрагироваться можно и без неё… Но только работать это не будет.

Виды защит

Описанный в предыдущих главах механизм управления памятью тоже относится к «необходимым ограничениям». Проверки существования дескриптора, типа дескриптора, размеров, разрешения чтения/записи, дают большую структурированность, в частности становится невозможно писать по случайному адресу. И в общем-то всё это тоже относится к защите, в том числе и с точки зрения Intel. Согласно терминологии Intel, система защиты в целом называется «protection» и все перечисленные выше проверки относятся к «просто protection» (это не термин). Но есть еще один раздел системы защиты, называемый privilege level protection (а это термин, он довольно неуклюже переводится на русский как «защита по привилегиям»), и именно ему посвящена эта и следующие главы.

Если проводить аналогии, то «просто protection» это стены, крыша и дверь дома, а privilege level protection – возможность запереть дверь на ключ. Если дверь не запирать, дом прекрасно защищён от ветра, снега и дождя, но практически не защищён от человека. С другой стороны, «возможность запереть дверь» сама по себе не существует и появляется только тогда, когда дом и дверь уже есть. Это некоторая дополнительная надстройка над существующими проверками, отделяющая тех, у кого есть ключ, от тех, у кого ключа нет. И, конечно, если у дома разваливаются стены, даже запертая дверь плохо поможет (в качестве примера: по непроверенным слухам, в ОС семейства Windows 9x IDT находится в области памяти, доступной на запись для обычных приложений).

Насущные проблемы

Но спустимся с небес к нашим баранам. Начнём со списка потребностей в защите, которые «всплыли» в предыдущих главах.

• Глава «Обзор защищённого режима»: переключение в реальный режим контролирует ОС, пользователь не может самостоятельно переключить режим (сбросить младший бит регистра cr0).
• Глава «Управление памятью: сегменты и дескрипторы»: управление памятью – задача ОС, пускать сюда пользовательские приложения нельзя. Пользователь не может создать «свою» GDT, то есть, ему запрещено выполнять инструкцию lgdt.
• Глава «Программные прерывания»: точно так же, как и в случае с lgdt, пользовательские приложения не имеют доступа к инструкции lidt.
• Глава «Исключения»: пользователь не может напрямую, через int n вызывать обработчики исключений, ОС регулирует, какие обработчики можно так вызывать, какие – нет.
• Глава «Внешние прерывания»: пользователь не может напрямую управлять ПКП.

Обобщая, получаем следующее:

• Нужно уметь отличать пользовательское приложение от ОС
• Некоторые инструкции пользовательским приложениям выполнять запрещено.
• Нужно уметь разделять ресурсы, к которым пользователю обращаться можно, и ресурсы, к которым пользователю обращаться нельзя (в данном случае – обработчики прерываний).
• Нужно уметь запрещать пользователю обращаться к заданным портам ввода-вывода. Причём список «опасных» портов не фиксирован, а запретить сразу для всех – слишком крутое решение.

Снова дескрипторы

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

На картинке:

Рисунок 1. Формат пятого байта дескриптора.

С точки зрения защиты, ключевое поле – DPL, Descriptor Privilege Level. Название переводится как «уровень привилегий дескриптора», и очень точно отражает предназначение поля.

Уровни привилегий

Царь-царевич, 
Король-королевич, 
Сапожник, портной. 
Кто ты будешь такой?

Считалка

Процессоры Intel x86 поддерживают четыре уровня привилегий.

• 00b – 0-й уровень привилегий – самый привилегированный.
• 01b – 1-й уровень привилегий – менее привилегированный.
• 10b – 2-й уровень привилегий – ещё менее привилегированный.
• 11b – 3-й уровень привилегий – наименее привилегированный.

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

DPL

DPL это пятый и шестой биты пятого байта дескриптора. Для разных дескрипторов DPL имеет разный смысл, по этому признаку все дескрипторы можно разбить на три класса и одно исключение из правил.

Дескриптор сегмента кода

Значение DPL это уровень привилегий, которыми обладает находящийся в сегменте код. Именно этим отличается ОС и пользовательские приложения: код ОС находится в сегментах с нулевым DPL и обладает максимальным (нулевым) уровнем привилегий, код приложений – минимальным (третьим).

Дескриптор «подчинённого» сегмента кода

Кроме дескрипторов «обычного» сегмента кода, существуют дескрипторы подчинённого (conforming) сегмента кода. Их описание вынесено в приложение.

Дескриптор «ресурса»

В поле DPL хранится минимальный (численно максимальный) уровень привилегий, необходимый для доступа к ресурсу. Если к ресурсу обращается код с недостаточными привилегиями, процессор генерирует исключение #GP.

Из описанных в предыдущих главах, к этому классу относятся дескрипторы сегментов данных и обработчиков прерываний (оба варианта). Сюда же можно отнести и дескрипторы сегментов кода (только «обычные», подчинённые будут работать иначе), при использовании с сегментными регистрами DS, ES, FS, GS, то есть не для передачи управления, а как «данные-только-для-чтения». Все неизученные типы дескрипторов также относятся к этому классу.

Например, такое прерывание может вызвать только код с нулевым уровнем привилегий:

        gate_descriptor <int26_handler, 8, 0, 10001111b, 0>

А такое – любой:

        gate_descriptor <int26_handler, 8, 0, 11101111b, 0>

Аналогично с любыми другими дескрипторами ресурсов.

Исключение: дескриптор сегмента данных с регистром SS

Сначала рассмотрим ситуацию (ситуация предполагает периодическое изменение привилегий, сейчас нам не важно как это происходит). Пусть имеется:

• Прикладной код «A», работает на низшем уровне привилегий (3). Занят сложными расчётами.
• Системный код «S», работает на высшем уровне привилегий (0). Обрабатывает прерывания и исключения.
• Стек, используемый и тем и другим. DPL сегмента стека равен 3, и «A» и «S» имеют к нему доступ.

Два варианта развития событий:

• В результате расчётов «A» получил переполнение стека, то есть процессор сгенерировал исключение #SS. Но вряд ли он сможет направить его не обработку, так как для этого нужно положить в стек адрес ошибочкой команды, регистр EFLAGS и код ошибки, а стек и так уже переполнен. Скорее всего, это закончится сбросом процессора и перезагрузкой.
• Более мягкий вариант. «A» вовсю работает, переполнения стека пока нет, хотя он уже почти на пределе. Возникает прерывание таймера, успешно вызывается обработчик из «S». И всё могло бы закончиться хорошо, если бы обработчику не нужно было 8 байт стека, которых уже не осталось. Опять переполнение, сброс и перезагрузка.

Для предотвращения таких ситуаций системный код должен использовать свой сегмент стека. А, видимо, для повышения мотивации использования разных стеков, разработчики Intel просто запретили использовать один и тот же: при загрузке селектора в регистр SS, текущий уровень привилегий должен точно совпадать с DPL дескриптора сегмента.

Подробнее о переключении стеков при смене уровней привилегий написано в главе «Защита: передача управления».

CPL

Текущий уровень привилегий (Current Privilege Level, CPL) – уровень привилегий исполняемого в данный момент кода, или, другими словами, уровень привилегий, на котором в данный момент находится процессор. Обычно CPL совпадает со значением двух младших битов регистра CS.

Рисунок 2. Регистр CS и CPL.

Именно CPL определяет, что разрешено, а что запрещено, именно он проверяется при попытке выполнения привилегированных команд (см. ниже), сравнивается с DPL ресурса (см. выше) и с IOPL (см. ниже). В общем, несколько упрощая, при нулевом CPL можно сделать с системой вообще всё, в любом другом случае придётся спрашивать разрешения.

Значение CPL определяется в соответствии с двумя простыми правилами (подчинённые сегменты кода добавят третье, но пока – два):

• После переключения из реального режима процессор оказывается на максимальном (нулевом) уровне привилегий. Кстати, из этого можно сделать вывод, что внутренние механизмы используют какой-то иной способ определения CPL, так как младшие биты унаследованного от реального режима CS могут оказаться вовсе не 0.
• В дальнейшем CPL равен DPL текущего сегмента кода.

Изменение CPL тоже рассмотрено в главе «Защита: передача управления».

RPL

Два младших бита «нормального» селектора (не загруженного в CS) называются уровень привилегий запроса (Request Privilege Level, RPL), и примерно в 99% ситуаций, единственно разумным значением этого поля будет 0. Тем не менее, поле придумано разработчиками не совсем напрасно, и ситуация, когда ненулевой RPL имеет смысл, всё-таки существует.

Рисунок 3. Селектор и RPL

Ситуация

Рассмотрим следующий сценарий:

• Приложение «A» вызывает системную функцию «F» (вопрос «что значит вызывает системную функцию» пока оставим), передаёт в параметре адрес <SEG:OFFSET>
• «F» читает/пишет по этому адресу
• Управление возвращается к «A», все довольны.

Теперь добавим уровни привилегий:

• «A» работает с минимальным уровнем привилегий (3)
• «F» работает с максимальным уровнем привилегий (0)
• DPL сегмента SEG равен Х

Поскольку «F» выполняется с нулевым уровнем привилегий, она может читать/записывать данные независимо от значения DPL сегмента SEG. Может быть, это как раз то поведение, которое требуется, но может быть, нужно ограничить возможности работы только теми сегментами, которые доступны «A». И вот тут-то на помощь приходит RPL! С ним сценарий выглядит так:

• Приложение «A» вызывает системную функцию «F», передаёт в параметре адрес <SEG:OFFSET>
• Перед использованием адреса, «F» модифицирует его, устанавливая значение поля RPL селектора SEG равным уровню привилегий «A» (как именно она это делает – в следующих главах, в этой главе важна суть).
• «F» читает/пишет по этому адресу. Если селектор SEG ссылается на дескриптор, который недоступен при уровне привилегий, указанном в поле RPL селектора, будет сгенерировано исключение #GP.
• Если всё в порядке, управление возвращается к «A», все довольны. Если было исключение, оно обрабатывается, «F» возвращает ошибку а-ля E_ACCESSDENIED, хакер посрамлён, все довольны.

Строгое описание

Описанное выше применение RPL сводится к следующему правилу: при загрузке селектора сегмента в сегментный дескриптор, система защиты сравнивает c DPL сегмента не только CPL, но и RPL селектора.

Это единственный разумный случай использования RPL. К сожалению, есть ещё несколько не очень разумных, в которых значение RPL всё-таки играет роль:

• При загрузке сегмента стека. RPL должен точно совпадать с CPL и DPL
• При передаче управления сегменту кода. RPL учитывается, как именно – описано в главе «Защита: передача управления».

IOPL

Уровень привилегий ввода-вывода (Input-Output Privilege Level, IOPL). Это поле описано в главе «Защита: ввод-вывод», а здесь упомянуто для комплекта.

VIP only

Следующие инструкции в защищённом режиме можно выполнять только при нулевом CPL (в реальном режиме таких проблем нет, можно всем, всё и всегда):

• lgdt – загрузка регистра GDTR, инициализация GDT
• lidt – загрузка регистра IDTR, инициализация IDT
• mov (в управляющие регистры) – изменение различных флагов, в том числе флага PE.
• ltr – см. следующую главу
• hlt – сброс процессора
• Ещё несколько инструкций, которые вам не понадобятся, полный список есть в [Intel 2004]

Эти инструкции называются привилегированными (privileged instructions), попытка выполнить их при ненулевом CPL приведёт к генерации исключения #GP.

Итого

Если вернуться к началу главы, к разделу «Насущные проблемы», и вспомнить, чего требовалось достичь, то окажется, что практически всё уже успешно достигнуто. Список результатов приведён в Таблице 2.

Для сегментов кода предложенные решения порождают проблему следующего уровня: отделять мы уже умеем, теперь надо как-то наладить связь между кодом с разными уровнями привилегий. Этому вопросу посвящена глава «Защита: передача управления».

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

Дескриптор сегмента данных, регистр не SS

При загрузке селектора в регистр:

1. Если селектор нулевой, он просто загружается, никаких проверок не проводится.
2. Если находящийся в селекторе индекс дескриптора выходит за границы GDT, генерируется исключение #GP.
3. Анализируется тип дескриптора. Флаг S должен быть установлен в 1, дескриптор должен описывать либо сегмент данных, либо доступный для чтения сегмент кода, иначе генерируется исключение #GP.
4. Анализируется поле DPL дескриптора. Должны выполняться неравенства DPL >= CPL и DPL >= RPL селектора (для подчинённых сегментов кода этот пункт будет отличаться), иначе генерируется исключение #GP.
5. Анализируется флаг P дескриптора, он должен быть установлен в 1, подробнее – см. приложение.

При выполнении операции:

1. Если в регистре нулевой селектор, исключение #GP.
2. Если попытка записи в read-only сегмент, исключение #GP.
3. Если адрес выходит за границы сегмента, исключение #GP.

Дескриптор сегмента данных, регистр SS

При загрузке селектора в регистр:

1. Если селектор нулевой, генерируется исключение #GP.
2. Если находящийся в селекторе индекс дескриптора выходит за границы GDT, генерируется исключение #GP.
3. Анализируется тип дескриптора. Дескриптор должен описывать доступный для записи сегмент данных, иначе генерируется исключение #GP.
4. Анализируется поле DPL дескриптора. Должны выполняться равенства DPL == CPL и DPL == RPL селектора, иначе генерируется исключение #GP.
5. Анализируется флаг P дескриптора, он должен быть установлен в 1, подробнее – см. приложение.

При выполнении операции – то же, что и в случае обычного сегментного регистра, отличие только в том, что две первые проверки никогда не сработают: в SS не может находиться нулевой селектор или селектор read-only сегмента.

Пример

Программа выполняет следующие действия:

• Стандартно инициализирует защищённый режим, при этом в GDT оказываются дескрипторы двух сегментов, а в IDT дескриптор обработчика исключения #GP
• Пытается поместить в регистр fs селектор второго дескриптора GDT с RPL равным 3
• Так как поле DPL дескриптора равно 0, генерируется исключение #GP.
• Обработчик исключения выводит на экран восклицательный знак, инкрементирует DPL дескриптора и возвращает управление, позволяя попытаться ещё раз.
• Так как поле теперь DPL дескриптора равно 1, что всё ещё меньше чем 3, опять генерируется исключение #GP, вызывается обработчик, и т.п. Это продолжается до тех пор, пока DPL не станет равен 3.
• Наконец удаётся установить значение fs
• Программа завершается.

В итоге на экране будет три восклицательных знака.

; rpl.asm
; Программа, проверяющая действие поля RPL

        .model tiny
        .code
        .386p
        org     100h

;;;;;;;;;;;;;;;;;;;;;;;;;;;        
;
; Структуры
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;

; Сегментный дескриптор
segment_descriptor struct
    limit_low   dw      0    ; Младшие два байта поля Segment limit
    base_low    dw      0    ; Младшие два байта поля Base Address
    base_high0  db      0    ; Второй байт поля Base Address
    type_and_permit db  0    ; Флаги
    flags       db      0    ; Ещё одни флаги
    base_high1  db      0    ; Старший байт поля Base Address
segment_descriptor ends

; Дескриптор шлюза
gate_descriptor struct
    offset_low  dw      0    ; Два младших байта поля Offset
    selector    dw      0    ; Поле Segment Selector
    zero        db      0
    type_and_permit db  0    ; Флаги
    offset_high dw      0    ; Старшие байты поля Offset
gate_descriptor ends

; Регистр, описывающий таблицу
table_register struct
    limit       dw      0    ; Table Limit
    base        dd      0    ; Linear Base Address
table_register ends

;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; Код
;
;;;;;;;;;;;;;;;;;;;;;;;;;;

start:
        ; Подготавливаем DS
        push    cs
        pop     ds

        ; В es - начало видеобуфера. Можно было сделать то же
        ; самое средствами защищённого режима, но так проще
        push    0b800h
        pop     es

        ; Устанавливаем правильный сегмент в long-jmp-to-RM
        mov     ax, cs
        mov     cs:rm_cs, ax

        ; Прописываем адрес начала cs в качестве базового адреса сегментов
        call    cs_to_eax
        mov     code_dsc.base_low, ax
        shr     eax, 16
        mov     code_dsc.base_high1, al

        ; Сохраняем IDTR реального режима
        sidt    fword ptr old_idtr

        ; Инициализируем IDT
        call initialize_idt
        ; Инициализируем GDT
        call initialize_gdt

        ; Открываем вентиль A20
        call open_A20

        call disable_interrupts
        call set_PE

        ; 16-разрядный дальний переход. Перключает содержимое cs из нормального
        ; для реального режима (адрес) в нормальное для защищённого (селектор).
        ; Базовый адрес целевого сегмента совпадает с cs,
        ; поэтому смещение можно прописать сразу
        db      0EAh   ; код команды дальнего перехода
        dw      $ + 4  ; смещение
        dw      8      ; селектор

        ; В данный момент сегмент кода - 64 Кб, базовый адрес равен
        ; адресу сегмента кода до переключения в защищённый режим,
        ; потому можно без проблем переключаться обратно

        ; Селектор второго дескриптора GDT, RPL равен 3
        mov ax, 10011b
        ; Попытка поместить селектор в сегментный регистр
        mov fs, ax

        call clear_PE

        ; Мы в реальном режиме, осталось разобраться с
        ; значением регистра cs

        ; 16-разрядный дальний переход. Перключает содержимое cs из нормального
        ; для защищённог режима (селектор) в нормальное для реальног (адрес).
        ; Адрес сегмента вычисляется и прописывается во время выполнения.
        db      0EAh   ; код команды дальнего перехода
        dw      $ + 4  ; смещение
rm_cs   dw      0      ; сегмент

        ; восстанавливаем IDTR реального режима
        lidt    fword ptr old_idtr

        call enable_interrupts
        ret

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Обработчики
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

intGpf_handler:
        push   eax
        push   ebx

        mov     bh, 07h       ; белый текст на чёрном фоне
        mov     bl, '!'

        mov     eax, 80 * 24 * 2
        mov     word ptr es:[eax], bx

        call upscroll_screen  ; прокручивает экран на строчку вверх

        ; Запоминаем пятый байт дескриптора в al и ah
        mov     al, res_dsc.type_and_permit
        mov     ah, al

        ; Оставляем в al только DPL (биты 5-6), инкрементируем это поле
        and     al, 01100000b
        add     al, 00100000b
        and     al, 01100000b

        ; Обнуляем в ah поле DPL
        and     ah, 10011111b

        ; Совмещаем
        or      ah, al
        
        ; И кладём в дескриптор
        mov     res_dsc.type_and_permit, ah

        pop     ebx
        pop     eax
        add     esp, 4

        iretd

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Данные
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

; Глобальная таблица дескрипторов
GDT     label byte
        ; Нулевой дескриптор
        segment_descriptor <>
        ; Дескриптор сегмента кода, размер 64 Kb
code_dsc segment_descriptor <0ffffh, 0, 0, 10011010b, 0, 0>
        		; 10011010b - 1001, C/D - 1, 0, R/W - 1, 0
        		; 0         - G - 0, 000, Limit - 0
        ; Дескриптор ресурса, в данном случае – сегмента данных
res_dsc  segment_descriptor <0ffffh, 0, 0, 10010010b, 10001111b, 0>
        		; 10011010b - 1001, C/D - 0, 0, R/W - 1, 0
        		; 10001111b - G - 1, 000, Limit - 1111
       		
; Данные для загрузки в GDTR
gdtr    table_register <$ - GDT - 1, 0>


; Таблица дескрипторов прерываний
IDT     label byte
        db    13 dup (  8 dup (0)) ; 0 – 12
        ; Дескриптор шлюза ловушки, обработчик #GP
        gate_descriptor <intGpf_handler, 8, 0, 8Fh, 0>

; Данные для загрузки в IDTR
idtr    table_register <$ - IDT - 1, 0>

; Место для хранения IDTR реального режима
old_idtr table_register <>  

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Служебные функции
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

; Открывает вентиль A20
open_A20:
        in      al, 92h
        or      al, 2
        out     92h, al
        ret

; Инициализирует GDT
initialize_gdt:
        ; Вычисляем линейный адрес начала массива дескрипторов
        call    cs_to_eax
        add     eax, offset GDT
        ; Записываем его в структуру
        mov     dword ptr gdtr.base, eax

        ; Загружаем GDTR
        lgdt    fword ptr gdtr
        ret

; Инициализирует IDT
initialize_idt:
        ; Вычисляем линейный адрес начала массива дескрипторов
        call    cs_to_eax
        add     eax, offset IDT
        ; Записываем его в структуру
        mov     dword ptr idtr.base, eax

        ; Загружаем GDTR
        lidt    fword ptr idtr
        ret

; Запрещает маскируемые и немаскируемые прерывания
disable_interrupts:
        cli              ; запретить прерывания
        in      al, 70h  ; индексный порт CMOS
        or      al, 80h  ; установка бита 7 в нем запрещает NMI
        out     70h, al
        ret

; Разрешает маскируемые и немаскируемые прерывания
enable_interrupts:
        in      al, 70h  ; индексный порт CMOS
        and     al, 7Fh  ; сброс бита 7 отменяет блокирование NMI
        out     70h, al
        sti              ; разрешить прерывания
        ret

; Устанавливает флаг PE
set_PE:
        mov     eax, cr0 ; прочитать регистр CR0
        or      al, 1    ; установить бит PE,
        mov     cr0, eax ; с этого момента мы в защищенном режиме
        ret

; Сбрасывает флаг PE
clear_PE:
        mov     eax, cr0 ; прочитать CR0
        and     al, 0FEh ; сбросить бит PE
        mov     cr0, eax ; с этого момента мы в реальном режиме
        ret

; Вычисляет линейный адрес начала сгмента кода
cs_to_eax:
        mov     eax, 0
        mov     ax, cs
        shl     eax, 4
        ret

; Прокручивает экран на строчку вверх
upscroll_screen:
        push   eax
        push   ecx
        push   edx

        mov    eax, 0         ; Текущий символ
        mov    ecx, 80 * 24   ; Колическтво символов на экране
                              ; (без последней строки, она отдельно)
screen_loop:
        mov    dx, word ptr es:[eax * 2 + 80*2]
        mov    word ptr es:[eax * 2], dx      ; Меняем символ
        inc    eax
        loop   screen_loop

        mov    ecx, 80        ; Длинна последней строки
        mov    dx,  0720h     ; символ, которым заполняется строка

last_line_loop:
        mov    word ptr es:[eax * 2], dx      ; Меняем символ
        inc    eax
        loop   last_line_loop

        pop    edx
        pop    ecx
        pop    eax
        ret

        end     start

Задания

• Измените поведение обработчика исключения, пусть он не инкрементирует DPL, а декрементирует RPL, т.е. уменьшает на единицу значение регистра ax.
• Реализуйте аналогичный пример для сегмента стека, проверьте необходимость равенства всех трёх значений: CPL, DPL, RPL. Учтите, что после перехода в защищённый режим CPL равен 0, и изменять его вы пока не умеете.

Я один, но это не значит что я одинок..

Виктор Цой

За двумя зайцами погонишься – ни одного не поймаешь

Пословица

Задача главы предельно проста: объяснить, как правильно создать одну задачу (task) и как проинициализировать регистр задачи (Task Register, TR). Это даже почти не глава. Сначала это была маленькая врезка, но когда она неожиданно разрослась до трёх страниц и потребовала отдельного примера, пришлось выделить её в самостоятельную боевую единицу. Но «дотянуть» до честной главы по объёму так и не получилось – как было три страницы, так и осталось, больше просто не о чем писать.

Пример, приведённый в конце, не просто минимальный, а жестоко минимальный.

Заданий нет вообще.

Хуже того. Я даже не буду писать о «зачем» и углубляться в проблематику многозадачности. В данном случае механизм задач интересен не сам по себе, а только как некоторая инфраструктура, которую процессор использует при передаче управления между сегментами кода с различными уровнями привилегий. Поэтому никакой воды, никаких лишних мыслей, рублёный слог, факты, таблицы, диаграммы, код.

Сегмент состояния задачи

Сегмент состояния задачи (task state segment, TSS) содержит «состояние задачи» – некоторые специфичные для задачи данные, определяющие её поведение. Грубо и упрощённо, можно разбить эти данные на две части:

• Значения всех стандартных регистров (EIP, EFLAGS, общего назначения, сегментных) на момент переключения задач. При переключении задач регистры выполняющейся задачи автоматически сохраняются в её TSS, а регистры новой задачи автоматически подгружаются, но уже из её TSS.
• Ещё кое-что :) Пока не важно, в следующих главах разберёмся.

Минимальный размер TSS – 104 байта, именно столько занимает стандартная структура, содержащая все обязательные данные. Поскольку в течение этой главы мы не будем делать с задачами ничего интересного, структура и содержимое TSS пока не имеют значения, то есть он может состоять из 104-х байт абсолютно произвольного содержания. Для простоты, пусть будут нули.

Выглядит это так:

tss_seg   db 104 dup(0)

Дескриптор сегмента состояния задачи

Естественно, сегмент не может существовать без дескриптора. Формат дескриптора сегмента состояния задачи (task state segment descriptor) таков:

На картинке это выглядит так:

Рисунок 1. Формат дескриптора сегмента состояния задачи.

В качестве примера – дескриптор сегмента состояния задачи, размер сегмента 104 байта, базовый адрес 01020304h:

    db      103         ; Segment Limit
    db      0 
    db      4           ; base address
    db      3 
    db      2 
    db      10001001b   ; 1, DPL – 00, S - 0, 1001
    db      0           ; G - 0, 000, Limit - 0
    db      1           ; base address

Или так:

    ; Дескриптор сегмента состояния задачи, 104 байта, базовый адрес 01020304h
    segment_descriptor <103, 0304h, 2h, 10001001b, 0,  1h>

Инициализация

Для того, чтобы корректно инициализировать механизм управления задачами, нужно выполнить три действия:

• Создать сегмент состояния задачи
• Создать для него дескриптор в GDT
• Загрузить селектор этого дескриптора в регистр TR инструкцией ltr (load task register)

Инструкция ltr относится к привилегированным и имеет следующий формат:

		ltr selector

Где selector это 16-ти разрядный регистр или переменная типа dw.

Пример

Замечательный пример, сложностью и объёмом возвращающий нас примерно ко второй главе. Коротенькая инициализация, две инструкции, ради которых всё это затевалось, возврат в реальный режим. Всегда бы так!

; task.asm
; Программа, инициализирующая TR

        .model tiny
        .code
        .386p
        org     100h

;;;;;;;;;;;;;;;;;;;;;;;;;;;        
;
; Структуры
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;

; Сегментный дескриптор
segment_descriptor struct
    limit_low   dw      0    ; Младшие два байта поля Segment limit
    base_low    dw      0    ; Младшие два байта поля Base Address
    base_high0  db      0    ; Второй байт поля Base Address
    type_and_permit db  0    ; Флаги
    flags       db      0    ; Ещё одни флаги
    base_high1  db      0    ; Старший байт поля Base Address
segment_descriptor ends

; Регистр, описывающий таблицу дескриптров
table_register struct
    limit       dw      0    ; Table Limit
    base        dd      0    ; Linear Base Address
table_register ends

;;;;;;;;;;;;;;;;;;;;;;;;;;
;
; Код
;
;;;;;;;;;;;;;;;;;;;;;;;;;;

start:
        ; Подготавливаем DS
        push    cs
        pop     ds

        ; Получаем адрес начала сегмента TSS
        call    cs_to_eax
        add     eax, offset tss_seg

        ; Записываем его в дескриптор
        mov     word ptr tss_dsc.base_low, ax
        shr     eax, 16
        mov     byte ptr tss_dsc.base_high0, al

        ; Инициалиируем GDT
        call initialize_gdt

        call disable_interrupts
        call set_PE

        ; загрузить селектор дескриптора TSS в TR
        mov  ax, 8
        ltr  ax

        call clear_PE
        call enable_interrupts

        ret

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Данные
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

; Глобальная таблица дескрипторов
GDT       label   byte
          ; Нулевой дескриптор
          segment_descriptor <> 
          ; Дескриптор TSS, 104 байта, базовый адрес 0
tss_dsc   segment_descriptor <103, 0, 0, 10001001b, 0,  0>

; Данные для загрузки в GDTR
gdtr      table_register <$ - GDT - 1, 0>

; Сегмент TSS. Можно было его вообще не объявлять и оставить 
; базовый адрес 0, всё равно бы сработало. Но в будущем пригодится. 
tss_seg   db 104 dup(0)

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
;; Служебные функции
;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;

; Инициализирует GDT
initialize_gdt:
        ; Вычисляем линейный адрес начала массива дескрипторов
        call    cs_to_eax
        add     eax, offset GDT
        ; Записываем его в структуру
        mov     dword ptr gdtr.base, eax

        ; Загружаем GDTR
        lgdt    fword ptr gdtr
        ret

; Запрещает маскируемые и немаскируемые прерывания
disable_interrupts:
        cli              ; запретить прерывания
        in      al, 70h  ; индексный порт CMOS
        or      al, 80h  ; установка бита 7 в нем запрещает NMI
        out     70h, al
        ret

; Разрешает маскируемые и немаскируемые прерывания
enable_interrupts:
        in      al, 70h  ; индексный порт CMOS
        and     al, 7Fh  ; сброс бита 7 отменяет блокирование NMI
        out     70h, al
        sti              ; разрешить прерывания
        ret

; Устанавливает флаг PE
set_PE:
        mov     eax, cr0 ; прочитать регистр CR0
        or      al, 1    ; установить бит PE,
        mov     cr0, eax ; с этого момента мы в защищенном режиме
        ret

; Сбрасывает флаг PE
clear_PE:
        mov     eax, cr0 ; прочитать CR0
        and     al, 0FEh ; сбросить бит PE
        mov     cr0, eax ; с этого момента мы в реальном режиме
        ret

; Вычисляет линейный адрес начала сгмента кода
cs_to_eax:
        mov     eax, 0
        mov     ax, cs
        shl     eax, 4
        ret

        end     start

[2B ProGroup 1995] Коллектив авторов «2B ProGroup» (Вегнер В.А., Крутяков А.Ю., Серегин В.В., Сидоров В.А., Спесивцев А.В.) «Аппаратура персональных компьютеров и её программирование. IBM PS/XT/AT и PS/2». Москва, Радио и Связь, 1995. Замечательная книжка, посвященная взаимодействию с различной периферией, в частности, очень подробно и понятно описана работа с ПКП i8259A. Большое спасибо за неё Диме Голубеву.

[Intel 2004] «IA-32 Intel® Architecture Software Developer’s Manual Volume 3: System Programming Guide». http://www.intel.com Официальное руководство от Intel.

[Григорьев 1993] В.Л. Григорьев «Микропроцессор i486. Архитектура и программирование (в 4-х книгах). Книга 1. Программная архитектура». Москва 1993.

[Гук 1999] М. Гук «Процессоры Pentium® II, Pentium® Pro и просто Pentium®», издательство «Питер», 1999 (на данный момент существует более новое издание). Энциклопедия, со всеми вытекающими последствиями: информации много и она хорошо структурирована, но изучать предмет по этой книжке не стоит, поберегите нервные клетки и стены, об которые вы будете ими биться. А вот в качестве справочника – вполне.

[Зубков 1999] С.В. Зубков, «Assembler. Для DOS, Windows, Unix», издательство ДМК, 1999 (на данный момент существует более новое издание). Практически всеобъемлющий труд о программировании на ассемблере, с точки зрения программирования в защищённом режиме ценен, в первую очередь, приведёнными примерами. Остальные авторы на работающие примеры значительно более скупы.

[Орловский 1992] Г.В. Орловский «Введение в архитектуру микропроцессора 80386», Санкт-Петербург, 1992. Неплохое описание защищённого режима процессора Intel386. Написано более-менее понятно, хотя и лаконично – никакой воды, никаких примеров…

Broken Sword, рассылка «Процессор Intel в защищённом режиме» http://www.brokensword.narod.ru, копия есть на http://www.wasm.ru. Понятно и подробно, а, кроме того, живо и абсолютно неакадемично. К сожалению, автор прекратил работу над рассылкой, не дойдя даже до середины.