Ядро — это компьютерная программа, лежащая в основе операционной системы компьютера , которая, как правило, полностью контролирует все в системе. Ядро также отвечает за предотвращение и смягчение конфликтов между различными процессами. [1] Это часть кода операционной системы, которая всегда находится в памяти [2] и обеспечивает взаимодействие между аппаратными и программными компонентами. Полное ядро контролирует все аппаратные ресурсы (например, ввод-вывод, память, криптография) через драйверы устройств , разрешает конфликты между процессами, касающимися таких ресурсов, и оптимизирует использование общих ресурсов, например, использование ЦП и кэша , файловых систем и сетевых сокетов. В большинстве систем ядро — одна из первых программ, загружаемых при запуске (после загрузчика ). Оно обрабатывает остальную часть запуска, а также память, периферийные устройства и запросы ввода-вывода (I/O) от программного обеспечения , преобразуя их в инструкции по обработке данных для центрального процессора .
Критический код ядра обычно загружается в отдельную область памяти, которая защищена от доступа прикладного программного обеспечения или других менее важных частей операционной системы. Ядро выполняет свои задачи, такие как запуск процессов, управление аппаратными устройствами, такими как жесткий диск , и обработка прерываний, в этом защищенном пространстве ядра . Напротив, прикладные программы, такие как браузеры, текстовые процессоры или аудио- или видеоплееры, используют отдельную область памяти, пользовательское пространство . Такое разделение предотвращает вмешательство пользовательских данных и данных ядра друг в друга и приводит к нестабильности и замедлению [1] , а также предотвращает влияние неисправных приложений на другие приложения или сбой всей операционной системы. Даже в системах, где ядро включено в адресные пространства приложений , защита памяти используется для предотвращения несанкционированного изменения ядра приложениями.
Интерфейс ядра — это уровень абстракции низкого уровня . Когда процесс запрашивает службу у ядра, он должен вызвать системный вызов , обычно через функцию-оболочку .
Существуют различные конструкции архитектуры ядра. Монолитные ядра работают полностью в одном адресном пространстве с процессором, работающим в режиме супервизора , в основном для скорости. Микроядра запускают большинство, но не все свои службы в пользовательском пространстве, [3] как это делают пользовательские процессы, в основном для устойчивости и модульности . [4] MINIX 3 является ярким примером конструкции микроядра. Ядро Linux является как монолитным, так и модульным, поскольку оно может вставлять и удалять загружаемые модули ядра во время выполнения.
Этот центральный компонент компьютерной системы отвечает за выполнение программ. Ядро берет на себя ответственность за принятие решения в любой момент времени, какая из множества запущенных программ должна быть выделена процессору или процессорам.
Оперативная память (ОЗУ) используется для хранения как программных инструкций, так и данных. [a] Обычно для выполнения программы в памяти должны присутствовать оба эти элемента. Часто нескольким программам требуется доступ к памяти, часто требуя больше памяти, чем доступно компьютеру. Ядро отвечает за решение о том, какую память может использовать каждый процесс, и определяет, что делать, если памяти недостаточно.
Устройства ввода-вывода включают в себя, помимо прочего, периферийные устройства, такие как клавиатуры, мыши, дисководы, принтеры, USB- устройства, сетевые адаптеры и устройства отображения . Ядро предоставляет приложениям удобные методы для использования этих устройств, которые обычно абстрагируются ядром, так что приложениям не нужно знать подробности их реализации.
Ключевые аспекты, необходимые в управлении ресурсами, — это определение домена выполнения ( адресного пространства ) и механизма защиты, используемого для посредничества в доступе к ресурсам внутри домена. [5] Ядра также предоставляют методы для синхронизации и межпроцессного взаимодействия (IPC). Эти реализации могут быть расположены внутри самого ядра, или ядро может также полагаться на другие процессы, которые оно запускает. Хотя ядро должно предоставлять IPC для предоставления доступа к средствам, предоставляемым друг другом, ядра также должны предоставлять работающим программам метод для выполнения запросов на доступ к этим средствам. Ядро также отвечает за переключение контекста между процессами или потоками.
Ядро имеет полный доступ к памяти системы и должно разрешать процессам безопасно получать доступ к этой памяти по мере необходимости. Часто первым шагом в этом является виртуальная адресация , обычно достигаемая путем подкачки страниц и/или сегментации . Виртуальная адресация позволяет ядру сделать заданный физический адрес похожим на другой адрес, виртуальный адрес. Виртуальные адресные пространства могут быть разными для разных процессов; память, к которой один процесс обращается по определенному (виртуальному) адресу, может отличаться от той, к которой другой процесс обращается по тому же адресу. Это позволяет каждой программе вести себя так, как будто она единственная (кроме ядра) запущенная, и таким образом предотвращает сбои приложений друг друга. [6]
Во многих системах виртуальный адрес программы может ссылаться на данные, которые в данный момент не находятся в памяти. Уровень косвенности, предоставляемый виртуальной адресацией, позволяет операционной системе использовать другие хранилища данных, такие как жесткий диск , для хранения того, что в противном случае должно было бы оставаться в основной памяти ( ОЗУ ). В результате операционные системы могут разрешать программам использовать больше памяти, чем физически доступно системе. Когда программе требуются данные, которые в данный момент не находятся в ОЗУ, ЦП сигнализирует ядру, что это произошло, и ядро отвечает, записывая содержимое неактивного блока памяти на диск (при необходимости) и заменяя его данными, запрошенными программой. Затем программу можно возобновить с точки, на которой она была остановлена. Эта схема обычно известна как подкачка по требованию .
Виртуальная адресация также позволяет создавать виртуальные разделы памяти в двух разрозненных областях, одна из которых зарезервирована для ядра ( пространство ядра ), а другая — для приложений ( пространство пользователя ). Процессор не разрешает приложениям обращаться к памяти ядра, что предотвращает повреждение работающего ядра приложением. Это фундаментальное разделение пространства памяти внесло большой вклад в текущие разработки реальных ядер общего назначения и является почти универсальным в таких системах, хотя некоторые исследовательские ядра (например, Singularity ) используют другие подходы.
Для выполнения полезных функций процессам необходим доступ к периферийным устройствам , подключенным к компьютеру, которые контролируются ядром через драйверы устройств . Драйвер устройства — это компьютерная программа, инкапсулирующая, контролирующая и управляющая аппаратным устройством (через его интерфейс HSI) от имени ОС. Он предоставляет операционной системе API, процедуры и информацию о том, как управлять и взаимодействовать с определенным элементом оборудования. Драйверы устройств являются важной и жизненно важной зависимостью для всех ОС и их приложений. Целью разработки драйвера является абстракция; функция драйвера — преобразовывать предписанные ОС вызовы абстрактных функций (программные вызовы) в вызовы, специфичные для устройства. Теоретически устройство должно работать правильно с подходящим драйвером. Драйверы устройств используются, например, для видеокарт, звуковых карт, принтеров, сканеров, модемов и сетевых карт.
На аппаратном уровне общие абстракции драйверов устройств включают в себя:
А на программном уровне абстракции драйверов устройств включают в себя:
Например, чтобы показать пользователю что-либо на экране, приложение должно сделать запрос к ядру, которое перенаправит запрос своему драйверу дисплея, который затем будет отвечать за фактическую отрисовку символа/пикселя. [6]
Ядро должно поддерживать список доступных устройств. Этот список может быть известен заранее (например, во встроенной системе , где ядро будет переписано, если доступное оборудование изменится), настроен пользователем (типично для старых ПК и систем, не предназначенных для личного использования) или обнаружен операционной системой во время выполнения (обычно называется plug and play ). В системах plug and play диспетчер устройств сначала выполняет сканирование различных периферийных шин , таких как Peripheral Component Interconnect (PCI) или Universal Serial Bus (USB), для обнаружения установленных устройств, а затем ищет соответствующие драйверы.
Поскольку управление устройствами — это тема, сильно зависящая от ОС , эти драйверы обрабатываются по-разному в каждом виде архитектуры ядра, но в каждом случае ядро должно предоставлять ввод -вывод , чтобы позволить драйверам физически получать доступ к своим устройствам через какой-либо порт или область памяти. При проектировании системы управления устройствами необходимо принимать важные решения, поскольку в некоторых проектах доступ может включать переключение контекста , что делает операцию очень интенсивной для ЦП и легко приводит к значительному снижению производительности. [ необходима цитата ]
В вычислительной технике системный вызов — это способ, которым процесс запрашивает службу из ядра операционной системы, на запуск которой у него обычно нет разрешения. Системные вызовы обеспечивают интерфейс между процессом и операционной системой. Большинство операций, взаимодействующих с системой, требуют разрешений, недоступных процессу пользовательского уровня, например, ввод-вывод, выполняемый с помощью устройства, присутствующего в системе, или любая форма связи с другими процессами требует использования системных вызовов.
Системный вызов — это механизм, который используется прикладной программой для запроса службы у операционной системы. Они используют инструкцию машинного кода , которая заставляет процессор менять режим. Примером может служить переход из режима супервизора в защищенный режим. Здесь операционная система выполняет такие действия, как доступ к аппаратным устройствам или блоку управления памятью . Обычно операционная система предоставляет библиотеку, которая находится между операционной системой и обычными пользовательскими программами. Обычно это библиотека C, такая как Glibc или Windows API. Библиотека обрабатывает низкоуровневые детали передачи информации ядру и переключения в режим супервизора. Системные вызовы включают close, open, read, wait и write.
Чтобы фактически выполнять полезную работу, процесс должен иметь возможность доступа к службам, предоставляемым ядром. Это реализуется по-разному каждым ядром, но большинство из них предоставляют библиотеку C или API , которые, в свою очередь, вызывают соответствующие функции ядра. [7]
Метод вызова функции ядра различается от ядра к ядру. Если используется изоляция памяти, то пользовательский процесс не может вызвать ядро напрямую, поскольку это будет нарушением правил управления доступом процессора. Вот несколько возможностей:
Важным соображением при проектировании ядра является поддержка, которую оно обеспечивает для защиты от сбоев ( отказоустойчивость ) и от вредоносного поведения ( безопасность ). Эти два аспекта обычно не различаются четко, и принятие этого различия в проектировании ядра приводит к отказу от иерархической структуры для защиты . [5]
Механизмы или политики, предоставляемые ядром, можно классифицировать по нескольким критериям, включая: статические (применяемые во время компиляции ) или динамические (применяемые во время выполнения ); упреждающие или пост-обнаруживающие; в соответствии с принципами защиты, которым они удовлетворяют (например, Деннинг [8] [9] ); поддерживаются ли они оборудованием или основаны на языке; являются ли они в большей степени открытым механизмом или политикой привязки; и многое другое.
Поддержка иерархических доменов защиты [10] обычно реализуется с использованием режимов ЦП .
Многие ядра предоставляют реализацию «возможностей», т. е. объектов, которые предоставляются пользовательскому коду, которые разрешают ограниченный доступ к базовому объекту, управляемому ядром. Типичным примером является обработка файлов: файл — это представление информации, хранящейся на постоянном запоминающем устройстве. Ядро может иметь возможность выполнять множество различных операций, включая чтение, запись, удаление или выполнение, но приложению уровня пользователя может быть разрешено выполнять только некоторые из этих операций (например, ему может быть разрешено только читать файл). Типичная реализация этого заключается в том, что ядро предоставляет объект приложению (обычно так называемый «дескриптор файла»), над которым приложение может затем вызывать операции, действительность которых ядро проверяет во время запроса операции. Такая система может быть расширена для охвата всех объектов, которыми управляет ядро, и, конечно же, объектов, предоставляемых другими пользовательскими приложениями.
Эффективным и простым способом обеспечения аппаратной поддержки возможностей является делегирование блоку управления памятью (MMU) ответственности за проверку прав доступа для каждого доступа к памяти, механизм, называемый адресацией на основе возможностей . [11] Большинство коммерческих компьютерных архитектур не имеют такой поддержки возможностей со стороны MMU.
Альтернативный подход заключается в имитации возможностей с использованием обычно поддерживаемых иерархических доменов. В этом подходе каждый защищенный объект должен находиться в адресном пространстве, к которому приложение не имеет доступа; ядро также поддерживает список возможностей в такой памяти. Когда приложению необходимо получить доступ к объекту, защищенному возможностью, оно выполняет системный вызов, а затем ядро проверяет, предоставляет ли возможность приложения разрешение на выполнение запрошенного действия, и если это разрешено, выполняет доступ для него (либо напрямую, либо путем делегирования запроса другому процессу уровня пользователя). Стоимость производительности переключения адресного пространства ограничивает практичность этого подхода в системах со сложными взаимодействиями между объектами, но он используется в современных операционных системах для объектов, к которым нечасто обращаются или которые не должны выполняться быстро. [12] [13]
Если прошивка не поддерживает механизмы защиты, можно имитировать защиту на более высоком уровне, например, имитируя возможности манипулирования таблицами страниц , но это повлияет на производительность. [14] Однако отсутствие аппаратной поддержки может не быть проблемой для систем, которые решили использовать защиту на основе языка. [15]
Важным решением при проектировании ядра является выбор уровней абстракции, на которых должны быть реализованы механизмы и политики безопасности. Механизмы безопасности ядра играют важную роль в поддержке безопасности на более высоких уровнях. [11] [16] [17] [18] [19]
Один из подходов заключается в использовании поддержки прошивки и ядра для обеспечения отказоустойчивости (см. выше) и построении политики безопасности для вредоносного поведения поверх этого (добавляя такие функции, как механизмы криптографии, где это необходимо), делегируя часть ответственности компилятору . Подходы, которые делегируют реализацию политики безопасности компилятору и/или уровню приложения, часто называют безопасностью на основе языка .
Отсутствие многих критических механизмов безопасности в современных основных операционных системах препятствует реализации адекватных политик безопасности на уровне абстракции приложений . [16] Фактически, распространенное заблуждение в области компьютерной безопасности заключается в том, что любая политика безопасности может быть реализована в приложении независимо от поддержки ядра. [16]
По мнению разработчиков Mars Research Group, отсутствие изоляции является одним из основных факторов, подрывающих безопасность ядра. [20] Они предлагают свою структуру изоляции драйверов для защиты, в первую очередь в ядре Linux. [21] [22]
Типичные компьютерные системы сегодня используют аппаратно-управляемые правила о том, каким программам разрешен доступ к каким данным. Процессор отслеживает выполнение и останавливает программу, которая нарушает правило, например, пользовательский процесс, который пытается записать в память ядра. В системах, в которых отсутствует поддержка возможностей, процессы изолируются друг от друга с помощью отдельных адресных пространств. [23] Вызовы из пользовательских процессов в ядро регулируются, требуя от них использовать один из вышеописанных методов системного вызова.
Альтернативный подход заключается в использовании защиты на основе языка. В системе защиты на основе языка ядро будет разрешать выполнение только кода, созданного доверенным языковым компилятором . Язык может быть разработан таким образом, что программисту будет невозможно дать ему команду сделать что-то, что нарушит требования безопасности. [15]
Преимущества такого подхода включают в себя:
К недостаткам можно отнести:
Примерами систем с языковой защитой являются JX и Singularity от Microsoft .
Эдсгер Дейкстра доказал, что с логической точки зрения атомарные операции блокировки и разблокировки, работающие на двоичных семафорах, являются достаточными примитивами для выражения любой функциональности взаимодействия процессов. [24] Однако этот подход обычно считается недостаточным с точки зрения безопасности и эффективности, тогда как подход с передачей сообщений является более гибким. [25] Также доступен ряд других подходов (как более низкого, так и более высокого уровня), при этом многие современные ядра обеспечивают поддержку таких систем, как общая память и удаленные вызовы процедур .
Идея ядра, в котором устройства ввода-вывода обрабатываются единообразно с другими процессами, как параллельные взаимодействующие процессы, была впервые предложена и реализована Бринчем Хансеном (хотя похожие идеи были предложены в 1967 году [26] [27] ). В описании этого Хансеном «общие» процессы называются внутренними процессами , в то время как устройства ввода-вывода называются внешними процессами . [25]
Подобно физической памяти, предоставление приложениям прямого доступа к портам и регистрам контроллера может привести к сбою контроллера или сбою системы. При этом, в зависимости от сложности устройства, некоторые устройства могут стать на удивление сложными для программирования и использовать несколько разных контроллеров. Из-за этого важно предоставить более абстрактный интерфейс для управления устройством. Этот интерфейс обычно выполняется драйвером устройства или уровнем абстракции оборудования. Часто приложениям требуется доступ к этим устройствам. Ядро должно поддерживать список этих устройств, запрашивая их у системы каким-либо образом. Это можно сделать через BIOS или через одну из различных системных шин (например, PCI/PCIE или USB). Используя пример видеодрайвера, когда приложение запрашивает операцию на устройстве, например, отображение символа, ядру необходимо отправить этот запрос текущему активному видеодрайверу. Видеодрайвер, в свою очередь, должен выполнить этот запрос. Это пример межпроцессного взаимодействия (IPC).
Перечисленные выше задачи и функции могут быть реализованы многими способами, которые отличаются друг от друга по конструкции и реализации.
Принцип разделения механизма и политики является существенным различием между философией микро- и монолитных ядер. [28] [29] Здесь механизм является поддержкой, которая позволяет реализовать множество различных политик, в то время как политика является определенным «режимом работы». Пример:
Поскольку механизм и политика разделены, политику можно легко изменить, например, потребовав использования токена безопасности .
В минимальном микроядре включены только некоторые самые основные политики, [29] и его механизмы позволяют тому, что работает поверх ядра (остальная часть операционной системы и другие приложения), решать, какие политики применять (например, управление памятью, высокоуровневое планирование процессов, управление файловой системой и т. д.). [5] [25] Монолитное ядро, напротив, имеет тенденцию включать множество политик, тем самым ограничивая остальную часть системы в использовании их.
Пер Бринч Хансен представил аргументы в пользу разделения механизма и политики. [5] [25] Неспособность должным образом выполнить это разделение является одной из основных причин отсутствия существенных инноваций в существующих операционных системах, [5] проблема, распространенная в компьютерной архитектуре. [30] [31] [32] Монолитный дизайн обусловлен архитектурным подходом к защите «режим ядра»/«пользовательский режим» (технически называемым иерархическими доменами защиты ), который распространен в обычных коммерческих системах; [33] фактически, каждый модуль, нуждающийся в защите, поэтому предпочтительно включать в ядро. [33] Эта связь между монолитным дизайном и «привилегированным режимом» может быть сведена к ключевому вопросу разделения механизма и политики; [5] фактически архитектурный подход «привилегированного режима» объединяет механизм защиты с политиками безопасности, в то время как основной альтернативный архитектурный подход, адресация на основе возможностей , четко различает их, что естественным образом приводит к микроядерному дизайну [5] (см. Разделение защиты и безопасности ).
В то время как монолитные ядра выполняют весь свой код в одном и том же адресном пространстве ( пространстве ядра ), микроядра пытаются запустить большую часть своих служб в пользовательском пространстве, стремясь улучшить удобство обслуживания и модульность кодовой базы. [4] Большинство ядер не вписываются точно в одну из этих категорий, а скорее находятся между этими двумя конструкциями. Они называются гибридными ядрами . Более экзотические конструкции, такие как наноядра и экзоядра, доступны, но редко используются в производственных системах. Например, гипервизор Xen является экзоядром.
В монолитном ядре все службы ОС работают вместе с основным потоком ядра, таким образом, также находясь в той же области памяти. Такой подход обеспечивает богатый и мощный доступ к оборудованию. Разработчик UNIX Кен Томпсон заявил, что «по [его] мнению, проще реализовать монолитное ядро». [34] Основными недостатками монолитных ядер являются зависимости между компонентами системы — ошибка в драйвере устройства может привести к сбою всей системы — и тот факт, что большие ядра могут стать очень сложными в обслуживании; Томпсон также заявил, что «[монолитному ядру] также проще превратиться в беспорядок в спешке по мере его изменения». [34]
Монолитные ядра, которые традиционно использовались в операционных системах типа Unix, содержат все основные функции операционной системы и драйверы устройств. Монолитное ядро — это одна программа, которая содержит весь код, необходимый для выполнения каждой задачи, связанной с ядром. Каждая часть, к которой должно обращаться большинство программ, которые не могут быть помещены в библиотеку, находится в пространстве ядра: драйверы устройств, планировщик, обработка памяти, файловые системы и сетевые стеки. Множество системных вызовов предоставляется приложениям, чтобы позволить им получить доступ ко всем этим службам. Монолитное ядро, хотя изначально загружено подсистемами, которые могут не понадобиться, можно настроить до такой степени, что оно будет таким же быстрым или быстрее, чем то, которое было специально разработано для оборудования, хотя и более уместно в общем смысле.
Современные монолитные ядра, такие как ядро Linux , ядро FreeBSD , ядро AIX , ядро HP-UX и ядро Solaris , все из которых относятся к категории Unix-подобных операционных систем, поддерживают загружаемые модули ядра , что позволяет загружать модули в ядро во время выполнения, что позволяет легко расширять возможности ядра по мере необходимости, одновременно помогая минимизировать объем кода, работающего в пространстве ядра.
Большая часть работы в монолитном ядре выполняется через системные вызовы. Это интерфейсы, обычно хранящиеся в табличной структуре, которые обращаются к некоторой подсистеме внутри ядра, такой как дисковые операции. По сути, вызовы производятся внутри программ, и проверенная копия запроса передается через системный вызов. Следовательно, далеко ходить не надо. Монолитное ядро Linux можно сделать чрезвычайно маленьким не только из-за его способности динамически загружать модули, но и из-за его простоты настройки. Фактически, есть некоторые версии, которые достаточно малы, чтобы поместиться вместе с большим количеством утилит и других программ на одном гибком диске и при этом обеспечить полностью функциональную операционную систему (одной из самых популярных является muLinux ). Эта возможность миниатюризации ядра также привела к быстрому росту использования Linux во встраиваемых системах .
Эти типы ядер состоят из основных функций операционной системы и драйверов устройств с возможностью загрузки модулей во время выполнения. Они предоставляют богатые и мощные абстракции базового оборудования. Они предоставляют небольшой набор простых абстракций оборудования и используют приложения, называемые серверами, для предоставления большей функциональности. Этот конкретный подход определяет высокоуровневый виртуальный интерфейс через оборудование с набором системных вызовов для реализации служб операционной системы, таких как управление процессами, параллелизм и управление памятью в нескольких модулях, которые работают в режиме супервизора. Эта конструкция имеет несколько недостатков и ограничений:
Микроядро (также сокращенно μK или uK) — это термин, описывающий подход к проектированию операционной системы, при котором функциональность системы перемещается из традиционного «ядра» в набор «серверов», которые взаимодействуют через «минимальное» ядро, оставляя как можно меньше в «системном пространстве» и как можно больше в «пространстве пользователя». Микроядро, разработанное для определенной платформы или устройства, всегда будет иметь только то, что ему нужно для работы. Подход микроядра состоит в определении простой абстракции над оборудованием с набором примитивов или системных вызовов для реализации минимальных служб ОС, таких как управление памятью , многозадачность и межпроцессное взаимодействие . Другие службы, включая те, которые обычно предоставляются ядром, такие как сетевое взаимодействие , реализуются в программах пользовательского пространства, называемых серверами . Микроядра проще поддерживать, чем монолитные ядра, но большое количество системных вызовов и переключений контекста может замедлить работу системы, поскольку они обычно генерируют больше накладных расходов, чем простые вызовы функций.
Только те части, которые действительно требуют нахождения в привилегированном режиме, находятся в пространстве ядра: IPC (межпроцессное взаимодействие), базовый планировщик или примитивы планирования, базовая обработка памяти, базовые примитивы ввода-вывода. Многие критические части теперь работают в пространстве пользователя: полный планировщик, обработка памяти, файловые системы и сетевые стеки. Микроядра были изобретены как реакция на традиционную «монолитную» конструкцию ядра, в которой вся системная функциональность была помещена в одну статическую программу, работающую в специальном «системном» режиме процессора. В микроядре выполняются только самые фундаментальные задачи, такие как возможность доступа к некоторым (не обязательно всем) аппаратным средствам, управление памятью и координация передачи сообщений между процессами. Некоторые системы, использующие микроядра, — это QNX и HURD. В случае QNX и Hurd пользовательские сеансы могут быть полными снимками самой системы или представлениями, как их называют. Сама суть архитектуры микроядра иллюстрирует некоторые из ее преимуществ:
Большинство микроядер используют систему передачи сообщений для обработки запросов от одного сервера к другому. Система передачи сообщений обычно работает на основе порта с микроядром. Например, если отправляется запрос на больше памяти, порт открывается с микроядром и запрос отправляется через него. Попав в микроядро, шаги похожи на системные вызовы. Обоснованием было то, что это привнесет модульность в архитектуру системы, что повлечет за собой более чистую систему, более легкую для отладки или динамического изменения, настраиваемую под потребности пользователей и более производительную. Они являются частью операционных систем, таких как GNU Hurd , MINIX , MkLinux , QNX и Redox OS . Хотя микроядра сами по себе очень малы, в сочетании со всем необходимым вспомогательным кодом они, по сути, часто больше монолитных ядер. Сторонники монолитных ядер также отмечают, что двухуровневая структура микроядерных систем, в которой большая часть операционной системы не взаимодействует напрямую с оборудованием, создает немалые затраты с точки зрения эффективности системы. Эти типы ядер обычно предоставляют только минимальные услуги, такие как определение адресных пространств памяти, межпроцессное взаимодействие (IPC) и управление процессами. Другие функции, такие как запуск аппаратных процессов, не обрабатываются напрямую микроядрами. Сторонники микроядер отмечают, что эти монолитные ядра имеют тот недостаток, что ошибка в ядре может привести к сбою всей системы. Однако с микроядром, если процесс ядра выходит из строя, все еще возможно предотвратить сбой системы в целом, просто перезапустив службу, которая вызвала ошибку.
Другие службы, предоставляемые ядром, такие как сетевые, реализованы в программах пользовательского пространства, называемых серверами . Серверы позволяют изменять операционную систему, просто запуская и останавливая программы. Например, для машины без сетевой поддержки сетевой сервер не запускается. Задача перемещения в ядро и из него для перемещения данных между различными приложениями и серверами создает накладные расходы, которые пагубно влияют на эффективность микроядер по сравнению с монолитными ядрами.
Однако недостатки микроядра существуют. Вот некоторые из них:
Недостатки микроядер в значительной степени основаны на контексте. Например, они хорошо работают для небольших одноцелевых (и критических) систем, поскольку если не требуется запускать много процессов, то сложности управления процессами эффективно смягчаются.
Микроядро позволяет реализовать оставшуюся часть операционной системы как обычную прикладную программу, написанную на языке высокого уровня , и использовать различные операционные системы поверх того же неизмененного ядра. Также возможно динамически переключаться между операционными системами и иметь более одной активной одновременно. [25]
По мере роста ядра компьютера растут и размер и уязвимость его доверенной вычислительной базы ; и, помимо снижения безопасности, существует проблема увеличения объема памяти . Это смягчается в некоторой степени путем совершенствования системы виртуальной памяти , но не все компьютерные архитектуры поддерживают виртуальную память. [b] Чтобы уменьшить объем памяти ядра, необходимо выполнить обширное редактирование для тщательного удаления ненужного кода, что может быть очень сложно из-за неочевидных взаимозависимостей между частями ядра с миллионами строк кода.
К началу 1990-х годов из-за различных недостатков монолитных ядер по сравнению с микроядрами монолитные ядра считались устаревшими практически всеми исследователями операционных систем. [ требуется ссылка ] В результате проектирование Linux как монолитного ядра, а не микроядра стало темой знаменитого спора между Линусом Торвальдсом и Эндрю Таненбаумом . [35] Аргументы, представленные в дебатах Таненбаума и Торвальдса , имеют свои достоинства с обеих сторон .
Монолитные ядра спроектированы так, чтобы весь их код находился в одном адресном пространстве ( пространстве ядра ), что, по мнению некоторых разработчиков, необходимо для повышения производительности системы. [36] Некоторые разработчики также утверждают, что монолитные системы чрезвычайно эффективны, если они хорошо написаны. [36] Монолитная модель имеет тенденцию быть более эффективной [37] за счет использования общей памяти ядра, а не более медленной системы IPC микроядерных конструкций, которая обычно основана на передаче сообщений . [ требуется ссылка ]
Производительность микроядер была низкой как в 1980-х, так и в начале 1990-х годов. [38] [39] Однако исследования, которые эмпирически измеряли производительность этих микроядер, не анализировали причины такой неэффективности. [38] Объяснения этих данных были оставлены на усмотрение «фольклора», с предположением, что они были связаны с возросшей частотой переключений из «режима ядра» в «пользовательский режим», возросшей частотой межпроцессного взаимодействия и возросшей частотой переключений контекста . [38]
Фактически, как предполагалось в 1995 году, причинами плохой производительности микроядер могли быть: (1) фактическая неэффективность всего подхода микроядра , (2) конкретные концепции , реализованные в этих микроядрах, и (3) конкретная реализация этих концепций. Поэтому оставалось изучить, было ли решение для создания эффективного микроядра, в отличие от предыдущих попыток, применить правильные методы построения. [38]
С другой стороны, иерархическая архитектура доменов защиты , которая приводит к проектированию монолитного ядра [33], имеет существенный недостаток производительности каждый раз, когда происходит взаимодействие между различными уровнями защиты (т. е. когда процесс должен манипулировать структурой данных как в «режиме пользователя», так и в «режиме супервизора»), поскольку это требует копирования сообщений по значению . [40]
Гибридные ядра используются в большинстве коммерческих операционных систем, таких как Microsoft Windows NT 3.1, NT 3.5, NT 3.51, NT 4.0, 2000, XP, Vista, 7, 8, 8.1 и 10. Собственная macOS от Apple использует гибридное ядро под названием XNU , которое основано на коде из ядра OSF/1 Mach (OSFMK 7.3) [41] и монолитного ядра FreeBSD . Гибридные ядра похожи на микроядра, за исключением того, что они включают некоторый дополнительный код в пространстве ядра для повышения производительности. Эти ядра представляют собой компромисс, который был реализован некоторыми разработчиками для обеспечения основных преимуществ как монолитных, так и микроядер. Эти типы ядер являются расширениями микроядер с некоторыми свойствами монолитных ядер. В отличие от монолитных ядер, эти типы ядер не могут загружать модули во время выполнения самостоятельно. [ необходима цитата ] Это подразумевает запуск некоторых служб (таких как сетевой стек или файловая система ) в пространстве ядра для снижения накладных расходов на производительность традиционного микроядра, но при этом по-прежнему запуск кода ядра (например, драйверов устройств) в качестве серверов в пространстве пользователя.
Многие традиционно монолитные ядра теперь, по крайней мере, добавляют (или используют) возможность модуля. Наиболее известным из таких ядер является ядро Linux. Модульное ядро по сути может иметь части, встроенные в двоичный файл ядра или двоичные файлы, которые загружаются в память по требованию. Модуль с испорченным кодом может дестабилизировать работающее ядро. Можно написать драйвер для микроядра в совершенно отдельном пространстве памяти и протестировать его перед «выходом» в эксплуатацию. Когда модуль ядра загружается, он обращается к пространству памяти монолитной части, добавляя в него то, что ему нужно, тем самым открывая дверь для возможного загрязнения. Несколько преимуществ модульного (или) гибридного ядра:
Модули, как правило, взаимодействуют с ядром, используя модульный интерфейс некоторого рода. Интерфейс является обобщенным (хотя и специфичным для данной операционной системы), поэтому не всегда возможно использовать модули. Часто драйверам устройств может потребоваться больше гибкости, чем предоставляет модульный интерфейс. По сути, это два системных вызова, и часто проверки безопасности, которые должны быть выполнены только один раз в монолитном ядре, теперь могут быть выполнены дважды. Некоторые из недостатков модульного подхода:
Наноядро делегирует практически все службы, включая даже самые базовые, такие как контроллеры прерываний или таймер , драйверам устройств , что делает требования к памяти ядра еще меньше, чем у традиционного микроядра. [42]
Экзоядра — это все еще экспериментальный подход к проектированию операционных систем. Они отличаются от других типов ядер тем, что ограничивают свою функциональность защитой и мультиплексированием сырого оборудования, не предоставляя никаких аппаратных абстракций, поверх которых можно разрабатывать приложения. Такое разделение аппаратной защиты от аппаратного управления позволяет разработчикам приложений определять, как наиболее эффективно использовать имеющееся оборудование для каждой конкретной программы.
Экзоядра сами по себе чрезвычайно малы. Однако они сопровождаются библиотечными операционными системами (см. также unikernel ), предоставляя разработчикам приложений функциональные возможности обычной операционной системы. Это сводится к тому, что каждый пользователь пишет свою собственную остальную часть ядра практически с нуля, что является очень рискованным, сложным и довольно пугающим заданием — особенно в ограниченной по времени производственной среде, поэтому экзоядра так и не прижились. [ необходима цитата ] Главным преимуществом систем на основе экзоядра является то, что они могут включать несколько библиотечных операционных систем, каждая из которых экспортирует свой API , например, один для разработки пользовательского интерфейса высокого уровня и один для управления в реальном времени .
Многоядерная операционная система рассматривает многоядерную машину как сеть независимых ядер, как если бы это была распределенная система . Она не предполагает общей памяти, а скорее реализует межпроцессное взаимодействие как передачу сообщений . [43] [44] Barrelfish была первой операционной системой, которая была описана как многоядерная.
Строго говоря, операционная система (и, следовательно, ядро) не требуется для запуска компьютера. Программы могут быть напрямую загружены и выполнены на машине «голого железа» , при условии, что авторы этих программ готовы работать без какой-либо аппаратной абстракции или поддержки операционной системы. Большинство ранних компьютеров работали таким образом в 1950-х и начале 1960-х годов, которые сбрасывались и перезагружались между выполнением различных программ. В конце концов, небольшие вспомогательные программы, такие как загрузчики программ и отладчики, оставались в памяти между запусками или загружались из ПЗУ . По мере их разработки они сформировали основу того, что стало ранними ядрами операционных систем. Подход «голого железа» все еще используется сегодня на некоторых игровых консолях и встроенных системах , [45] но в целом более новые компьютеры используют современные операционные системы и ядра.
В 1969 году многопрограммная система RC 4000 представила философию проектирования системы на основе небольшого ядра, «на котором операционные системы для различных целей могли бы быть построены упорядоченным образом» [46] , что впоследствии было названо подходом микроядра.
В десятилетие, предшествовавшее Unix , компьютеры невероятно выросли в мощности — до такой степени, что операторы компьютеров искали новые способы заставить людей использовать свое свободное время на своих машинах. Одним из главных достижений в эту эпоху было разделение времени , когда несколько пользователей получали небольшие куски компьютерного времени, с такой скоростью, что казалось, что каждый из них подключен к своей собственной, более медленной машине. [47]
Разработка систем с разделением времени привела к ряду проблем. Одна из них заключалась в том, что пользователи, особенно в университетах, где разрабатывались системы, хотели взломать систему, чтобы получить больше процессорного времени. По этой причине безопасность и контроль доступа стали основными направлениями проекта Multics в 1965 году. [48] Другой постоянной проблемой было правильное управление вычислительными ресурсами: пользователи проводили большую часть своего времени, уставившись в терминал и думая о том, что ввести, вместо того, чтобы фактически использовать ресурсы компьютера, и система с разделением времени должна была предоставлять процессорное время активному пользователю в эти периоды. Наконец, системы обычно предлагали иерархию памяти в несколько слоев, и разделение этого дорогостоящего ресурса привело к серьезным разработкам в системах виртуальной памяти .
Commodore Amiga был выпущен в 1985 году и был одним из первых — и, безусловно, самых успешных — домашних компьютеров с усовершенствованной архитектурой ядра. Исполнительный компонент ядра AmigaOS, exec.library , использует микроядерную архитектуру передачи сообщений, но есть и другие компоненты ядра, такие как graphics.library , которые имеют прямой доступ к оборудованию. Защита памяти отсутствует, и ядро почти всегда работает в пользовательском режиме. В режиме ядра выполняются только специальные действия, а приложения пользовательского режима могут запрашивать у операционной системы выполнение своего кода в режиме ядра.
На этапе проектирования Unix программисты решили моделировать каждое высокоуровневое устройство как файл , поскольку они считали, что целью вычислений является преобразование данных . [49]
Например, принтеры представлялись как «файл» в известном месте — когда данные копировались в файл, они распечатывались. Другие системы, чтобы обеспечить схожую функциональность, имели тенденцию виртуализировать устройства на более низком уровне — то есть и устройства, и файлы были бы экземплярами некоторой концепции более низкого уровня . Виртуализация системы на уровне файлов позволяла пользователям манипулировать всей системой, используя имеющиеся у них утилиты и концепции управления файлами , что значительно упрощало работу. Как расширение той же парадигмы, Unix позволяет программистам манипулировать файлами, используя ряд небольших программ, используя концепцию каналов , которая позволяла пользователям выполнять операции поэтапно, пропуская файл через цепочку одноцелевых инструментов. Хотя конечный результат был тем же, использование меньших программ таким образом значительно увеличивало гибкость, а также простоту разработки и использования, позволяя пользователю изменять свой рабочий процесс, добавляя или удаляя программу из цепочки.
В модели Unix операционная система состоит из двух частей: во-первых, огромного набора служебных программ, которые управляют большинством операций; во-вторых, ядра, которое запускает программы. [49] В Unix, с точки зрения программирования, различие между ними довольно тонкое; ядро — это программа, работающая в режиме супервизора, [c] которая действует как загрузчик программ и супервизор для небольших служебных программ, составляющих остальную часть системы, а также обеспечивает блокировку и службы ввода-вывода для этих программ; за пределами этого ядро вообще не вмешивалось в пространство пользователя .
С годами вычислительная модель изменилась, и подход Unix ко всему как к файлу или потоку байтов больше не был столь универсальным, как раньше. Хотя терминал можно было рассматривать как файл или поток байтов, который печатается или считывается, то же самое, по-видимому, не было верно для графического пользовательского интерфейса . Сетевые технологии представляли собой еще одну проблему. Даже если сетевое взаимодействие можно сравнить с доступом к файлам, низкоуровневая пакетно-ориентированная архитектура имела дело с отдельными фрагментами данных, а не с целыми файлами. По мере роста возможностей компьютеров Unix становился все более загроможденным кодом. Это также связано с тем, что модульность ядра Unix широко масштабируется. [50] В то время как в семидесятых и восьмидесятых годах ядра могли иметь 100 000 строк кода , ядра, такие как Linux , современных преемников Unix, таких как GNU , имеют более 13 миллионов строк. [51]
Современные производные Unix, как правило, основаны на монолитных ядрах с загрузкой модулей. Примерами этого являются ядро Linux во многих дистрибутивах GNU , IBM AIX , а также варианты ядер Berkeley Software Distribution, такие как FreeBSD , DragonFly BSD , OpenBSD , NetBSD и macOS . Помимо этих альтернатив, разработчики-любители поддерживают активное сообщество разработчиков операционных систем , заполненное самописными ядрами-любителями, которые в основном в конечном итоге разделяют многие функции с ядрами Linux, FreeBSD, DragonflyBSD, OpenBSD или NetBSD и/или совместимы с ними. [52]
Apple впервые выпустила свою классическую Mac OS в 1984 году в комплекте с персональным компьютером Macintosh . Apple перешла на дизайн наноядра в Mac OS 8.6. Напротив, современная macOS (первоначально называвшаяся Mac OS X) основана на Darwin , который использует гибридное ядро под названием XNU , которое было создано путем объединения ядра 4.3BSD и ядра Mach . [53]
Microsoft Windows впервые была выпущена в 1985 году как дополнение к MS-DOS . Из-за своей зависимости от другой операционной системы, первые выпуски Windows, до Windows 95, считались операционной средой (не путать с операционной системой ). Эта линейка продуктов продолжала развиваться в течение 1980-х и 1990-х годов, с серией Windows 9x, добавившей 32-битную адресацию и упреждающую многозадачность; но закончилась с выпуском Windows Me в 2000 году.
Microsoft также разработала Windows NT , операционную систему с очень похожим интерфейсом, но предназначенную для высококлассных и бизнес-пользователей. Эта линейка началась с выпуска Windows NT 3.1 в 1993 году и была представлена обычным пользователям с выпуском Windows XP в октябре 2001 года, заменив Windows 9x на совершенно другую, гораздо более сложную операционную систему. Эта линейка продолжается в Windows 11 .
Архитектура ядра Windows NT считается гибридным ядром, поскольку само ядро содержит такие задачи, как диспетчер окон и диспетчеры IPC, с многоуровневой моделью подсистемы клиент/сервер. [54] Оно было разработано как модифицированное микроядро , поскольку ядро Windows NT находилось под влиянием микроядра Mach , но не соответствует всем критериям чистого микроядра.
Программа-контролер или супервизор — это компьютерная программа , обычно являющаяся частью операционной системы , которая контролирует выполнение других процедур и регулирует планирование работы , операции ввода/вывода , действия при ошибках и аналогичные функции, а также регулирует поток работы в системе обработки данных .
Исторически этот термин в основном ассоциировался с линейкой операционных систем для мэйнфреймов IBM , начиная с OS/360 . В других операционных системах супервизор обычно называется ядром.
В 1970-х годах IBM еще больше абстрагировала состояние супервизора от оборудования, что привело к появлению гипервизора , который обеспечивал полную виртуализацию , т. е. возможность запускать несколько операционных систем на одной машине совершенно независимо друг от друга. Поэтому первая такая система была названа Virtual Machine или VM .
Хотя Mach , разработанный Ричардом Рашидом в Университете Карнеги-Меллона , является самым известным микроядром общего назначения, были разработаны и другие микроядра с более конкретными целями. Семейство микроядер L4 (в основном ядра L3 и L4) было создано для демонстрации того, что микроядра не обязательно медленные. [55] Более новые реализации, такие как Fiasco и Pistachio, способны запускать Linux рядом с другими процессами L4 в отдельных адресных пространствах. [56] [57]
Кроме того, QNX — это микроядро, которое в основном используется во встраиваемых системах [58] , а программное обеспечение с открытым исходным кодом MINIX , изначально созданное для образовательных целей, теперь ориентировано на то, чтобы стать высоконадежной и самовосстанавливающейся микроядерной ОС.
. . . почти все системные вызовы [вызываются] из программ на языке C путем вызова библиотечной процедуры . . . Библиотечная процедура . . . выполняет инструкцию TRAP для переключения из пользовательского режима в режим ядра и запуска выполнения . . .
Последние 25 лет показали, что исследования архитектуры операционных систем оказали незначительное влияние на существующие основные [ sic ] системы.
Тесно связанная природа монолитного ядра позволяет ему очень эффективно использовать базовое оборудование [...] Микроядра, с другой стороны, запускают гораздо больше основных процессов в пользовательском пространстве. [...] К сожалению, эти преимущества достигаются ценой того, что микроядру приходится передавать большой объем информации в пространство ядра и из него через процесс, известный как переключение контекста. Переключение контекста приводит к значительным накладным расходам и, следовательно, к снижению производительности.
