Инструкция по вызову супервизора

В этой статье рассматриваются конкретные инструкции для мэйнфреймов IBM System / 360 и последующих . Для получения общей концепции инструкции по отправке вызовов операционной системе см. Системный вызов .

Supervisor вызов инструкция ( SVC ) является аппаратной инструкцией в System / 360 семейства мэйнфреймов IBM компьютеров вплоть до современных zSeries (а также без больших ЭВМ , таких как Amdahl 470V / 5, 470V / 6, 470V / 7, 470V / 8, 580, 5880, 5990M и 5990A и другие; Univac 90/60 , 90/70 и 90/80 и, возможно, другие; и Fujitsu M180 (UP) ^[1] и M200 (MP), и другие) используется для прерывания запроса службы от операционной системы . Системная процедура, предоставляющая услугу, называется подпрограммой SVC.. SVC - это конкретная реализация системного вызова .

Обоснование [ править ]

Мэйнфреймы IBM в семействе System / 360 и последующих версиях работают в одном из двух состояний: состояние проблемы или состояние супервизора и с одним из шестнадцати ключей доступа к хранилищу (от 0 до 15). В состоянии проблемы для пользовательской программы доступен большой набор непривилегированных инструкций общего назначения . В состоянии супервизора системные программы дополнительно могут использовать небольшой набор привилегированных инструкций, которые обычно предназначены для контрольных функций. Эти функции могут влиять на других пользователей, другие процессоры или всю компьютерную систему. В ключе хранилища 0 программа может получить доступ ко всем адресуемым ^[a]хранилище, в противном случае оно ограничено областями хранения с совпадающим ключом. Программе разрешен доступ к определенным функциям контроля только после тщательной проверки авторизации операционной системой: DEBCHK (SVC 117), TESTAUTH (SVC 119) и, возможно, дополнительных тестов. Программы, не прошедшие ни один из этих тестов, отключаются, то есть аварийно завершаются и немедленно прекращают обработку. Некоторые из этих тестов не были доступны в OS / 360, но были добавлены в OS / VS1 , SVS или MVS / 370 , но все они были доступны в MVS / 370 или последующих выпусках и доступны по сей день.

В OS / VS1 , OS / VS2 (SVS) , MVS / 370 и последующих версиях ОС функция MODESET (SVC 107) устранила необходимость во многих пользовательских SVC, поскольку этот системный SVC учитывал оба изменения режима (состояние проблемы до состояния супервизора) и ключа (от 8-15 [пользователь] до 0-7 [система]) за одну операцию, и многие написанные пользователем SVC изначально были предназначены для простого режима и ключевых изменений, в любом случае, и впоследствии единственное специальное требование состоял в том, что шаг работы должен быть авторизован APF ^{[b] [c]}и чтобы программа, вызывающая MODESET, была резидентной в конкатенации библиотек, все из которых были идентифицированы как авторизованные, и этот безопасный подход полностью находился под контролем установки. Такой подход в целом упростил пользовательский контроль авторизации, хотя для этого потребовались некоторые простые изменения в приложении. В целом, пользовательские установки предпочитали этот подход, и тем самым была значительно повышена общая надежность системы.

Хотя приложения для мэйнфреймов обычно являются синхронными процессами, сама операционная система по своей природе асинхронна , хотя система также поддерживает многие процессы, которые естественно синхронны . Когда приложение запрашивает системную службу, которая по своей природе является асинхронной., например, обработка ввода / вывода, должен использоваться механизм синхронизации приложения и операционной системы. Этот важный механизм реализуется через функции, которые встроены в операционную систему или специально ею поддерживаются, в том числе: WAIT (временная остановка обработки приложения до тех пор, пока не произойдет внешнее событие); POST (указать возникновение внешнего события, чтобы можно было продолжить обработку приложения); и SYNCH (изменение режима обработки системы - супервизор на пользователя и системный ключ на пользовательский ключ - с сохранением целостности системы и синхронное выполнение функции от имени приложения, после чего обработка супервизора может продолжаться).

В приведенной ниже таблице SVC OS / 360 указаны условия, при которых могут использоваться эти средства синхронизации.

Реализация [ править ]

SVC - это двухбайтовая инструкция с шестнадцатеричным кодом операции 0A ; второй байт инструкции, номер SVC , указывает конкретный запрос. ^[2] Номер SVC может быть любым значением от 0 до 255, причем конкретный номер SVC зависит от разработчика операционной системы, например, в IBM MVS SVC 3 используется для завершения программы, а в UNIVAC VS / 9 и Fujitsu BS2000, SVC 9 использовался с той же целью.

Когда программа выдает SVC, происходит прерывание. PSW, 8-байтовый (в System 360 и S / 370) или 16-байтовый (в z / System), привилегированный регистр, содержащий, среди прочего, текущий адрес инструкции, которая должна быть выполнена, бит привилегии ( 1, если привилегированный), и ключ хранилища сохраняется в абсолютном месте. Это адреса 32-39 на 360 и 370; 320-335 в системе z / System. Затем PSW загружается из другого абсолютного местоположения; это 96-103 на 360 и 370, 448-463 на z / system. Выполнение возобновляется с адреса, который был загружен в PSW. Биты 24–31 сохраненного PSW (абсолютный адрес 35 на 360 и 370, 323 на z / System) содержат номер вызова супервизора.

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

В операционных системах, разработанных IBM, возврат из подпрограммы SVC для подпрограмм SVC типов 2, 3 и 4 осуществляется посредством вызова SVC 3 (EXIT), а для других типов SVC - посредством привилегированной инструкции Load PSW (LPSW), и которая выполняется от имени процедуры SVC диспетчером управляющей программы или обработчиком прерывания SVC.

О не IBM разработала операционные системы , такие как музыка / SP , разработанный Университетом Макгилла в Монреале, Канада для IBM мэйнфреймы, и для не-IBM мэйнфреймы, VS / 9 , разработанный Univac (от ЦОС операционной системы для RCA Spectra 70 серии компьютеры) для линейки мэйнфреймов UNIVAC Series 90 и операционная система B800 (также разработанная на основе операционной системы TSOS ) для мэйнфреймов Fujitsu , все используют инструкцию LPSW для выхода из вызова супервизора.

Выбор того, будет ли вызов супервизора возвращаться в вызывающую программу напрямую через инструкцию LPSW или через какие-либо другие средства, такие как инструкция возврата из подпрограммы или сам вызов супервизора, является делом дизайна. Для этого нет очевидного «права»; у обоих методов могут быть причины. Использование инструкции LPSW для выхода из подпрограммы SVC обеспечивает более быстрое выполнение, но означает, что фактическое тестирование подпрограммы должно выполняться на выделенной машине, на которой выполняется код как часть реального супервизора операционной системы. Если код был написан как обычная подпрограмма, его можно протестировать так же, как и любую обычную программу, и потенциально развернуть без необходимости его модификации. Это также позволит измерить метрики, касающиеся того, сколько времени потребовалось подпрограмме вызова супервизора для выполнения своей задачи.

В MVS / 370 и более поздних версиях ОС точки входа ветвления и ссылки являются альтернативой вызовам SVC для подпрограмм режима супервизора. В MVS / SP V1R3 и более поздних версиях ОС записи программных вызовов (ПК) имеют расширенные SVC для вызова многих контролирующих функций как авторизованными, так и неавторизованными программами; и некоторые функции могут быть вызваны только записями ветви или ПК, например, Start Input / Output . (Это также имеет то преимущество, что операционные системы IBM не запускаются на оборудовании сторонних производителей.)

Различные операционные системы IBM плохо совместимы в конкретных используемых кодах или в службах супервизора, которые могут быть вызваны. Системы VM / 370 и z / VM используют инструкцию DIAG аналогичным образом и оставляют SVC для использования операционными системами, работающими на виртуальных машинах. Большинство SVC OS / 360 поддерживалось для «унаследованных» программ, но некоторые SVC были «расширены» с течением времени.

OS / 360 и последующие системные SVC [ править ]

В OS / 360 и последующих системах номера SVC от 0 до примерно 127 определены IBM, а номера 255 и ниже доступны для использования персоналом системного программирования установки. z / OS изменила это значение на SVC с номерами от 0 до примерно 200 для IBM и 255 вниз для установки, поскольку дополнительные системные службы, в первую очередь для поддержки шифрования / дешифрования, реализовывались IBM с использованием SVC. Подпрограммы SVC должны иметь имена модулей в определенном формате, начинающиеся с IGC.

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

OS / 360 определила четыре типа подпрограмм SVC, которые называются от «Типа 1» до «Типа 4»; MVS / 370 добавил дополнительный «Тип 6», который похож на «Тип 1», за исключением того, что процедура SVC физически отключена. «Тип 5» не был ни определен, ни реализован. Следующая информация, часть таблицы для OS / 360, дополненная для MVS / 370 и последующих систем, дает представление о соображениях, связанных с написанием подпрограммы SVC.

Ограничения размера для подпрограмм SVC типов 3 и 4 необходимы, потому что они загружаются в назначенные «переходные области» (PLPA в post-MVT) при вызове.

• Примером типа 1 является SVC 10, используемый как для GETMAIN, так и для FREEMAIN, который выделяет область оперативной памяти для задачи и, соответственно, для ее освобождения. SVC 10 неофициально известен как «REGMAIN», поскольку он обменивается параметрами только через регистры общего назначения и может как ПОЛУЧАТЬ, так и БЕСПЛАТНО. SVC 4 и SVC 5 могут выполнять аналогичные функции GET и FREE соответственно, но обмениваться параметрами через списки параметров в памяти.
• Примером типа 2 является SVC 42, ATTACH, который создает новую задачу.
• Примером типа 3 является SVC 33, IOHALT, который завершает операции ввода-вывода на устройстве, не поддерживающем DASD. Этот SVC был изменен на тип 2 в OS / VS, поскольку IOHALT широко используется во многих системах на основе телепроцессов.
• Примером типа 4 является SVC 19, OPEN, используемый для предоставления набора данных для использования пользовательской программой, который включает модули, общие для всех методов доступа, и вызывает дополнительные модули, специфичные для каждого метода доступа . OPEN также поддерживает наборы данных, с которыми нужно работать с помощью метода доступа «самостоятельно», например, те, к которым осуществляется доступ с помощью EXCP .
• Примером типа 6 является SVC 107, MODESET, который не получает блокировок, но может изменять системный режим и системный ключ в соответствии с переданными параметрами.

Безопасность [ править ]

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

Начиная с MVS / 370, IBM считала дефектом продукта, если ошибка проектирования системы позволяла прикладной программе войти в состояние супервизора без авторизации. Они потребовали, чтобы все SVC IBM были защищены, чтобы закрыть все угрозы целостности системы и данных. Они «гарантировали» закрытие таких разоблачений, как они были обнаружены. К Выпуску 3.7 MVS / 370 в 1977 году почти каждая такая уязвимость была действительно выявлена ​​и закрыта ценой 100 000 утвержденных отчетов об анализе программ (APAR) и связанных временных исправлений программы (PTF). Это было выдающимся достижением, поскольку после этого «время безотказной работы» системы измерялось годами , а не днями или даже часами .

Заметки [ править ]

Ссылки [ править ]

Дальнейшее чтение [ править ]

• Крагон, Харви Г. (23 августа 2000 г.). Компьютерная архитектура и реализация . Издательство Кембриджского университета. ISBN 9780521651684 - через Google Книги.
• Харрис, Дж. Арчер (21 декабря 2001 г.). Обзор операционных систем Шаума . McGraw Hill Professional. ISBN 9780071394482 - через Google Книги.