Ответ 1

Затвор (вызов, прерывание, задача или ловушка) используется для передачи управления исполнением по сегментам. Проверка уровня привилегий выполняется по-разному в зависимости от типа назначения и используемой инструкции.

В шлюзе вызовов используются инструкции CALL и JMP. Управление передачей вызовов с нижнего кода привилегии на более высокий код привилегии. DPL шлюза используется для определения того, какие уровни привилегий имеют доступ к воротам. Ворота вызова (или, вероятно, постепенно) заброшены в пользу механизма SYSENTER/SYSEXIT, который выполняется быстрее.

Целевые ворота используются для поддержки многозадачности аппаратного обеспечения. Коммутатор аппаратных задач может выполняться добровольно (CALL/JMP для дескриптора ворот задачи) или через прерывание или IRET, когда установлен флаг NT. Он работает одинаково с прерываниями или ловушками. Целевые ворота не используются, насколько мне известно, поскольку ядра обычно требуют дополнительной работы при переключении задачи.

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

Дополнительные сведения см. в руководствах по архитектуре Intel на интересующих вас процессорах.

Update

Чтобы ответить на комментарий:

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

Для простого (но непрактичного) примера, чтобы лучше понять, почему прерывания и ловушки блокируют EFLAGS по-разному, подумайте, что произойдет, если мы будем писать обработчик прерываний для аппаратных событий в однопроцессорной системе, и мы не смогли бы очистить IF бит, пока мы его обслуживали. Возможно, второе прерывание будет достигнуто, пока мы будем заняты первым. Тогда наш обработчик прерываний будет вызываться процессором в какой-то случайной точке во время выполнения IH. Это может привести к повреждению данных, взаимоблокировке или другой плохой магии. Практически прерывание прерывания является одним из механизмов обеспечения того, чтобы ряд операторов ядра обрабатывался как критический раздел.

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

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

Теперь шлюзовые шлюзы действительно используются для обслуживания программных прерываний, исключений и т.д. Ошибка страницы или деление на нулевое исключение в вашем процессоре, вероятно, обрабатывается через ловушку. Простейшим примером использования ловушек для управления выполнением программы является инструкция INT 3, которая используется для реализации контрольных точек в отладчиках. При выполнении виртуализации происходит то, что гипервизор работает в кольце 0, а гостевое ядро ​​обычно находится в кольце 1 - когда привилегированный код будет сбой с общей ошибкой исключения. Witchel и Rosenblum разработали двоичный перевод, который в основном переписывает инструкции для имитации их эффектов. Критические инструкции обнаруживаются и заменяются ловушками. Затем, когда ловушка выполняется, управление передается VMM/гипервизору, который отвечает за эмуляцию критических команд в кольце 0.

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

Для получения дополнительной информации, я предлагаю вам проверить:

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

Надеюсь, это поможет!

Ответ 2

С точки зрения защиты архитектура x86 на основе многоуровневого дизайна, согласно которой все пространство выполнения, поставляемое процессором, разделено на четыре защищенных домена безопасности, каждый из которых имеет свой собственный уровень привилегий. Этот проект предполагает, что большая часть временного кода будет выполнена в наименее привилегированном домене, и иногда будут запрашиваться услуги из более привилегированного домена безопасности, и эти службы будут вытеснять менее привилегированные действия в стек, а затем восстановить их таким образом, чтобы все предпосылки будут невидимы для менее привилегированного кода. Проект с многоуровневой защитой утверждает, что управление не может быть передано произвольно между различными доменами безопасности. Ворота - это функция архитектуры x86 для управления передачей от менее привилегированного сегмента кода к более привилегированному сегменту кода, но не наоборот. Более того, точка в менее привилегированном сегменте, от которого будет передаваться управление, может быть произвольной, но строго указано в более привилегированном сегменте, где будет передаваться элемент управления. Переход назад к менее привилегированному сегменту допускается только с помощью инструкции iret. В этом отношении руководство разработчика Intel Software заявляет:

"Code modules in lower privilege segments can only access modules operating at 
higher privilege segments by means of a tightly controlled and protected inter-
face called a gate. Attempts to access higher privilege segments without going 
through a protection gate and without having sufficient access rights causes a 
general-protection exception (#GP) to be generated."

Другими словами, ворота являются более привилегированной точкой входа в домен, с требуемыми правами доступа и указанным адресом назначения. Таким образом, все ворота аналогичны и используются практически для тех же целей, и все дескрипторы ворот содержат поле DPL, которое используется процессором для контроля прав доступа. Но обратите внимание: процессор проверяет DPL затвора только в том случае, если источником вызова является программное обеспечение (вызов, jmp, инструкция int выполняется) и обход этой проверки, когда источником вызова является аппаратное обеспечение. Несмотря на то, что все ворота подобны, у них есть некоторые отличия, потому что первоначально инженеры Intel полагали, что разные ворота будут использоваться для разных целей. Пусть описываются ворота и их отличия:

1) Задание. Может храниться только в IDT и GDT и вызывается командой int. Это особый тип ворот, который значительно отличается от всех остальных. Первоначально инженеры Intel думали, что они будут революционизировать многозадачность, предоставляя функцию, основанную на процессоре для переключения задач. Они внедрили TSS (сегмент состояния задачи), которые содержат состояние регистров задачи и могут использоваться для переключения аппаратных задач. Существует два способа запуска переключения аппаратных задач: использование самого TSS и использование Task Gate. Чтобы выполнить аппаратный переключатель задач, вы можете использовать команды вызова или jmp. Если я правильно понял, основной причиной введения ворот задачи было желание иметь возможность запускать аппаратный переключатель задач в ответ на приход прерывания, поскольку аппаратный вызов задачи не может быть вызван путем перехода к селектору TSS. В действительности, никто не использует его, и даже никто не использует функцию переключения аппаратного контекста вообще. В реальном мире эта функция не является оптимальной с точки зрения производительности и не подходит для использования. Например, принимая во внимание, что TSS может быть сохранен только в GDT, а длина GDT не может быть больше 8192, у нас не может быть больше 8 тыс. Задач с аппаратной точки зрения.

2) Trap Gate. Может храниться только в IDT и вызывается командой int. Его можно рассматривать как базовый тип ворот. Он просто передает управление конкретному адресу, указанному в дескрипторе ловушки ловушки, в более привилегированном сегменте и не более того. Трап-ворота активно используются для разных целей, которые могут включать:

• реализация системного вызова (например, Linux использует int 0x80, а Windows использует int 0x2E для этих целей)
• реализация обработки исключений (у нас нет причин отключать прерывания в случае исключения).
• реализация обработки прерываний на машинах с APIC (мы можем лучше контролировать стек ядра).

3) Ворота прерывания. Может храниться только в IDT и вызывается командой int. Это то же самое, что и ловушка-ловушка, но, кроме того, вызов вызова прерывания дополнительно запрещает прием будущих прерываний путем автоматической очистки флага ЕС в регистре EFLAGS. Ворота прерывания активно используются для обработки прерываний, особенно на машинах на базе ПОС. Причина - требование контролировать глубину стека. У ПИК нет функции приоритетов источников прерываний. Из-за этого по умолчанию PIC отключает только прерывание, которое уже обрабатывается процессором. Но другие прерывания все еще могут прибыть посередине и вытеснять обработку прерываний. Таким образом, в тот же момент в стек ядра может быть 15 обработчиков прерываний. В результате разработчики ядра вынуждали либо значительно увеличить размер стека ядра, что приводит к штрафу памяти, либо быть готовым столкнуться со спорадическим переполнением стека ядра. Interrupt Gate может гарантировать, что только один обработчик может быть в стек ядра одновременно.

4) Вызов ворот. Может храниться в GDL и LDT и вызывается с помощью команд вызова и jmp. Подобно ловушке ловушки, но, кроме того, может передавать количество параметров из стека задач пользовательского режима в стек задачи режима ядра. Количество переданных параметров указывается в дескрипторе ворот вызова. Ворота вызова никогда не пользовались популярностью. Для этого есть несколько причин:

• Их можно заменить ловушками (Occam Razor).
• Они не переносят много. Другие процессоры не имеют сходной функции. Это означает, что поддержка вызовов для системного вызова означает, что при переносе операционной системы на другой процессор необходимо перезаписать код.
• Они не слишком гибкие, из-за того, что количество параметров, которые могут быть переданы между стеками, ограничено.
• Они не оптимальны с точки зрения производительности.

Кроме того, в конце 1990-х годов Intel и AMD представили еще одну возможность реализации системного вызова, которая в отличие от ворот вызова обеспечивает достаточно хорошие преимущества. Это пара инструкций sysenter/sysexit и syscall/sysret для Intel и AMD соответственно. И в отличие от шлюзов вызова, эти функции широко использовались в операционных системах.

Я не согласен с Майклом Фукаракисом. Sory, но нет никаких различий между прерываниями и ловушками, кроме влияния на флаг IF.

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

2) Любой тип затвора (включая прерывание, ловушку и задачу) можно вызвать в программном обеспечении с помощью команды int. Единственной функцией, которая может запрещать доступ к коду доступа к конкретному затвору, является DPL. Например, когда операционная система строит IDT, независимо от типов конкретных ворот, настройка DPL ядра для ворот, которая будет использоваться для обработки событий adware до 0 и в соответствии с этим доступом к этим затворам, будет разрешена только из пространства ядра (который работает в большинстве привилегированных доменов), но когда он устанавливает ворота для системного вызова, он устанавливает DPL на 3, чтобы разрешить доступ к этому затвору из любого кода. В результате задача пользовательского режима может выполнять системный вызов с помощью gate с DPL = 3, но, к примеру, поймает ошибку общей защиты при попытке вызвать обработчик прерываний клавиатуры.

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

4) Аналогичным образом, ворота любого типа в IDT можно вызвать в программном обеспечении. Причина использования ловушек для системного вызова и исключений проста. Нет никаких причин для отключения прерываний. Отключение прерывания - это плохо, потому что он увеличивает задержки обработки прерываний и увеличивает вероятность потери прерывания. Из-за этого никто не будет отключать их без какой-либо серьезной причины на руках.

5) Обработчик прерываний обычно записывается в строгом реентерабельном стиле. Таким образом, обработчики прерываний обычно не имеют данных и могут прозрачно вытеснять друг друга. Даже когда нам необходимо взаимно исключить одновременный доступ к данным в обработчике прерываний, мы можем защитить только доступ к общим данным с помощью команд cli и sti. Нет никакой причины рассматривать весь обработчик прерываний как критический раздел. Нет никаких причин использовать прерывистые ворота, кроме желания предотвратить возможное переполнение стека ядра в системах на базе ПОС.

Итак, в итоге, шлюзы-ловушки - это решение по умолчанию для взаимодействия с ядром. Ворота прерывания могут использоваться вместо ловушки, если есть какая-то серьезная причина для этого.

Ответ 3

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