Конфигурация изолированных расширений и драйверов устройств

Конфигурация изолированных расширений и драйверов устройств

Иллюстрации

Показать все

Реферат

ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ

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

Однако часто требуются дополнительные функциональные возможности и/или конфигурирование на индивидуальной основе. Другими словами, функциональные возможности расширяются. Обычно программные системы предусматривают расширение обеспечением динамического добавления новых программных модулей или процессов. Эти добавления часто называются «расширениями» или «подключаемыми программами». Общие примеры расширений или подключаемых программ в традиционных системах включают в себя, но не в качестве ограничения, драйверы устройств для операционных систем, расширенные хранимые процедуры в базах данных, подключаемые программы и компоненты технологии ActiveX™ в Web-браузерах, контент ISAPI (интерфейса прикладного программирования Интернет-сервера) и расширения фильтров в Web-серверах, расширения оболочек для командных оболочек пользовательского интерфейса и т.п. Функциональные возможности, добавленные посредством расширений, варьируются от простой поддержки обновленных версий устройств аппаратного обеспечения, до вирусных сканеров и сервисных средств управления рабочим процессом в клиентах электронной почты. Однако традиционный подход к интеграции расширений может быть проблематичным.

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

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

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

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

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

Следовательно, традиционные драйверы входят в число наиболее ненадежных компонентов ОС. Некоторые отчеты показывают, что 85% продиагностированных отказов в наиболее популярных традиционных ОС вызываются драйверами. Другие отчеты показывают, что вероятность содержания ошибок в драйверах менее популярных традиционных ОС в семь раз больше, чем в других исполняемых командах, содержащихся в ядре.

СУЩНОСТЬ ИЗОБРЕТЕНИЯ

В материалах настоящей заявки описаны одна или более реализаций для описания и/или принятия мер в ответ на требования к конфигурации приложений, расширений, драйверов устройств и других компонентов программных систем.

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

ПЕРЕЧЕНЬ ФИГУР ЧЕРТЕЖЕЙ

По всем чертежам одинаковые номера используются для указания ссылкой на подобные элементы и признаки.

Фиг.1 - рабочий сценарий для архитектуры операционной системы, которая поддерживает одну или более реализаций, описанных в материалах настоящей заявки.

Фиг.2 - структурная схема архитектуры операционной системы, которая поддерживает одну или более реализаций, описанных в материалах настоящей заявки.

Фиг.3 - структурная диаграмма объектов, находящихся внутри процесса драйвера устройства, и их взаимосвязи с другими компонентами архитектуры операционной системы, изображенными на Фиг.2.

Фиг.4 - блок-схема последовательности операций другой методологической реализации, описанной в материалах настоящей заявки.

ПОДРОБНОЕ ОПИСАНИЕ

Последующее описание объясняет методики для описания и/или принятия мер в ответ на требования к конфигурации приложений, расширений, драйверов устройств и других компонентов программных систем.

Традиционные расширения (например, драйверы устройств) включают в себя исполняемые команды для прямого доступа к вычислительным ресурсам, таким как ввод/вывод (I/O), память, видео, звук, линии запроса на прерывание (IRQ) или другие устройства аппаратного обеспечения. В отличие от традиционных расширений, расширения (например, драйверы устройств), созданные в соответствии с одной или более реализациями, описанными в материалах настоящей заявки, осуществляют доступ к вычислительным ресурсам через один или более объектов локального доступа, которые являются объектами (т.е. исполняемыми командами с одной или более структурами данных), обеспечивающими шлюз или мост для вычислительных ресурсов.

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

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

Это новое разделение труда наделяет хозяина расширения (ОС в одном или более вариантах осуществления для драйверов устройств), способностью проверять все требования к конфигурации и контролировать любое осуществление доступа расширением к ресурсам I/O (ввода/вывода) или IPC.

Программно-Изолированные Процессы

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

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

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

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

Фиг.1 демонстрирует рабочий сценарий конструирования SIP-процессов. Она показывает архитектуру 100 конструирования процессов как часть операционной системы 110, сохраненной и/или работающей на компьютере 120. Архитектура 100 конструирования процессов может являться частью операционной системы, как показано на фиг.1. В качестве альтернативы, вся или часть архитектуры 100 конструирования процессов может быть отделена от операционной системы, но по-прежнему работать совместно с операционной системой.

Архитектура 100 конструирования процессов конструирует процессы в рабочей памяти компьютера из динамического набора составляющих компонентов, скомпонованного из набора расширяемых компонентов. После конструирования исполняемые команды активного процесса фиксируются. После фиксации активный процесс обычно не выполняет новых, исполняемых процессором, команд. Для того чтобы сделать это, обычно процесс заново переконструируется с новыми исполняемыми командами, как часть его, или создается новый процесс-дополнение.

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

Компьютер 120 включает в себя компьютерное запоминающее устройство 122 (например, жесткий диск, RAID-систему и т.п.), которое хранит набор загружаемых модулей 124 и рабочую память 130. В примере на фиг.1 архитектура 100 конструирования процессов конструирует процесс 140, который сохраняется в рабочей памяти 130. Как изображено здесь, процесс 140 конструируется из загружаемых модулей 124, которые являются описаниями составляющих компонентов процесса, скомпонованных из расширяемых компонентов процесса.

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

При конструировании процесса архитектура 100 конструирования процесса может использовать один или более следующих функциональных компонентов: компоновщик 150 манифеста процесса, дизайнер 152 представления типизированного кода, корректор 154 представления типизированного кода, оптимизатор 156, конвертер 158 представления типизированного кода, нейтрализатор 160 межпроцессного взаимного влияния и дизайнер 162 фиксированного идетификатора. Несмотря на то, что фиг.1 показывает эти функциональные компоненты отдельно друг от друга, функциональные возможности одного или более этих функциональных компонентов могут быть комбинированы.

Заявка "Inter-Process Communications Employing Bi-Direction/Message Conduits" («Межпроцессное Взаимодействие, Использующее Двухсторонние Каналы Сообщений») раскрывает компоненты модели ОС, которая поддерживает межпроцессный обмен информацией, который может быть использован среди SIP-процессов (а также ОС).

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

Новое ядро (которое поддерживает реализации, описанные в материалах настоящей заявки и которое представляет операционная система 210) состоит почти полностью из безопасных исполняемых команд, а остаток системы, который исполняется в SIP-процессах, состоит из проверяемо безопасных исполняемых команд, включая драйверы устройств, системные процессы и приложения. Несмотря на то, что все небезопасные исполняемые команды должны быть проверяемо безопасны, части нового ядра и системы времени исполнения, называемые доверенной основой, не являются проверяемо безопасными. Безопасность языка защищает эту доверенную основу от небезопасных исполняемых команд. Кроме того, целостность каждого SIP зависит от безопасности команд и от распространяющегося на всю систему инварианта, говорящего, что процесс не содержит ссылок на объектное пространство другого процесса.

Межпроцессное Взаимодействие

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

SIP создает канал, вызывая статический метод контракта NewChannel, который в своих выходных параметрах возвращает две конечные точки канала, ассиметрично типизированные, как экспортер и импортер.

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

Отправка в канал является асинхронной. Синхронное получение блоков продолжается до получения специального сообщения. Используя особенности языка, поток может ожидать первого набора сообщений через канал или может ожидать специальных наборов сообщений из других каналов. Когда данные передаются через канал, право владения передается от посылающего процесса, который может не сохранять ссылку на сообщение, к получающему процессу. Этот инвариант монопольного использования осуществляется посредством системы языка и времени исполнения и служит трем целям. Первая - предотвратить совместное использование между процессами. Вторая - сделать более удобным статический анализ программ, устраняя неоднозначность указателей в сообщениях. Третья - позволить гибкость реализации, обеспечивая семантику передачи сообщений, которая может быть реализована копированием или передачей указателя.

Изолированная Расширяемость

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

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

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

Динамическая загрузка исполняемых команд навязывает второе, менее очевидное, бремя на производительность и корректность. Система, которая может динамически загружать исполняемые команды, является открытой средой, в которой трудно или невозможно сделать надежное предположение о состоянии, инвариантах или правомерных переходах системы. Рассмотрим виртуальную машину Java (JVM), в которой в любое время прерывание, исключение или переключатель потоков могут выполнить команды, которые загружают новый файл, переписывают тело класса и метода и изменяют глобальное состояние. Вообще, не существует достоверного способа проанализировать программу, работающую в такой среде, кроме необоснованного предположения, что среда произвольно не изменится между двумя исполняемыми командами.

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

Наиболее распространенным механизмом изоляции является традиционный процесс ОС, но его высокие затраты ограничивают его практичность. Аппаратное обеспечение управления памятью в современных процессорах обеспечивает процесс жесткими границами и защищает состояние процессора, но оно накладывает большие неудобства в межпроцессном управлении и передаче данных. В современных x86 процессорах переключение между процессами может требовать от сотен до тысяч циклов, не включая TLB и потери заполнения КЭШа.

Более новые системы, такие как виртуальная машина Java™ (JVM) и Общеязыковая Среда Времени Исполнения (CLR) компании Microsoft®, разработаны для расширяемости и поэтому используют безопасность языка, а не аппаратное обеспечение, в качестве механизма, призванного изолировать вычисления, исполняемые в одном и том же адресном пространстве. Однако защищенные языки сами по себе могут являться недостаточной гарантией изоляции. Совместное использование данных обеспечивает маршрут между объектными пространствами вычислений, на котором интерфейсы прикладного программирования (API) точечного отражения обеспечивают механизм, позволяющий разрушать абстракцию данных и сокрытие информации. Как следствие, эти системы требуют сложных механизмов защиты и методик, таких как детальный контроль доступа Виртуальной Машины Java (JVM) или Технология Обеспечения Безопасности (Code Access Security) CLR, чтобы контролировать доступ к механизмам системы и интерфейсам.

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

Как минимум одна реализация, описанная в материалах настоящей заявки, использует SIP-процессы, чтобы инкапсулировать исполняемые команды системных компонентов в замкнутой среде. Расширения для системы или приложение исполняются в новом SIP и взаимодействуют с родителем посредством каналов, которые обеспечивают ограниченные и соответствующие функциональные возможности. Если происходит сбой в работе приложения, его SIP завершается, что позволяет ОС вернуть себе ресурсы и уведомить сообщающихся с ней партнеров. Так как эти партнеры не имели общего состояния с расширением, исправление ошибки является локальным и обеспечивается подробно разработанными протоколами каналов.

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

Компьютерная Архитектура, поддерживающая Конфигурацию Изолированных Драйверов Устройств

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

Фиг.2 изображает примерную архитектуру 200 операционной системы (ОС), которая поддерживает конфигурацию изолированных расширений и драйверов устройств и одну или более реализаций, описанных в материалах настоящей заявки. Как изображено на фиг.2, примерная архитектура 200 ОС демонстрирует ядро 200, один или более драйверов 220 устройств, одну или более файловых систем 230 и одно или более приложений 240. Специалисты в этой области техники признают, что ОС может включать в себя дополнительные службы ОС, которые исполняются в SIP-процессах, подобно файловой системе 330.

Ядро 210 является привилегированным системным компонентом, который контролирует доступ к ресурсам аппаратного обеспечения, распределяет и восстанавливает память, создает и планирует потоки, обеспечивает внутрипроцессную потоковую синхронизацию и управляет вводом/выводом (I/O).

Ядро 210 обеспечивает основные функциональные возможности ОС. Они включают в себя, например, управление памятью и другими ресурсами аппаратного обеспечения, порождение и завершение процессов, межпроцессную коммуникацию, операции для работы с каналами, планирование и операции ввода/вывода (I/O). Некоторые из компонентов этого ядра 210 включают в себя менеджер (средство управления) 211 ввода/вывода (I/O), планировщик 212, менеджер 213 страниц, координатор 214 драйвера устройства и уровень 215 аппаратных абстракций (HAL).

Исполняемые команды в этой примерной архитектуре 200 ОС являются либо проверенными, либо доверенными. Безопасность типов и безопасность памяти проверенных команд контролируется компилятором. Непроверяемые команды должны быть доверенными для операционной системы (ОС) и ограничены уровнем 215 аппаратных абстракций (HAL), ядром 210 и частями доверенных объектов 324, 334 и 344 времени исполнения.

Все исполняемые команды, находящиеся вне ядра, и доверенные объекты времени исполнения написаны на безопасном языке, таком как C# или Java, переведены на безопасный промежуточный язык, такой как Промежуточный Язык компании Microsoft® (MSIL) и затем откомпилированы в исполняемую процессором команду одним или более другими завершающими компиляторами.

Линия раздела между командами ядра и командами программно-изолированного процесса (SIP) размывается доверенной системой времени исполнения. Доверенная система времени исполнения содержит доверенные, но непроверяемые исполняемые команды. Исполняемая команда объекта времени исполнения защищена от команд программно-изолированного процесса (SIP), потому что их проверенная безопасность типа предохраняет их от взаимодействия с системой времени исполнения и ее структурами данных, за исключением взаимодействия через безопасные интерфейсы. Во многих случаях завершающий компилятор может безопасно встроить команды из доверенного объекта времени исполнения в другую исполняемую команду программно-изолированного процесса, таким образом безопасно перемещая операции, которые традиционно должны были бы работать в ядре, в пользовательский процесс.

Исполняемые команды драйвера 220 устройства включают в себя команды, написанные программистом драйвера устройства, плюс исполняемые команды из одной или более библиотек 222 классов и их доверенного объекта 224 времени исполнения. Подобным образом, как изображено на фиг.2, файловая система 230 включает в себя исполняемые команды из библиотек 232 классов и ее доверенного объекта 234 времени исполнения. Кроме того, как изображено на фиг.2, приложение 240 включает в себя исполняемые команды из библиотек 242 классов и его доверенного объекта 244 времени исполнения.

Фиг.3 изображает объекты, относящиеся к внутренней конфигурации примерного процесса 300 драйвера устройства и их взаимоотношения с другими частями примерной архитектуры 200 операционной системы (ОС), поддерживаемые одой или более реализациями, описанными в материалах настоящей заявки. Как изображено, примерная архитектура 200 ОС демонстрирует ядро 210 ОС, примерный процесс 300 драйвера устройства, аппаратные и другие вычислительные ресурсы 350.

Ядро 310 ОС включает в себя один или более каналов 312, доступных для передачи межпроцессных сообщений. Как изображено на фиг.3, аппаратные и другие вычислительные ресурсы 350 включают в себя порт 352 ввода/вывода (I/O) (также известный, как регистр I/O), память 354 I/O, контроллер 356 Прямого Доступа к Памяти (DMA) и линию 358 запроса на прерывание (IRQ). Конечно, это только примеры некоторых аппаратных средств и других вычислительных ресурсов. Другие реализации могут включать в себя другие общие и редко встречающиеся аппаратные и другие вычислительные ресурсы. Реализации могут также включать более одного порта 352 ввода/вывода (I/O), памяти 354 ввода/вывода (I/O), контроллера 356 DMA или линии 358 запроса на прерывание. Некоторые реализации могут не включать в себя все эти типы аппаратных ресурсов.

Примерный процесс 300 драйвера устройства содержит объекты, реализующие функции драйвера устройства, объекты 326 драйвера устройства. Процесс 300 драйвера устройства также содержит доверенный рабочий модуль 224, ноль или более библиотек 222 классов и объект 328 конфигурации.

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

Доверенный рабочий модуль 224 включает в себя объекты доступа, которые опосредуют доступ к аппаратным и IPC-ресурсам. Эти объекты доступа включают в себя (в качестве примера и без ограничения) IoPort 332, IoMemory 334, IoDma 336, IoIrq 338 и endpoint 340. Объекты доступа в доверенном рабочем модуле 224 исполняют функции шлюза для следующих ресурсов:

IoPort 332 -> Порт 352 ввода/вывода (I/O);

IoMemory 334 -> Память 354 ввода/вывода (I/O);

IoDma 336 -> Канал 356 Прямого Доступа к Памяти (DMA);

IoIrq 338 -> Линия 358 Запроса на Прерывание (IRQ);

Endpoints 340 -> Средство Управления 312 Каналами.

В отличие от традиционных драйверов устройств файлы, содержащие исполняемые команды объектов 326 драйвера устройства, не включают в себя исполняемые команды для конфигурации драйвера устройства или для прямого доступа к аппаратным и другим вычислительным ресурсам, таким как те, что изображены под номером 350. Вместо этого исполняемая команда в объектах 326 драйвера устройства имеет доступ к аппаратным и другим вычислительным ресурсам только посредством доступа к объектам 332, 334, 336, 338 и 340, исполняемые команды которых содержатся в доверенном рабочем модуле 224.

Исполняемые команды, предназначенные для создания объекта 328 конфигурации и получения доступа к объектам 332, 334, 336 и 340, не включаются в файлы, предоставленные программистом драйвера устройства. Вместо этого программист драйвера устройства вставляет требования к конфигурации для драйвера устройства в качестве метаданных, прикрепленных к исполняемым командам. В одной или более описанных реализациях исполняемые команды, предназначенные для создания объекта 328 конфигурации и доступа к объектам 332, 334, 336, 338 и 340, являются обособленными и помещаются отдельно от исполняемых команд остальных объектов драйверов устройств.

В одной или более реализациях исполняемые команды, предназначенные для создания объекта 328 конфигурации, предоставляются операционной системой. В одной реализации эти исполняемые команды генерируются в момент инсталляции, используя шаблоны рефлексии момента компиляции (CTR). CTR-шаблоны обрабатывают требования к конфигурации, внедренные в виде метаданных в описание объекта конфигурации, закодированного в драйвере устройства. В другой реализации CTR-шаблоны обрабатывают манифест, части которого были созданы из конфигурационных метаданных в файлах, содержащих исполняемые команды для объектов 326 драйвера устройства. В другой реализации исполняемые команды, содержащиеся в доверенном рабочем модуле 224, создают объект конфигурации, интерпретируя либо конфигурационные метаданные, либо манифест драйвера устройства.

Примерная архитектура 200 ОС исполняет каждый драйвер устройства (такой, как драйвер 220) в отдельном программно-изолированном процессе (SIP). Примерная архитектура 200 ОС использует безопасность языка, чтобы удостоверяться в том, что ни один (SIP) не способен записывать информацию в страницы, принадлежащие другому SIP. Инкапсулированные в SIP-процессы отдельные драйверы при необходимости могут быть остановлены и перезапущены, не нарушая работы операционной системы в целом.

Программы для примерной архитектуры 200 ОС во время инсталляции статически привязываются к доверенным средам времени исполнения. Пока программы статически проверяются на безопасность типов, каждая среда времени исполнения является компонентом доверенной вычислительной основы их (TCB) системы. Исполняемые команды из доверенного объема времени исполнения поддерживают изоляцию процесса, позволяя процессам исполняться в привилегированном/супервизорском режиме главного процессора и не имея возможности влиять на ресурсы памяти и аппаратного обеспечения других процессов. В одной описанной реализации динамическая рефлексия или другие механизмы, которые могли бы обойти безопасность типов, не допускаются в исполняемых командах, предоставляемых программистом драйвера устройства.

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

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

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

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

В примерной архитектуре 200 ОС драйвер устройства декларирует свои требования к конфигурации ввода/вывода (I/O) и IPC. В традиционных подходах требования к конфигурации являются нераскрываемыми. Здесь требования к конфигурации кодируются в том же файле, что и исполняемые команды драйвера устройства. Закодированные требования к конфигурации могут быть конвертированы, для более легкой обработки, в отдельную спецификацию, которая декларирует требования к конфигурации.

Требования к конфигурации являются проверяемыми во время компиляции, во время инсталляции, в момент первоначальной загрузки и момент исполнения. В сущности, кодирование требований к конфигурации в тот же файл, ч