Защитное кольцо
Из Википедии, свободной энциклопедии
  (Перенаправлено из Ring 0 (компьютерная безопасность) )
Перейти к навигации Перейти к поиску
Чтобы узнать о других значениях, см. Кольцо .
«Кольцо ноль» перенаправляется сюда. Для других целей см. кольцо 0 .

Кольца привилегий для x86 доступны в защищенном режиме

В компьютерных науках иерархические домены защиты [ 1 ] [2] , часто называемые кольцами защиты , представляют собой механизмы защиты данных и функций от сбоев (путем повышения отказоустойчивости ) и вредоносного поведения (путем обеспечения компьютерной безопасности ).

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

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

Реализации

Множественные кольца защиты были одной из самых революционных концепций, представленных в операционной системе Multics , высокозащищенной предшественнице современного семейства операционных систем Unix . У мейнфрейма GE 645 был некоторый аппаратный контроль доступа, но этого было недостаточно для полной аппаратной поддержки колец, поэтому Multics поддерживала их, перехватывая переходы колец в программном обеспечении; [3] его преемник, Honeywell 6180 , реализовал их аппаратно с поддержкой восьми колец. [4] Однако большинство систем общего назначения используют только два кольца, даже если аппаратное обеспечение, на котором они работают, обеспечивает больше режимов ЦП.чем это. Например, Windows 7 и Windows Server 2008 (и их предшественники) используют только два кольца, с кольцом 0 , соответствующий режим ядра и кольца 3 в пользовательском режиме , [5] , потому что более ранние версии Windows , работали на процессорах , которые поддерживают только два уровня защиты . [6]

Многие современные архитектуры ЦП (включая популярную архитектуру Intel x86 ) включают некоторую форму кольцевой защиты, хотя операционная система Windows NT , например Unix, не использует эту функцию в полной мере. В некоторой степени OS/2 использует три кольца: [7] кольцо 0 для кода ядра и драйверов устройств, кольцо 2 для привилегированного кода (пользовательские программы с разрешениями на доступ к вводу-выводу) и кольцо 3 для непривилегированного кода (почти все пользовательские программы) . программы). В DOS ядро, драйверы и приложения обычно работают в кольце 3 (однако это относится только к случаю, когда используются драйверы защищенного режима и/или расширители DOS; в ОС реального режима система работает практически без защиты). ), тогда как 386 менеджеров памяти, таких какEMM386 работает в кольце 0. В дополнение к этому, EMM386 3.xx DR-DOS может дополнительно запускать некоторые модули (такие как DPMS ) вместо этого в кольце 1. OpenVMS использует четыре режима, которые называются (в порядке уменьшения привилегий) Kernel, Executive, Supervisor и User.

Обновленный интерес к этой конструкции структуры пришел с распространением на Xen VMM программного обеспечения, продолжается обсуждение на монолитном против микро-ядрах ( в частности , в Usenet телеконференции и веб - форумах ), Microsoft, Ring-1 конструкция структура в рамках своей NGSCB инициативы и гипервизоры на основе виртуализации x86, такие как Intel VT-x (ранее Vanderpool).

В исходной системе Multics было восемь колец, но во многих современных системах их меньше. Аппаратное обеспечение всегда знает о текущем кольце потока выполнения инструкций с помощью специального машинного регистра. В некоторых системах областям виртуальной памяти вместо этого аппаратно назначаются кольцевые номера. Одним из примеров является Data General Eclipse MV/8000 , в котором три старших бита счетчика программ (PC) служили кольцевым регистром. Таким образом, код, выполняемый с виртуальным ПК, установленным, например, на 0xE200000, автоматически окажется в кольце 7, а вызов подпрограммы в другом разделе памяти автоматически вызовет кольцевую передачу.

Аппаратное обеспечение строго ограничивает способы передачи управления от одного кольца к другому, а также налагает ограничения на типы доступа к памяти, которые могут выполняться между кольцами. Используя в качестве примера x86, существует специальная структура шлюза [ требуется уточнение ] , на которую ссылается инструкция вызова , которая передает управление безопасным способом [ требуется разъяснение ] к предопределенным точкам входа в кольца более низкого уровня (более надежные); это работает как вызов супервизораво многих операционных системах, использующих кольцевую архитектуру. Аппаратные ограничения предназначены для ограничения возможности случайного или злонамеренного нарушения безопасности. Кроме того, самому привилегированному кольцу могут быть предоставлены специальные возможности (такие как адресация реальной памяти в обход оборудования виртуальной памяти).

Архитектура ARM версии 7 реализует три уровня привилегий: приложение (PL0), операционная система (PL1) и гипервизор (PL2). Необычно то, что уровень 0 (PL0) является наименее привилегированным, а уровень 2 — наиболее привилегированным. [8] ARM версии 8 реализует четыре уровня исключений: приложение (EL0), операционная система (EL1), гипервизор (EL2) и защищенный монитор/прошивка (EL3), для AArch64 [9] : D1-2454  и AArch32. [9] : G1-6013 

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

Эффективное использование кольцевой архитектуры требует тесного взаимодействия между оборудованием и операционной системой [ почему? ] . Операционные системы, предназначенные для работы на нескольких аппаратных платформах, могут лишь ограниченно использовать кольца, если они не присутствуют на каждой поддерживаемой платформе. Часто модель безопасности упрощается до «ядра» и «пользователя», даже если аппаратное обеспечение обеспечивает более точную детализацию с помощью колец.

Режимы

Режим супервизора

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

Режим супервизора — это «режим выполнения на некоторых процессорах, который позволяет выполнять все инструкции, включая привилегированные инструкции. Он также может предоставлять доступ к другому адресному пространству, аппаратному обеспечению управления памятью и другим периферийным устройствам. обычно бегает». [10]

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

Несколько примеров из мира ПК:

  • Linux , macOS и Windows — это три операционные системы, в которых используется режим супервизора/пользователя. Для выполнения специализированных функций код пользовательского режима должен выполнить системный вызов в режиме супервизора или даже в пространство ядра, где доверенный код операционной системы выполнит необходимую задачу и вернет выполнение обратно в пространство пользователя. Дополнительный код может быть добавлен в пространство ядра с помощью загружаемых модулей ядра , но только пользователем с необходимыми разрешениями, поскольку этот код не подлежит контролю доступа и ограничениям безопасности пользовательского режима.
  • DOS (пока не загружен диспетчер памяти 386, такой как EMM386 ), а также другие простые операционные системы и многие встроенные устройства постоянно работают в режиме супервизора, что означает, что драйверы могут быть написаны непосредственно как пользовательские программы.

Большинство процессоров имеют как минимум два разных режима. Процессоры x86 имеют четыре разных режима, разделенных на четыре разных кольца. Программы, работающие в кольце 0, могут делать с системой все, что угодно, а код, работающий в кольце 3, должен иметь возможность дать сбой в любой момент без воздействия на остальную часть компьютерной системы . Кольцо 1 и кольцо 2 используются редко, но могут быть настроены с разными уровнями доступа.

В большинстве существующих систем переключение из пользовательского режима в режим ядра сопряжено с большими потерями производительности. По базовым запросам было измерено, что getpidна большинстве машин это стоит 1000–1500 циклов. Из них около 100 предназначены для фактического переключения (70 из пространства пользователя в пространство ядра и 40 обратно), остальные — «накладные расходы ядра». [11] [12] В микроядре L3 минимизация этих накладных расходов снизила общую стоимость примерно до 150 циклов. [11]

Морис Уилкс писал: [13]

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

Для повышения производительности и детерминизма некоторые системы помещают функции, которые, скорее всего, будут рассматриваться как логика приложения, а не как драйверы устройств, в режим ядра; в качестве примеров приводятся приложения безопасности ( управление доступом , брандмауэры и т. д.) и мониторы операционной системы. По крайней мере, одна встроенная система управления базами данных, e X treme DB Kernel Mode , была разработана специально для развертывания в режиме ядра, чтобы предоставить локальную базу данных для функций приложений на основе ядра и исключить переключения контекста , которые в противном случае происходили бы при взаимодействии функций ядра. с системой баз данных, работающей в пользовательском режиме. [14]

Функции также иногда перемещаются по кольцам в другом направлении. Ядро Linux, например, внедряет раздел vDSO в процессы, содержащие функции, которые обычно требуют системного вызова, т. е. кольцевого перехода. Но вместо системного вызова эти функции используют статические данные, предоставляемые ядром, что устраняет необходимость в кольцевом переходе, который легче, чем системный вызов. Функция gettimeofday может быть предоставлена ​​таким образом.

Режим гипервизора

Последние процессоры Intel и AMD предлагают инструкции по виртуализации x86 для гипервизора , чтобы управлять доступом к оборудованию Ring 0. Хотя они взаимно несовместимы, как Intel VT-x (кодовое название «Vanderpool»), так и AMD-V (кодовое название «Pacifica») создают новое «кольцо −1», так что гостевая операционная система может выполнять операции кольца 0 изначально, не затрагивая другие. гостей или хост-ОС.

Чтобы помочь виртуализации, VT-x и SVM вставляют новый уровень привилегий под кольцом 0. Оба добавляют девять новых инструкций машинного кода, которые работают только в «кольце -1», предназначенных для использования гипервизором. [15]

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

Основная статья: привилегия (вычисления)

Уровень привилегий в наборе инструкций x86 контролирует доступ программы, работающей в данный момент на процессоре, к таким ресурсам, как области памяти, порты ввода-вывода и специальные инструкции. Существует 4 уровня привилегий, начиная от 0 (наиболее привилегированный) и заканчивая 3 (наименее привилегированный). Большинство современных операционных систем используют уровень 0 для ядра/исполнительной системы и уровень 3 для прикладных программ. Любой ресурс, доступный для уровня n, также доступен для уровней от 0 до n, поэтому уровни привилегий представляют собой кольца. Когда процесс с меньшими привилегиями пытается получить доступ к процессу с более высокими привилегиями, ОС сообщает об исключении общей ошибки защиты .

Нет необходимости использовать все четыре уровня привилегий. Текущие операционные системы с широкой долей рынка, включая Microsoft Windows , macOS , Linux , iOS и Android, в основном используют механизм пейджинга только с одним битом для указания уровня привилегий как супервизора или пользователя (бит U/S). Windows NT использует двухуровневую систему. [16] Программы реального режима в 8086 выполняются на уровне 0 (самый высокий уровень привилегий), тогда как в виртуальном режиме в 8086 все программы выполняются на уровне 3. [17]

Потенциальное будущее использование нескольких уровней привилегий, поддерживаемых семейством x86 ISA, включает контейнеризацию и виртуальные машины . Ядро операционной системы хоста может использовать инструкции с полным доступом к привилегиям ( режим ядра ), тогда как приложения, работающие в гостевой ОС на виртуальной машине или в контейнере, могут использовать самый низкий уровень привилегий в пользовательском режиме. Виртуальная машина и ядро ​​гостевой ОС сами могут использовать промежуточный уровень привилегий инструкций для вызова и виртуализации операций режима ядра, таких как системные вызовы, с точки зрения гостевой операционной системы. [18]

IOPL

Флаг IOPL ( уровень привилегий ввода/вывода ) присутствует на всех процессорах x86 , совместимых с IA-32 . Он занимает биты 12 и 13 в регистре FLAGS . В защищенном и длинном режимах он показывает уровень привилегий ввода/вывода текущей программы или задачи. Текущий уровень привилегий (CPL) (CPL0, CPL1, CPL2, CPL3) задачи или программы должен быть меньше или равен IOPL, чтобы задача или программа могла получить доступ к портам ввода-вывода .

IOPL можно изменить с помощью POPF(D)и IRET(D)только тогда, когда текущий уровень привилегий равен Ring 0.

Помимо IOPL, разрешения порта ввода-вывода в TSS также участвуют в определении способности задачи получить доступ к порту ввода-вывода.

Разное

В системах x86 аппаратная виртуализация x86 ( VT-x и SVM ) упоминается как «кольцо -1», режим управления системой упоминается как «кольцо -2», Intel Management Engine и процессор безопасности платформы AMD иногда упоминаются как «кольцо −3». [19]

Использование аппаратных функций

Многие аппаратные архитектуры ЦП обеспечивают гораздо большую гибкость, чем та, которую используют операционные системы, с которыми они обычно работают. Правильное использование сложных режимов ЦП требует очень тесного взаимодействия между операционной системой и ЦП и, таким образом, имеет тенденцию привязывать ОС к архитектуре ЦП. Когда ОС и ЦП специально разработаны друг для друга, это не проблема (хотя некоторые аппаратные функции могут оставаться неиспользованными), но когда ОС спроектирована так, чтобы быть совместимой с несколькими различными архитектурами ЦП, большая часть функции режима ЦП могут игнорироваться ОС. Например, причина, по которой Windows использует только два уровня (кольцо 0 и кольцо 3), заключается в том, что некоторые аппаратные архитектуры, которые поддерживались в прошлом (такие как PowerPC или MIPS) реализовано только два уровня привилегий. [5]

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

ошибки и исключения на одном уровне привилегий могут дестабилизировать только уровни привилегий с более высокими номерами. Таким образом, сбой в кольце 0 (режим ядра с наивысшими привилегиями) приведет к сбою всей системы, а сбой в кольце 2 повлияет только на кольца 3 и далее и самое большее на кольцо 2.

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

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

Смотрите также

  • Вызов шлюза (Intel)
  • Сегментация памяти
  • Защищенный режим  — доступен на x86-совместимых процессорах 80286 и новее.
  • IOPL (директива CONFIG.SYS) — директива OS/2 для запуска кода DLL на кольце 2, а не на кольце 3.
  • Дескриптор сегмента
  • Инструкции по вызову супервайзера
  • Режим управления системой (SMM)
  • Принцип наименьших привилегий

использованная литература

  1. ^ Каргер, Пол А .; Герберт, Эндрю Дж. (1984). «Архитектура с расширенными возможностями для поддержки безопасности решетки и отслеживаемости доступа». Симпозиум IEEE 1984 года по безопасности и конфиденциальности . п. 2. doi : 10.1109/SP.1984.10001 . ISBN 0-8186-0532-4. S2CID  14788823 .
  2. ^ Биндер, В. (2001). «Проектирование и реализация ядра мобильного агента J-SEAL2». Труды Симпозиума 2001 г. по приложениям и Интернету . стр. 35–42. doi : 10.1109/SAINT.2001.905166 . ISBN 0-7695-0942-8. S2CID  11066378 .
  3. ^ «Аппаратная архитектура для реализации защитных колец» . Проверено 27 сентября 2012 г.
  4. ^ "Глоссарий Multics - кольцо" . Проверено 27 сентября 2012 г.
  5. ^ Б Russinovich, Mark E .; Дэвид А. Соломон (2005). Внутреннее устройство Microsoft Windows (4-е изд.). Майкрософт Пресс. стр.  16 . ISBN 978-0-7356-1917-3.
  6. ^ Руссинович, Марк (2012). Внутреннее устройство Windows, часть 1. 6-е изд . Редмонд, Вашингтон: Microsoft Press. п. 17. ISBN 978-0-7356-4873-9. Причина, по которой Windows использует только два уровня, заключается в том, что некоторые аппаратные архитектуры, которые поддерживались в прошлом (например, Compaq Alpha и Silicon Graphics MIPS ), реализовывали только два уровня привилегий.
  7. ^ «Справочник по драйверам презентационных устройств для OS / 2 - 5. Введение в драйверы презентационных устройств OS / 2» . Архивировано из оригинала 15 июня 2015 года . Проверено 13 июня 2015 г.
  8. ^ Справочное руководство по архитектуре ARM, выпуск ARMv7-A и ARMv7-R . ООО "Арм" с. Б1-1136.
  9. ^ a b Справочное руководство по архитектуре Arm Armv8, для архитектуры A-профиля . Арм ООО
  10. ^ "режим супервизора" . ФОЛДОК . 15 февраля 1995 г.
  11. ^ б Йохен Лидтке . О конструкции µ-ядра , Proc. 15-й симпозиум ACM по принципам операционных систем (SOSP) , декабрь 1995 г.
  12. ^ Ousterhout, JK 1990. Почему операционные системы не становятся быстрее, чем аппаратное обеспечение? Летняя конференция Usenix, Анахайм, Калифорния, стр. 247–256.
  13. ↑ Морис Уилкс (апрель 1994 г.). «Операционные системы в меняющемся мире». Обзор операционных систем ACM SIGOPS . 28 (2): 9–21. дои : 10.1145/198153.198154 . ISSN 0163-5980 . S2CID 254134 .  
  14. ^ Горин, Андрей и Криволапов, Александр. «Базы данных режима ядра: технология СУБД для высокопроизводительных приложений» , журнал доктора Добба , май 2008 г.
  15. ^ Дорнан, Энди (1 ноября 2005). «Intel VT против AMD Pacifica» . CMP. Архивировано из оригинала 30 мая 2013 года . Проверено 11 ноября +2012 .
  16. ^ Руссинович, Марк Э .; Дэвид А. Соломон (2005). Внутреннее устройство Microsoft Windows (4-е изд.). Майкрософт Пресс. стр. 16. ISBN 978-0-7356-1917-3 
  17. ^ Сунил Матур, «Микропроцессор 8086: архитектура, программирование и взаимодействие», издание Eastern Economy, PHI Learning
  18. ^ Андерсон, Томас; Далин, Майкл (21 августа 2014 г.). "2.2". Операционные системы: принципы и практика (2-е изд.). Рекурсивные книги. ISBN 978-0985673529.
  19. ^ Гелас, Йохан Де. «Аппаратная виртуализация: гайки и болты» . www.anandtech.com . Проверено 13 марта 2021 г.
  • Справочник программиста Intel 80386

дальнейшее чтение

  • Дэвид Т. Роджерс (июнь 2003 г.). «Структура динамической подрывной деятельности» (PDF) .
  • Уильям Дж. Каэлли (2002). «Повторное изучение «надежных систем» в эпоху НИИП: уроки прошлого для будущего» (PDF) .
  • Харуна Р. Иса; Уильям Р. Шокли; Синтия Э. Ирвин (1999). «Многопоточная архитектура для многоуровневой безопасной обработки транзакций» (PDF) .
  • Иван Келли (8 мая 2006 г.). «Перенос MINIX на Xen» (PDF) . Архивировано из оригинала (PDF) 27 августа 2006 г.
  • Пол Бархэм; Борис Драгович; Кейр Фрейзер; Стивен Хэнд; Тим Харрис; Алекс Хо; Рольф Нойгебауэр; Ян Пратт; Эндрю Уорфилд (2003). «Зен и искусство виртуализации» (PDF) .
  • Маркус Пейнадо; Юйцюнь Чен; Пол Англия; Джон Манферделли. «NGSCB: надежная открытая система» (PDF) . Архивировано из оригинала (PDF) 4 марта 2005 г.
  • Майкл Д. Шредер ; Джером Х. Зальццер (1972). «Аппаратная архитектура для реализации защитных колец» .
  • «Руководство разработчика программного обеспечения для архитектуры Intel, том 3: системное программирование (номер заказа 243192)» (PDF) . Глава 4 «Защита»; раздел 4.5 «Уровни привилегий». Архивировано из оригинала (PDF) 19 февраля 2009 г.
  • Ци-кер Чиуэ; Ганеш Венкитачалам; Прашант Прадхан (1999). «Интеграция защиты сегментации и пейджинга для безопасных, эффективных и прозрачных расширений программного обеспечения» . Глава 3: Аппаратные функции защиты в архитектуре Intel X86; раздел 3.1 Проверки защиты.
  • Такахиро Синагава; Кенджи Коно; Такаши Масуда (17 мая 2000 г.). «Использование механизма сегментации для защиты от вредоносного мобильного кода» (PDF) . Глава 3 Реализация; раздел 3.2.1 Кольцевая защита. Архивировано из оригинала (PDF) 10 августа 2017 года . Проверено 2 апреля 2018 .
  • Боберт, Уильям Эрл; Р. Каин (1985). Практическая альтернатива иерархическим политикам честности . 8-я Национальная конференция по компьютерной безопасности.
  • Горин, Андрей; Криволапов, Александр (май 2008 г.). «Базы данных в режиме ядра: технология СУБД для высокопроизводительных приложений» . Журнал доктора Добба .
Получено с " https://en.wikipedia.org/w/index.php?title=Protection_ring&oldid=1067553309 "
Contribute a better translation