Конфигурация изолированных расширений и драйверов устройств
Изобретение относится к информационным технологиям точнее к конфигурации изолированных расширений и драйверов устройств. Техническим результатом является уменьшение вероятности возникновения ошибок, за счет предотвращения конфликтов. Способ содержит: получение нового драйвера устройства; определение набора вычислительных ресурсов, требуемых для исполнения упомянутого набора исполняемых команд нового драйвера устройства; сравнивают набор вычислительных ресурсов, требуемых новым драйвером устройства, с набором ресурсов, используемым всеми другими драйверами устройств, и выполняют проверку на предмет конфликтов в смысле перекрывания ресурсов; и только если нет никаких конфликтов между новым драйвером устройства и упомянутыми всеми другими драйверами устройств, устанавливают новый драйвер устройства. 3 н. и 5 з.п. ф-лы, 4 ил.
ПРЕДШЕСТВУЮЩИЙ УРОВЕНЬ ТЕХНИКИ
Программные системы, такие как операционная система, обычно снабжены набором предопределенных программных модулей для исполнения различных задач. Эти модули ассоциированы друг с другом, так как все они являются частью одного и того же предопределенного набора.
Однако часто требуются дополнительные функциональные возможности и/или конфигурирование на индивидуальной основе. Другими словами, функциональные возможности расширяются. Обычно программные системы предусматривают расширение обеспечением динамического добавления новых программных модулей или процессов. Эти добавления часто называются «расширениями» или «подключаемыми программами». Общие примеры расширений или подключаемых программ в традиционных системах включают в себя, но не в качестве ограничения, драйверы устройств для операционных систем, расширенные хранимые процедуры в базах данных, подключаемые программы и компоненты технологии 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. В традиционных подходах требования к конфигурации являются нераскрываемыми. Здесь требования к конфигурации кодируются в том же файле, что и исполняемые команды драйвера устройства. Закодированные требования к конфигурации могут быть конвертированы, для более легкой обработки, в отдельную спецификацию, которая декларирует требования к конфигурации.
Требования к конфигурации являются проверяемыми во время компиляции, во время инсталляции, в момент первоначальной загрузки и момент исполнения. В сущности, кодирование требований к конфигурации в тот же файл, что и драйвер устройства, превращает его в артефакт с самоописанием. При наличии набора MSIL-конструкций для драйвера устройства ОС может иметь полное представление о следующих условиях конфигурации (и зависимостях от ресурсов как программного, так и аппаратного обеспечения), которые должны быть удовлетворены, чтобы драйвер устройства функционировал корректно.
С абстракцией приложения и декларациями конфигурации драйвера примерная архитектура 200 ОС может предоставить гарантии относительно ресурсов ввода/вывода (I/O) и IPC, используемых драйвером устройства. Например, ОС может обнаружить конфликты конфигурации до исполнения драйвера, сравнивая набор ресурсов, необходимых драйверу нового устройства, с набором ресурсов, используемых всеми другими драйверами устройств, и препятствуя перекрытию и, таким образом, конфликтованию ресурсов, таких как диапазоны портов ввода/вывода или памяти ввода/вывода. В предпочтительном варианте осуществления конфликты конфигурации обнаруживаются во время инсталляции, а инсталляция разрешается, только если нет конфликтов между драйвером нового устройства и остальной системой, включая все ранее установленные драйверы устройств.
В качестве другого примера ОС может создать допустимый порядок полной начальной загрузки - порядок, в котором драйверы устройств инициализируются, извлекая из каждого драйвера устройства его конфигурационные зависимости, затем сортируя список таким образом, чтобы ни один драйвер устройства не был инициализирован раньше тех, от которых он зависит. Автоматическое создание допустимого порядка полной начальной загрузки системы является значительным преимуществом над предыдущими системами, где порядок начальной загрузки либо жестко закодирован в ОС во время разработки, либо где порядок загрузки обновляется вручную администратором. Так как последний пример гарантий получен из требований декларативной конфигурации, ОС способна генерировать все исполняемые команды для инициализации драйвера, относящиеся к конфигурации драйвера и получению ресурсов. По существу, ОС может гарантировать, что драйверы используют только заявленные ресурсы и что получение ресурсов осуществляется в соответствии с политиками системы. Эти возможности увеличивают надежность и удобство сопровождения системы с незначительными издержками производительности во время исполнения.
Конфигурация Драйвера Устройства
В отличие от традиционных подходов, в одной или более реализациях, описанных в материалах настоящей заявки, координатор 214 драйвера устройства не допускает, чтобы драйвер осуществлял доступ к несоответствующим участкам памяти или другим ресурсам аппаратного обеспечения. Наоборот, координатор драйвера устройства позволяет драйверу осуществлять доступ только к соответствующим участкам памяти и другим ресурсам аппаратного обеспечения. Более того, вместо того, чтобы предоставить драйверу прямой доступ к аппаратному обеспечению и ресурсам (что допускают традиционные подходы), ядро 210 проверяет возможность доступа драйвера к аппаратному обеспечению и ресурсам.
Одна или более реализаций, описанных в материалах настоящей заявки, имеют систему ввода/вывода (I/O), состоящую из трех уровней: HAL 214, менеджер 211 ввода/вывода (I/O) и драйверы 220. Уровень Аппаратных Абстракций (HAL) 214 является небольшой основой доверенных исполняемых команд, которая абстрагирует доступ к аппаратному обеспечению компьютера. Например, в одном варианте осуществления HAL реализован в виде четырех объектов доступа для работы с аппаратным обеспечением: объект 332 IoPort для доступа к порту 352 ввода/вывода (I/O) (также известный, как I/O регистр), объект 334 IoMemory для доступа памяти 354 ввода/вывода, объект 336 IoDma для доступа к DMA-контроллеру 356 и объект 338 IoIrq для доступа к линии 358 запроса на прерывание. В одном осуществлении HAL 314 также включает в себя исполняемую команду для контроллера таймера, контроллера прерывания и аппаратного обеспечения часов реального времени. Менеджер ввода/вывода 211 является ответственным за инициализацию драйверов устройств и связывание приложений с драйверами 220 устройств.
Ядро 210 использует либо непосредственно конфигурационные метаданные драйвера 220 устройства, либо манифесты для каждого драйвера устройства (например, манифест 142 процесса, изображенный на фиг.1), чтобы сконфигурировать драйверы 220 устройств и связать ресурсы, необходимые для корректного исполнения. В момент запуска ядро 210 осуществляет конфигурацию системы по принципу автоматического распознавания и конфигурирования подключенных устройств (Plug'n'Play). Ядро 210 использует информацию, полученную загрузчиком операционной системы из BIOS и от шин, таких как PCI-шина, чтобы определить доступные устройства, запустить соответствующие драйверы устройств и передать собранную информацию объектам драйверов, которые инкапсулируют доступ к аппаратному обеспечению устройства.
Каждый драйвер 220 пишется с использованием безопасных исполняемых команд и исполняется в своем собственном процессе. Драйверы взаимодействуют с другими частями системы, включая сетевой стек и файловую систему, исключительно посредством каналов. Когда драйвер стартует, менеджер 211 ввода/вывода, в соответствии с предписанием манифеста драйвера 220 устройства, предоставляет объекты 332, 334, 336 и 338 доступа ввода/вывода для взаимодействия с аппаратными средствами 352, 354, 356 и 358 устройства. Все эти объекты доступа обеспечивают безопасный интерфейс, который проверяет каждую ссылку до предоставления прямого доступа к отображаемым ячейкам памяти аппаратного обеспечения.
В одном варианте осуществления, использующем программную изоляцию, исполняемая команда для объектов доступа ввода/вывода полностью содержится в доверенном объекте 324 времени исполнения и исполняется в рамках процесса 300 драйвера устройства. Проверки с целью убедиться в том, что доступ к аппаратному обеспечению является правомерным, выполняются исполняемыми командами, расположенными в объектах 332, 334, 336 и 338 доступа ввода/вывода и в доверенном объекте 224 времени исполнения. В другом варианте осуществления, использующем аппаратную изоляцию, аппаратное обеспечение процессора, используемое для изоляции процесса, программируется для того, чтобы предоставить драйверу устройства доступ только к определенным областям пространства портов ввода/вывода или пространства памяти ввода/вывода, к которым драйверу был разрешен доступ. В варианте осуществления, использующем аппаратную изоляцию, исполняемые команды, предназначенные для конфигурации аппаратного обеспечения, используемого для изоляции процесса, постоянно находятся внутри ядра 210 ОС.
Конфигурация Драйвера
Одна или более реализаций используют требования к конфигурации, закодированные в виде метаданных в системные компоненты, чтобы описать части системы, разъяснить, как они сочетаются друг с другом, и установить их поведенческое взаимодействие с другими частями системы. Метаданные описательно помечают каждый компонент системы, такой как ядро, приложение или драйвер устройства, и его требования к конфигурации. Требования к конфигурации включают в себя информацию о зависимостях, экспортированных службах и ресурсных требованиях. Сервисные средства используют эти метаданные до исполнения системы, чтобы удостовериться в том, что исполняемые команды системного компонента могут быть корректно сконфигурированы. Эти метаданные используются в процессе исполнения системы, чтобы сконфигурировать каждый компонент системы настолько корректно, чтобы он мог исполняться, как было задумано создавшим его программистом.
Системные метаданные архивируются в одном или более системных хранилищах, называемых манифестами. Системный манифест верхнего уровня указывает на манифесты, описывающие индивидуальные компоненты (такие как драйверы устройств). Посредством этих манифестов программные продукты, такие как загрузчик операционной системы или системный верификатор, могут обнаружить каждый компонент системы.
Системные манифесты являются достаточным источником информации для проведения анализа системы в автономном режиме. С реализациями, описанными в материалах настоящей заявки, администратор способен найти ответ на множество вопросов, относящихся к «драйверу устройства», используя только описания аппаратных устройств и системный манифест. Такие вопросы включают в себя, например: «Будет ли система загружаться на каком-то особенном аппаратном оборудовании, какие драйверы и службы будут инициализироваться, и какие приложения могут исполняться?»
Спецификация
Работоспособный образ системы содержит требования к конфигурации для целой системы, вставленные в виде метаданных. Используя эти метаданные, одна или более описанных реализаций поддерживают три инварианта. Первый - ОС никогда не установит драйвер устройства, который не сможет успешно стартовать из-за требований к конфигурации, которые конфликтуют с другим драйвером или другой частью системы. Второй - ОС никогда не запустит драйвер устройства, который не может успешно исполняться либо из-за конфигурационных конфликтов, либо из-за отсутствующих ресурсов. Третий - драйвер устройства не может использовать ресурсы во время исполнения, которые не были задекларированы в его требованиях к конфигурации.
Где это возможно, одна или более реализаций, описанных в материалах настоящей заявки, используют специальные атрибуты метаданных в высокоуровневых языках, чтобы чередовать требования к конфигурации с исходным кодом, так чтобы только один исходный документ должен был бы поддерживаться. Специальные атрибуты могут быть присоединены к исходному коду сущностей, таких как класс, метод или объявления полей. Компилятор кодирует атрибуты в файл, содержащий результирующие исполняемые команды на промежуточном языке. Компиляторы, компоновщики, инсталляционные и верификационные сервисные средства могут читать метаданные, закодированные в исполняемые команды, даже если они не исполняют команды.
В качестве примера, нижеприведенный исходный код показывает некоторые атрибуты, используемые, чтобы объявить требования к конфигурации драйвера видеоустройства (такого как драйвер видеокарты S3TMTrio64™):
Атрибуты [DriverCategory] и [Signature] объявляют этот модуль как драйвер устройства для специфического класса видеоустройств PCI. DriverCategory обозначает категорию приложений, которые реализуют драйверы устройств для специфического аппаратного оборудования. Другие категории включают в себя ServiceCategory для приложений, реализующих программные службы, и WebAppCategory для расширений к Web-серверу.
Атрибут [IoMemoryRange] объявляет, что frameBuffer извлекается из первого элемента конфигурационного пространства PCI-устройства. Это расположение буфера кадра определяется, когда аппаратное обеспечение конфигурируется, а параметры аппаратного обеспечения, такие как размер диапазона памяти, должны быть совместимы с конфигурационными значениями атрибута. Атрибуты [IoFixedMemoryRange] и [IoFixedPortRange] предписывают, что драйверу требуется либо фиксированный диапазон адресного пространства для доступа к отображаемой памяти, либо фиксированный диапазон портов ввода/вывода для доступа к регистрам устройства.
В этом варианте осуществления объекты IoDmaRange, IoIrqRange IoMemoryRange и IoPortRange являются контейнерами для совокупностей объектов последовательного доступа и могут быть использованы попеременно с объектами доступа IoDma, Iolrq, IoMemory и IoPort соответственно.
Атрибут [ExtensionEndpoint] объявляет, что драйвер должен быть сконфигурирован с конечной точкой канала, чтобы взаимодействовать с родительским процессом драйвера. В случае с драйверами устройств, такими как S3TMTrio64™, родительским процессом является система ввода/вывода.
Атрибуты [ServiceEndpoint] объявляют, что драйвер должен быть сконфигурирован с конечной точкой канала к системной службе каталогов, и что приложения, использующие видеодрайвер, будут направляться к драйверу устройства службой каталогов через его конечную точку.
Время Компиляции
Во время компиляции компилятор высокоуровнего языка вставляет специальные атрибуты в виде метаданных в файл, содержащий исполняемые команды промежуточного языка для драйвера устройства. Используя библиотеку доступа к метаданным промежуточного языка, одна или более описанных реализаций могут извлекать вставленные метаданные из файла промежуточного языка (объектного файла) без исполнения исполняемых команд, содержащихся в этом файле.
Во время компоновки сервисное средство для создания манифеста считывает специальные атрибуты метаданных из файла промежуточного языка, чтобы создать манифест приложения. Манифест приложения является XML-файлом, перечисляющим компоненты и требования к конфигурации приложения. Манифесты приложения более детально описаны в «Самоописываемых Артифактах и Абстракциях Приложения».
Нижеприведенный XML код содержит часть информации манифеста для драйвера видеоустройства (такого, как драйвер видеоустройства S3TMTrio64™):
Время Установки
В одной или более реализациях, описанных в материалах настоящей заявки, система гарантирует, что драйвер, который не может запуститься, не будет установлен. Чтобы обеспечить это, система, перед установкой драйвера, проверяет, что требования к конфигурации драйвера могут быть полностью удовлетворены.
Приложение является абстракцией первого класса в ОС, поддерживающей одну или более реализаций, описанных в материалах настоящей заявки. Эта концепция более детально описана в «Самоописываемых Артифактах и Абстракциях Приложения». В одном варианте осуществления для того чтобы приложение могло исполняться, набор исполняемых команд добавляется к приложению инсталлятором, чтобы инициализировать приложение в соответствии с его требованиями к конфигурации. В альтернативной реализации исполняемые команды, предназначенные для инициализации приложения в соответствии с его требованиями к конфигурации, содержатся в доверенном объекте времени исполнения и создают объект конфигурации и объекты доступа, интерпретируя метаданные конфигурации приложения.
Инсталлятор начинает с метаданных, содержащихся в манифесте приложения. Инсталлятор удостоверяется в том, что каждая из сборок приложения существует и что она безопасна по типам и памяти. Также он проверяет, что все контракты каналов реализованы корректно.
Как только эти внутренние свойства разрешаются и удостоверены, следующим шагом инсталлятор пытается разрешить и проверить все внешние зависимости. Например, инсталлятор убеждается в том, что любые ресурсы аппаратного обеспечения, используемые драйвером устройства, не конфликтуют с ресурсами аппаратного обеспечения, затребованными любым другим драйвером. Инсталлятор также удостоверяется в наличии каждого типа канала, используемого приложением. Если приложение экспортирует канал, инсталлятор проверяет, что экспортируемый канал не конфликтует с другим приложением. Когда возникают конфликты, политика системного манифеста позволяет решить их. Например, манифест мог бы объявить, что только один драйвер устройства может обеспечивать контракт видеоконсоли. Установка дополнительных видеодрайверов может быть запрещена или только один драйвер может быть активирован во время начальной загрузки системы.
Рефлексия Времени Компиляции (CTR) используется, чтобы сгенерировать доверенную исполняемую команду для инициализации конфигурационного объекта и объектов доступа приложений для системных ресурсов. В одном варианте осуществления CTR-шаблоны во время инсталляции исполняют обработку приписанных программных элементов в сборках, указанных в манифесте приложения.
Процесс инсталляции завершается обновлением метаданных системного манифеста, чтобы включить в состав новое приложение или новый драйвер устройства.
Как минимум в одной реализации весь процесс инсталляции происходит автономно, инсталляция становится видимой только при следующей загрузке системы. В качестве альтернативы, весь процесс инсталляции может исполняться в режиме он-лайн и/или частично в режиме он-лайн.
Время Исполнения
Во время исполнения метаданные управляют инициализацией ядра, драйверов устройств, служб и приложений. Загрузчик операционной системы считывает части системного манифеста, чтобы определить, какое ядро, драйверы устройств и службы необходимо загружать. Порядок, в котором эти загрузки и запуски исполняются, нигде не указан: вместо этого система сама определяет его, исходя из заданных зависимостей.
По мере запуска каждого приложения ядро проверяет и разрешает все зависимости метаданных и создает запись конфигурации процесса в ядре. Доверенные исполняемые команды, порожденные в приложении посредством CTR, выполняют разбор конфигурационной записи, чтобы создать объект 328 конфигурации и создать объекты 332, 334, 336, 338 и 340 доступа для доступа к внешним ресурсам. Рефлексия Времени Компиляции (CTR) генерирует исполняемые команды для объекта 428 конфигурации.
Возвращаясь к примеру драйвера устройства S3TMTrio64™, ядро записывает в запись конфигурации драйвера потребность в объектах IoMemoryRange, frameBuffer, textBuffer и fontBuffer. Ядро также записывает объекты IoPortRange для портов ввода/вывода control, advanced и gpstat. Ядро создает канал для соединения драйвера устройства с подсистемой ввода/вывода и второй канал, чтобы соединить драйвер с пространством имен. Конечные точки канала добавляются в запись конфигурации драйвера.
Когда драйвер устройства начинает исполняться, исполняемые команды в доверенной среде времени исполнения создают соответствующие объекты доступа IoMemoryRange и IoPortRange в объектном пространстве драйвера. Так они могут быть построены только посредством доверенного объекта времени исполнения, драйвер устройства может осуществлять доступ только к ресурсам ввода/вывода, объявленным в его конфигурационных метаданных и проверенным на наличие конфликтов ядром подсистемы ввода/вывода.
Объявление конечных точек канала в конфигурационных метаданных гарантирует три свойства. Первое - исполняемые команды для SIP могут быть проверены статически, чтобы гарантировать, что они обмениваются информацией только через полностью объявленные каналы в строгом соответствии с контрактами каналов. Второе - приложения не обязаны содержать глобальные имена. Например, драйвер видеокарты S3™Trio64™ не осведомлен об имени /dev/video в системном пространстве имен. Вместо этого драйвер использует локальное имя S3Trio64Config.video, чтобы ссылаться на канал с заданным контрактом (ServiceProviderContract). Совокупную компоновку пространства имен ввода/вывода можно изменить, не воздействуя ни на одну строку в исходном коде видеодрайвера. Третье - приложения могут быть помещены в «песочницу» (ограниченную среду) в соответствии с принципом наименьшей возможной привилегии, чтобы удалить источник ошибки и уязвимость в безопасности в текущих системах. Например, хотя драйвер S3™Trio64™ удерживает конечную точку, присоединенную к системной службе каталогов, этот драйвер не имеет возможности создавать новые имена или подсоединяться к любому другому системному процессу.
Методологическая Реализация Изолированных Драйверов Устройств
Фиг.4 демонстрирует способ 400 инициализации любого расширения (такого, как драйвер устройства). С помощью этого способа 400 ОС считывает метаданные из манифеста драйвера устройства, чтобы создать объект драйвера устройства. Этот способ 400 исполняется одним или более различными компонентами, как изображено на фиг.1. Более того, этот способ 400 может быть исполнен в программном или аппаратном обеспечении, во встроенном программно-аппаратном обеспечении или их комбинации.
На этапе 402 по фиг.4 операционная система (ОС) получает недоверенный программный модуль (такой как драйвер устройства). ОС определяет набор требуемых или запрашиваемых вычислительных ресурсов из манифеста драйвера устройства. Здесь вычислительные ресурсы могут включать в себя виртуальные ресурсы (такие как канал) или аппаратные ресурсы (такие как диапазон портов ввода/вывода или памяти ввода/вывода) или другие подобные ресурсы.
ОС может выполнить это определение, считывая манифест драйвера устройства. В качестве альтернативы ОС может анализировать исполняемые команды драйвера устройства. В качестве еще одной альтернативы ОС может извлекать метаданные из исполняемых команд или ассоциированной структуры данных.
На этапе 404 ОС определяет, выделен ли уже какой-либо из этих ресурсов для ОС или другого драйвера устройства. Если так, процесс прекращается на этапе 406. Альтернативные варианты осуществления изобретения могли бы сопровождать прекращение дополнительной стратегией, такой как перезапуск процесса инициализации после того, как ресурсы были высвобождены, согласование с текущим владельцем на предмет высвобождения ресурсов, запрашивание у пользователя разрешения на остановку конфликтующего драйвера, оповещение автора драйвера устройства о потенциально неправильном запросе ресурса и так далее.
Также здесь ОС может принять другое решение, относящееся к драйверу устройства и запрошенным вычислительным ресурсам. ОС подтверждает, что драйверу устройства разрешается осуществить доступ к тем запрашиваемым вычислительным ресурсам и осуществить к ним доступ таким способом, которым он запрашивает.
На этапе 408 ОС регистрирует выделение ресурсов драйверу устройства.
На этапе 410 ОС предоставляет доверенный объект локального доступа, который должен использоваться драйвером устройства, для каждого требуемого или запрошенного ресурса. Доверенные объекты времени исполнения (изображенные на фиг.3) являются примерами объектов локального доступа.
«Обеспечение» того, что ОС исполняет здесь, может включать в себя простое использование предварительно установленных и зафиксированных исполняемых команд (и данных), которые являются объектами локального доступа. Это может включать в себя генерацию новых команд (возможно, основываясь на шаблоне), которые конфигурируются под индивидуальные потребности и условия. Или ОС может делать что-то среднее между этими двумя возможностями. Например, она может конфигурировать или немного изменять исполняемые команды, которые являются объектами локального доступа.
Конечно, ОС может вставить или привязать исполняемые команды (и данные) доверенного объекта локального доступа к недоверенному драйвером устройству так, чтобы драйвер устройства мог получить доступ через вставленный или привязанный объект локального доступа.
На этапе 412 ОС инициализирует объект конфигурации устройства, используя набор объектов локального доступа для требующихся ресурсов. Объект конфигурации может включать в себя дополнительные установки, заданные в манифестах. Примером дополнительных установок была бы установка, сообщающая сортирующему расширению предпочтительный для пользователя формат даты и времени.
На этапе 414 ОС инициирует исполнение исполняемых команд драйвера устройства. Исполняемые команды, предназначенные для инициализации драйвера, предоставляются операционной системой или системой инсталляции, а не программистом драйвера устройства.
На этапе 416 исполняющийся драйвер устройства осуществляет доступ к затребованным вычислительным ресурсам через объекты локального доступа. Более того, исполняющийся драйвер устройства может осуществить доступ только к затребованным вычислительным ресурсам (не к другим) и только через привязанные или вставленные объекты локального доступа.
Вывод
Методики, описанные в материалах настоящей заявки, могут быть реализованы множеством способов, включая (но не в ограничительном смысле) программные модули, вычислительные системы общего и специального назначения, сетевые серверы и оборудование, специальное электронное оборудование и аппаратное обеспечение, встроенное программно-аппаратное обеспечение, как часть одной или более вычислительных сетей, и/или комбинации вышеперечисленного.
Хотя одна или более вышеописанных реализаций были описаны на языке, характерном для структурных признаков и/или методологических этапов, необходимо понимать, что другие реализации могут применяться без характерных примерных признаков или этапов, описанных в материалах настоящей заявки. Точнее, характерные примерные признаки и этапы раскрываются как предпочтительные формы одной или более реализаций. В некоторых случаях широко известные признаки могли быть опущены или упрощены для внесения ясности в описание примерных реализаций. Более того, для облегчения понимания определенные этапы способов схематически изображены как отдельные этапы, однако эти схематически изображенные этапы не должны интерпретироваться в качестве непременно зависимых от очередности при их исполнении.
1. Способ обнаружения конфликтов конфигурации между драйверами устройств до исполнения этих драйверов устройств, содержащий этапы, на которых:
получают новый драйвер (300) устройства, который является набором исполняемых команд;
определяют набор вычислительных ресурсов (312, 350), требуемых для исполнения упомянутого набора исполняемых команд нового драйвера (300) устройства;
сравнивают набор вычислительных ресурсов, требуемых новым драйвером устройства, с набором ресурсов, используемым всеми другими драйверами устройств, и выполняют проверку на предмет конфликтов в смысле перекрывания ресурсов; и
только если нет никаких конфликтов между новым драйвером устройства и упомянутыми всеми другими драйверами устройств,
устанавливают новый драйвер устройства,
предоставляют посредством операционной системы один или более объектов (332, 333, 336, 338, 340) локального доступа, ассоциированных с требуемым набором вычислительных ресурсов, причем новому драйверу (300) устройства разрешено осуществлять доступ к требуемому набору вычислительных ресурсов (312, 350) только используя эти один или более объектов локального доступа, при этом каждый из упомянутых одного или более объектов (332, 333, 336, 338, 340) локального доступа содержит исполняемые команды, и
инициируют выполнение упомянутого набора исполняемых команд нового драйвера (300) устройства и исполняемых команд упомянутых одного или более объектов (332, 333, 336, 338, 340) локального доступа.
2. Способ по п.1, в котором на этапе определения получают читаемый процессором манифест (142), ассоциированный с новым драйвером (300) устройства, причем этот манифест (142) драйвера устройства задает упомянутый набор вычислительных ресурсов (312, 350), требуемых для исполнения упомянутого набора исполняемых команд нового драйвера (300) устройства.
3. Способ по п.1, дополнительно содержащий этап, на котором подтверждают, что новый драйвер (300) устройства уполномочен на доступ к требуемому набору вычислительных ресурсов (312, 350).
4. Способ по п.1, в котором на этапе предоставления генерируют один или более объектов (332, 333, 336, 338, 340) локального доступа для использования новым драйвером (300) устройства для доступа к требуемому набору вычислительных ресурсов (312, 350).
5. Способ по п.1, в котором новый драйвер устройства является недоверенным программным модулем, а упомянутые объекты локального доступа являются доверенными объектами локального доступа.
6. Способ по п.5, в котором на этапе предоставления дополнительно конфигурируют исполняемые команды упомянутых одного или более доверенных объектов локального доступа, чтобы предоставить недоверенному программному модулю доступ к упомянутым вычислительным ресурсам через сконфигурированные исполняемые команды упомянутых одного или более доверенных объектов локального доступа.
7. Читаемый процессором носитель, содержащий исполняемые процессором команды, которые при их исполнении процессором предписывают процессору выполнять способ по одному из пп.1-6.
8. Компьютерная система для обнаружения конфликтов конфигурации между драйверами устройств, содержащая средства, выполненные с возможностью осуществлять способ по одному из пп.1-6.
