Кольца защиты

Ко́льца защи́ты (англ. protection rings, также англ. hierarchical protection domains) — это механизмы в компьютерных системах, предназначенные для защиты данных и функциональности от сбоев (путём повышения отказоустойчивости) и злонамеренного поведения (путём обеспечения компьютерной безопасности)[1][2].

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

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

В отменённой архитектуре Intel англ. X86S, анонсированной в 2024 году, были предусмотрены только кольцо 0 и кольцо 3; кольца 1 и 2 предполагалось убрать, так как современные операционные системы не используют их[3][4].

undefined

История

В 1980-е годы концепция колец защиты, унаследованная от операционной системы Multics, получила аппаратную реализацию в массовых микропроцессорах и стала фундаментальным элементом архитектуры многозадачных операционных систем.

Ключевым событием стало появление в 1982 году 16-битного процессора Intel 80286, в котором впервые в семействе x86 был реализован защищённый режим (англ. protected mode)[5]. Этот режим ввёл четырёхуровневую систему привилегий (кольца от 0 до 3)[6]:

  • Кольцо 0 (англ. Ring 0) — самый привилегированный уровень, предназначенный для ядра операционной системы с полным доступом к ресурсам компьютера[7].
  • Кольца 1 и 2 (англ. Rings 1, 2) — промежуточные уровни для системных служб и драйверов устройств[8].
  • Кольцо 3 (англ. Ring 3) — наименее привилегированный уровень для пользовательских приложений[8].

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

В 1985 году Intel 80386, первый 32-битный процессор в линейке, усовершенствовал механизмы защиты[9]. Ключевым нововведением стала страничная организация памяти (англ. paging), которая работала совместно с сегментацией и кольцами защиты, позволяя реализовывать более гибкие и эффективные схемы виртуальной памяти[10].

Несмотря на наличие четырёх аппаратных колец, большинство операционных систем того времени не использовали эту модель полностью. Системы семейства UNIX, а впоследствии и Linux, приняли упрощённую двухуровневую модель: ядро работало в кольце 0, а все пользовательские процессы — в кольце 3[7]. Это было обусловлено стремлением к кросс-платформенной совместимости (многие другие архитектуры имели только два уровня привилегий) и соображениями производительности[11]. Заметным исключением стала OS/2, которая использовала трёхуровневую модель: кольцо 0 для ядра, кольцо 2 для привилегированных служб с доступом к вводу-выводу и кольцо 3 для приложений[12]. Концепция многоуровневой защиты также применялась в компьютерах VAX от Digital Equipment Corporation под управлением ОС VMS, где было четыре режима привилегий (Kernel, Executive, Supervisor, User), что подтверждает её статус как общей черты передовых систем той эпохи[13].

Реализации

Большинство современных операционных систем используют только два кольца защиты, даже если аппаратная архитектура, такая как x86, поддерживает больше режимов. Как правило, ядро работает на самом привилегированном уровне (кольцо 0), а пользовательские приложения — на наименее привилегированном (кольцо 3). Промежуточные кольца 1 и 2 остаются незадействованными. Такое решение упрощает архитектуру ОС и обеспечивает её переносимость на платформы, которые аппаратно поддерживают только два уровня привилегий[14].

  • Windows: Современные версии, включая Windows 10, Windows 11 и Windows Server 2022, продолжают использовать двухуровневую модель: кольцо 0 для режима ядра (англ. Kernel Mode) и кольцо 3 для пользовательского режима (англ. User Mode)[12]. Однако с появлением технологии безопасности на основе виртуализации (англ. Virtualization-Based Security, VBS) была добавлена дополнительная ступень изоляции. VBS использует гипервизор Hyper-V для создания защищённой среды, которая функционирует на более привилегированном уровне, чем ядро ОС. Этот уровень условно называют «кольцом -1» или уровнем доверия виртуализации (англ. Virtualization Trust Level, VTL)[15]. В такой конфигурации гипервизор работает на уровне VTL0, а ядро основной ОС — на менее привилегированном уровне VTL1. Это позволяет реализовать такие функции, как Целостность памяти (англ. HVCI) и Credential Guard[15].
  • Linux: Ядро Linux на архитектуре x86-64 также придерживается модели с двумя уровнями: кольцо 0 для ядра и драйверов, и кольцо 3 для всех пользовательских процессов[16]. Это обусловлено соображениями производительности и переносимости[17]. Как и в Windows, технологии виртуализации (например, KVM) создают более привилегированный «кольцо -1» для работы гипервизора. Кроме того, для усиления защиты в ядре Linux (начиная с версии 5.4) был введён режим «lockdown», который, будучи активированным, ограничивает даже права суперпользователя (root) на изменение кода работающего ядра, предотвращая атаки на самом высоком уровне ОС[18].
  • macOS: Архитектура защиты в macOS зависит от аппаратной платформы. На компьютерах Mac с процессорами Intel используется та же двухуровневая модель, что и в Linux/Windows: ядро XNU работает в кольце 0, а приложения — в кольце 3[19]. На компьютерах с Apple silicon (архитектура ARM64) концепция колец заменена уровнями исключений (англ. Exception Levels, EL)[20]:
    • EL0**: Пользовательский режим (приложения).
    • EL1**: Режим ядра (ядро XNU).
    • EL2**: Режим гипервизора.
    • EL3**: Режим безопасного монитора (англ. Secure Monitor) — самый привилегированный уровень, отвечающий за безопасную загрузку и изоляцию.

Помимо этого, безопасность macOS в значительной степени опирается на программно-аппаратные комплексы, такие как System Integrity Protection (SIP) и Secure Enclave[21].

  • OS/2: В отличие от большинства систем, OS/2 частично применяла три кольца: 0 для ядра и драйверов, 2 для привилегированных программ (имеющих доступ к портам ввода-вывода) и 3 для непривилегированных пользовательских приложений[22].
  • Xen: Является активно развивающимся гипервизором 1-го типа, работающим непосредственно на аппаратном обеспечении («голое железо») в кольце 0[23]. Его архитектура предусматривает привилегированную управляющую виртуальную машину (англ. Domain 0, Dom0), которая отвечает за администрирование системы, в то время как гостевые ОС (англ. Domain U, DomU) работают в изолированных, непривилегированных окружениях. Такая модель используется в облачных платформах, корпоративной виртуализации и системах с повышенными требованиями к безопасности, таких как Qubes OS[24].
  • NGSCB (англ. Palladium): Эта инициатива Microsoft начала 2000-х годов по созданию доверенной вычислительной среды не была реализована в первоначальном виде и считается устаревшей[25]. Однако её ключевые идеи — использование аппаратной поддержки для изоляции критически важных процессов — получили развитие в современной технологии Virtualization-Based Security (VBS)[15].
  • Multics: В этой новаторской операционной системе, предшественнице Unix, была реализована концепция восьми иерархических колец. На раннем этапе (мэйнфрейм GE 645) переключение между кольцами частично эмулировалось программно[26], но уже в преемнике, Honeywell 6180, восемь колец были реализованы аппаратно[27].
  • OpenVMS: В этой системе используются четыре режима привилегий: ядро, исполнительный, супервизорский и пользовательский (в порядке убывания привилегий).
undefined

Режимы

Супервизорский режим

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

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

В монолитных ядрах ОС работает в супервизорском режиме, приложения — в пользовательском. В других типах ОС (напр. exokernel, микроядро) такой связи может не быть.

Примеры:

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

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

В большинстве существующих систем переключение из пользовательского режима в режим ядра связано со значительной потерей производительности: например, выполнение запроса getpid занимает 1000—1500 циклов, из которых собственно переключение — только ~100 (70 — в ядро, 40 — обратно), остальное — накладные расходы ядра[29][30]. В L3-microkernel общие затраты удалось снизить примерно до 150 циклов[29].

В современных операционных системах для минимизации накладных расходов на переключение режимов были разработаны асинхронные интерфейсы, позволяющие обрабатывать операции ввода-вывода пакетами. В ядре Linux (начиная с версии 5.1) был представлен механизм io_uring, который использует две кольцевые буферные структуры в разделяемой памяти для отправки и получения результатов множества операций с помощью минимального количества системных вызовов[31]. Этот подход, работающий по модели завершения (proactor), значительно превосходит по производительности старые API, такие как epoll, и позволяет сократить количество переключений контекста[32]. В Microsoft Windows, где исторически использовалась эффективная модель портов завершения ввода-вывода (IOCP), был также внедрён аналогичный API IoRing[33]. Таким образом, фокус сместился с оптимизации одного системного вызова на амортизацию затрат за счёт пакетной обработки.

Морис Уилкс отмечал[34]:

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

Для повышения производительности и детерминированности некоторые системы размещают логические функции, которые в иных условиях считались бы приложениями, в пространстве ядра (например, средства контроля доступа, файерволы, мониторы ОС). Эта концепция сохраняет актуальность в нишевых областях, требующих минимальных задержек. Например, СУБД eXtremeDB Kernel Mode (KM) продолжает развиваться и применяется в системах реального времени, сетевом оборудовании, IoT и финансовых приложениях, где устранение переключений режимов критически важно для производительности[35][36]. Последующие версии получили поддержку MVCC, распределённой обработки запросов, а также API для языков Go и Python[37][38].

Иногда функции, напротив, перемещаются из уровня ядра во внешний уровень — например, в ядре Linux некоторые обращения (например, функция gettimeofday) реализуются посредством vDSO, чтобы избежать системного вызова и смены кольца, что дешевле по ресурсам.

Гипервизорный режим

Современные процессоры Intel и AMD поддерживают аппаратную виртуализацию x86, позволяя гипервизору контролировать доступ к аппаратным функциям кольца 0. Intel VT-x и AMD-V, несмотря на несовместимость, позволяют гостевым ОС использовать привилегии кольца 0, не влияя на другие гости или хост.

До появления аппаратной виртуализации гостевые ОС работали на кольце 1; попытки выполнить команды более высокого уровня вызывали прерывание, обработку которого осуществляло программное обеспечение (Trap & Emulate). С поддержкой VT-x/AMD-V гипервизор работает в режиме «VMX Root», обладая наивысшей привилегией, а гости — в «VMX Non-Root» (кольцо 0 в госте, но без аппаратных привилегий). Переходы между режимами определяются структурой управления виртуальной машиной[39].

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

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

Не обязательно использовать все четыре уровня: большинство современных ОС (Windows, macOS, Linux, iOS, Android) используют только «ядро/пользователь» (бит Supervisor/User). Windows NT реализует двухуровневую модель[40]. В режиме реального времени 8086 программы выполняются с максимальным уровнем (0), а в виртуальном — с минимальным (3)[41].

Возможные сценарии расширенного использования колец — контейнеризация, виртуализация. Хост-ОС может использовать привилегированный режим ядра, а гость и пользовательские приложения — режимы с более низкой привилегией. Гостевая ОС и её приложения могут использовать промежуточные уровни для реализации системных вызовов и виртуализации[42].

IOPL

IOPL (англ. I/O Privilege level) — флаг, присутствующий во всех IA-32-совместимых процессорах x86. Размещён в битах 12 и 13 регистра FLAGS. В защищённом и длинном режиме указывает уровень доступа к портам ввода-вывода для выполняемой программы или задачи. Текущий уровень (CPL0…CPL3) должен быть не выше IOPL для доступа к портам.

Флаг IOPL изменяется командами POPF(D) и IRET(D) только из кольца 0.

Кроме IOPL права доступа определяются также картой портов ввода-вывода в TSS.

Прочее

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

  • Кольцо −1 (Гипервизорный режим): Уровень, на котором работает гипервизор, управляющий гостевыми операционными системами. Этот режим подробно описан в соответствующем разделе.
  • Кольцо −2 (System Management Mode): System Management Mode (SMM) — это специальный режим работы основного процессора, в котором приостанавливается выполнение всего остального кода, включая ОС и гипервизор[44]. Он активируется через системное управляющее прерывание (SMI) и предназначен для выполнения низкоуровневых задач, таких как управление питанием и инициализация оборудования. Код SMM выполняется в изолированной области памяти (SMRAM), недоступной для операционной системы[45]. Из-за высочайших привилегий SMM является потенциальным вектором атаки, поэтому современные платформы включают технологии изоляции, такие как SMM Supervisor (AMD) и Intel System Resource Defense (ISRD), для ограничения его полномочий[46].
  • Кольцо −3 (Подсистемы управления платформой): Наиболее привилегированный уровень, на котором работают автономные микропроцессоры, интегрированные в чипсет или центральный процессор, но функционирующие независимо от него[47].
    • Intel Management Engine (ME) — это подсистема, представляющая собой отдельный микропроцессор (начиная с ME 11, используется ядро Intel Quark и ОС MINIX 3)[43]. Она имеет полный доступ к оперативной памяти, сетевому интерфейсу и периферии, продолжая работать, даже когда компьютер выключен (при наличии питания). Закрытый исходный код и широкие полномочия ME вызывают опасения у исследователей безопасности, а в его прошивке периодически обнаруживаются уязвимости[48].
    • AMD Platform Security Processor (PSP), также известный как AMD Secure Technology, — аналог от AMD, представляющий собой встроенный ARM-сопроцессор с технологией TrustZone[43]. Он ориентирован на задачи безопасности: безопасную загрузку, управление ключами шифрования и целостность прошивки. Код PSP также является проприетарным[49]. Несмотря на предположительно меньшую поверхность атаки, в нём также обнаруживаются уязвимости, которые AMD устраняет с помощью обновлений AGESA[50][51].

Использование аппаратных возможностей

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

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

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

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

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

Примечания

  1. Karger, Paul A.; Herbert, Andrew J. (1984). An Augmented Capability Architecture to Support Lattice Security and Traceability of Access. 1984 IEEE Symposium on Security and Privacy [англ.]. p. 2. DOI:10.1109/SP.1984.10001. ISBN 0-8186-0532-4. S2CID 14788823.
  2. Binder, W. (2001). “Design and implementation of the J-SEAL2 mobile agent kernel”. Proceedings 2001 Symposium on Applications and the Internet [англ.]. pp. 35—42. DOI:10.1109/SAINT.2001.905166. ISBN 0-7695-0942-8. S2CID 11066378.
  3. Envisioning a Simplified Intel Architecture for the Future (англ.). Intel. Дата обращения: 28 мая 2024. Архивировано 5 октября 2025 года.
  4. Tanembaum, Andrew S. Modern Operating Systems : [англ.]. — 4th. — Pearson, 2015. — P. 479–480. — «For many years, the x86 has supported four protection modes or rings [...]. Ring 3 is the least privileged [...]. Ring 0 is the most privileged [...]. The remaining two rings are not used by any current operating system.». — ISBN 978-0-13-359162-0.
  5. 6.1. Архитектура микропроцессоров iAPX 286. www.frolov-lib.ru. Дата обращения: 3 ноября 2025. Архивировано 5 сентября 2025 года.
  6. 1 2 3 Кольца защиты, или что скрывает ядро операционной системы. Хабр (1 августа 2013). Дата обращения: 3 ноября 2025.
  7. 1 2 Кольца защиты. StudFiles. Дата обращения: 3 ноября 2025.
  8. 1 2 3 Кольца защиты операционной системы: что это такое и как они работают. ТехноВест. Дата обращения: 3 ноября 2025. Архивировано 23 марта 2025 года.
  9. Difference between 80286 and 80386 Microprocessor (англ.). EEEGuide. Дата обращения: 3 ноября 2025. Архивировано 11 августа 2025 года.
  10. Архитектура микропроцессора 80386. frolov-lib.ru. Дата обращения: 3 ноября 2025. Архивировано 4 ноября 2024 года.
  11. Почему в Linux не используются все 4 кольца защиты? www.linux.org.ru (25 июня 2010). Дата обращения: 3 ноября 2025. Архивировано 28 августа 2016 года.
  12. 1 2 Кольца защиты. chinapads.ru. Дата обращения: 3 ноября 2025. Архивировано 18 июня 2021 года.
  13. VAX — AlphaPedia. alphapedia.ru. Дата обращения: 3 ноября 2025. Архивировано 19 сентября 2024 года.
  14. Tanembaum, Andrew S. Modern Operating Systems : [англ.]. — 4th. — Pearson, 2015. — P. 479–480. — ISBN 978-0-13-359162-0.
  15. 1 2 3 Безопасность на основе виртуализации (VBS). Microsoft Learn. Дата обращения: 3 ноября 2025. Архивировано 8 июля 2025 года.
  16. Kernel Privilege Levels (англ.). LabEx. Дата обращения: 3 ноября 2025. Архивировано 5 сентября 2025 года.
  17. Why do x86 CPUs only use 2 out of 4 rings? (англ.). Super User. Дата обращения: 3 ноября 2025. Архивировано 7 ноября 2024 года.
  18. Linux to get kernel lockdown feature (англ.). ZDNet (10 сентября 2019). Дата обращения: 3 ноября 2025. Архивировано 11 августа 2025 года.
  19. Operating System Rings (англ.). Baeldung. Дата обращения: 3 ноября 2025. Архивировано 11 сентября 2025 года.
  20. AArch64 Exception Levels (англ.). krinkinmu.github.io (4 января 2021). Дата обращения: 3 ноября 2025. Архивировано 14 июня 2025 года.
  21. Native macOS Security Features for Mac Admins (англ.). Scalefusion Blog (23 августа 2023). Дата обращения: 3 ноября 2025. Архивировано 12 августа 2025 года.
  22. Presentation Device Driver Reference for OS/2 – 5. Introduction to OS/2 Presentation Drivers (англ.). Дата обращения: 4 июня 2024. Архивировано 15 июня 2015 года.
  23. Гипервизор Xen: что это, как работает, плюсы и минусы. ServerGate. Дата обращения: 3 ноября 2025.
  24. Xen Summit 2025: Find Your Place in the Future of Virtualization (англ.). Xen Project (22 октября 2024). Дата обращения: 3 ноября 2025. Архивировано 1 сентября 2025 года.
  25. Microsoft Scales Down 'Palladium' (англ.). Slashdot (27 апреля 2005). Дата обращения: 3 ноября 2025. Архивировано 5 августа 2023 года.
  26. “A Hardware Architecture for Implementing Protection Rings”. Communications of the ACM [англ.]. 15 (3). март 1972. Дата обращения 2024-06-04. Проверьте дату в |date= (справка на английском)
  27. Multics Glossary - ring (англ.). Дата обращения: 4 июня 2024. Архивировано 6 октября 2025 года.
  28. supervisor mode (англ.). FOLDOC (15 февраля 1995). Архивировано 13 июня 2025 года.
  29. 1 2 Jochen Liedtke (декабрь 1995). “On µ-Kernel Construction”. Proc. 15th ACM Symposium on Operating System Principles (SOSP) [англ.]. Проверьте дату в |date= (справка на английском)
  30. Ousterhout, J. K. (1990). Why aren't operating systems getting faster as fast as hardware?. Usenix Summer Conference [англ.]. Anaheim, CA. pp. 247—256.
  31. What is io_uring? High-Performance I/O in Linux (англ.). GoCodeo. Дата обращения: 3 ноября 2025. Архивировано 13 июля 2025 года.
  32. From epoll to iourings & Multishot Receives: Why 2025 Is the Year We Finally Kill the Event Loop (англ.). Codemia. Дата обращения: 3 ноября 2025. Архивировано 21 августа 2025 года.
  33. Windows is getting io_uring (англ.). Hacker News. Дата обращения: 3 ноября 2025.
  34. Maurice Wilkes (апрель 1994). “Operating systems in a changing world”. ACM SIGOPS Operating Systems Review [англ.]. 28 (2): 9—21. DOI:10.1145/198153.198154. ISSN 0163-5980. S2CID 254134. Проверьте дату в |date= (справка на английском)
  35. eXtremeDB Kernel Mode (KM) embedded database (англ.). Phaedsys. Дата обращения: 3 ноября 2025. Архивировано 25 июля 2011 года.
  36. eXtremeDB/rt Real-Time Embedded Database (англ.). McObject. Дата обращения: 3 ноября 2025.
  37. McObject’s eXtremeDB 4.0 Embedded Database Gains Features for Real-Time, HA and Big Data Systems (англ.). McObject (8 декабря 2008). Дата обращения: 3 ноября 2025. Архивировано 18 апреля 2024 года.
  38. eXtremeDB v8.4 adds Go language API, new security features and more (англ.). McObject (27 февраля 2024). Дата обращения: 3 ноября 2025. Архивировано 27 мая 2024 года.
  39. Intel® 64 and IA-32 Architectures Software Developer's Manual, Volume 3C : [англ.]. — Intel, 2016. — P. 1–3.
  40. Russinovich, Mark E. Microsoft Windows Internals : [англ.] / Mark E. Russinovich, David A. Solomon. — 4th. — Microsoft Press, 2005. — P. 16. — ISBN 978-0-7356-1917-3.
  41. Sunil Mathur. Microprocessor 8086: Architecture, Programming and Interfacing : [англ.]. — Eastern Economy. — PHI Learning.
  42. Anderson, Thomas. 2.2 // Operating Systems: Principles and Practice : [англ.] / Thomas Anderson, Michael Dahlin. — 2nd. — Recursive Books, 21 августа 2014. — ISBN 978-0985673529.
  43. 1 2 3 Intel ME and AMD PSP: The hidden processors inside your CPU (англ.). Digit.in. Дата обращения: 3 ноября 2025. Архивировано 25 июня 2025 года.
  44. Digging into SMM (англ.). nixhacker.com. Дата обращения: 3 ноября 2025. Архивировано 15 августа 2025 года.
  45. System Management Mode (SMM) (англ.). coreboot. Дата обращения: 3 ноября 2025. Архивировано 5 августа 2025 года.
  46. System Management Mode deep dive: How SMM isolation hardens the platform (англ.). Microsoft Security Blog (12 ноября 2020). Дата обращения: 3 ноября 2025. Архивировано 4 марта 2025 года.
  47. Intel ME is a separate processor (англ.). Hacker News. Дата обращения: 3 ноября 2025. Архивировано 23 февраля 2025 года.
  48. Intel® Converged Security and Management Engine (CSME), Server Platform Services (SPS), Trusted Execution Engine (TXE), and Active Management Technology (AMT) Security Updates (англ.). Intel. Дата обращения: 3 ноября 2025. Архивировано 10 августа 2025 года.
  49. AMD Confirms its Platform Security Processor Code Will Remain Closed-Source (англ.). TechPowerUp (8 августа 2017). Дата обращения: 3 ноября 2025. Архивировано 28 мая 2023 года.
  50. AMD CPU Signature Verification Vulnerability Could Lead to Code Execution (англ.). Cybersecurity News. Дата обращения: 3 ноября 2025. Архивировано 11 апреля 2025 года.
  51. AMD Fixes Critical CPU Flaw Threatening Confidential Computing Security (англ.). Varutra. Дата обращения: 3 ноября 2025.

Литература

  • Intel 80386 Programmer’s Reference

Ссылки