СИСТЕМА И СПОСОБ ДЛЯ ЗАЩИТЫ ОТ НЕДОВЕРЕННОГО КОДА РЕЖИМА УПРАВЛЕНИЯ С СИСТЕМОЙ С ПОМОЩЬЮ ПЕРЕАДРЕСАЦИИ ПРЕРЫВАНИЯ РЕЖИМА УПРАВЛЕНИЯ СИСТЕМОЙ И СОЗДАНИЯ КОНТЕЙНЕРА ВИРТУАЛЬНОЙ МАШИНЫ Российский патент 2007 года по МПК G06F9/48 

Область техники, к которой относится изобретение

Данное описание имеет отношение, в общем случае, к микропроцессорным системам и, более определенно, к микропроцессорным системам, которые могут работать в доверенной или защищенной среде.

Предшествующий уровень техники

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

Часто имеет место, что коммерческое программное обеспечение не является полностью пригодным для специфического аппаратного набора изготовителя комплектного оборудования (OEM). Из-за неправильного понимания спецификации или ошибок реализации могут возникнуть ситуации, когда программное обеспечение пытается обратиться к аппаратным средствам способом, не ожидаемым или не поддерживаемым аппаратными средствами. Простым примером может быть то, когда программа собирается поместить значение в регистр по адресу x, тогда как фактический регистр в аппаратных средствах находится по адресу x+y. Это может вызвать системное исключение.

Чтобы справляться с такими ситуациями, процессоры могут быть выполнены с возможностью поддержки режима работы, имеющего возможность функционировать прозрачным или квазипрозрачным образом в отношении операционной системы, либо образом, независимым от уровня привилегий, для выполнения программ-исправлений (патчей) нижнего уровня. Для целей представленного изобретения такой режим может быть определен как «режим нижележащего по отношению к операционной системе уровня» или иначе «режим ниже операционной системы». Одним таким режимом является режим управления системой (SMM) семейства процессоров Intel® Pentium® и совместимых процессоров (см. главу 14 Pentium® 4 Processor Software Developer's Manual, Vol.I11, 2001 edition, order number 245472, доступное у Intel Corporation of Santa Clara, California). Другие режимы ниже операционной системы могут существовать в процессоре архитектуры MIPS Technologies® MIPS32™ или MIPS64™, в процессоре архитектуры IBM® PowerPC™, в процессоре архитектуры SPARC International® SPARC® или во многих других процессорах. Существование режима ниже операционной системы может обеспечивать дополнительные преимущества для системы, такие как поддержка переходов в режим выключения питания. Чтобы учесть несогласованность программного обеспечения и оборудования, как описано выше, существующие реализации режима ниже операционной системы могут не иметь никаких ограничений по привилегиям или ограничений по отображению адресов. Режимы ниже операционной системы могут быть активированы специализированным прерыванием режима ниже операционной системы, иногда генерируемым системным встроенным программным обеспечением или системными аппаратными средствами. Это специализированное прерывание режима ниже операционной системы обычно разрабатывается как немаскируемое для того, чтобы отреагировать на острую необходимость, которая потребовала перехода в данный режим.

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

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

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

Перечень фигур чертежей

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

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

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

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

Фиг.4 - диаграмма, показывающая код режима управления системой, работающий в контейнере виртуальной машины, согласно одному варианту воплощения данного изобретения.

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

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

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

Подробное описание

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

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

В иллюстративном случае, где режим ниже операционной системы является режимом управления системой (SMM), исполнение кода SMM в доверенной или защищенной среде может начаться посредством первоначального направления прерывания режима управления системой (SMI) в обработчик в защищенном мониторе виртуальных машин (SVMM). Это направление в обработчик может быть достигнуто посредством разрешения SVMM считывать из и записывать в базовый регистр (PSMBASE) управления системой (SMBASE) в процессоре. SMI будет тогда переадресовано к коду SMM, расположенному в виртуальной машине (VM), которая находится под защищенным управлением SVMM. Альтернативно, архитектура виртуализации процессора может заблокировать использование регистра PSMBASE и вызвать переадресацию всех SMI к SVMM непосредственно.

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

Обратимся теперь к фиг.1, на которой показано соответствующее одному варианту осуществления отображение памяти для кода режима управления системой (SMM) в памяти с произвольным доступом управления системой (SMRAM). Во время нормальной инициализации системы раздел системной памяти 110 с произвольным доступом (RAM) может быть оставлен для исключительного использования кодом SMM. Этот обособленный раздел называют памятью с произвольным доступом управления системой (SMRAM). На конкретные ячейки памяти в пределах SMRAM могут указывать регистры обслуживания прерывания в наборе микросхем или процессоре, которые в одном варианте воплощения называют базовыми регистрами управления системой (SMBASE).

Содержимое CSMBASE регистра SMBASE набора микросхем может задавать границы SMRAM. Например, SMRAM может занять пространство между CSMBASE (120) и CSMBASE+FFFF hex (132). В других вариантах воплощения, чтобы поддерживать одновременное исполнение кода SMM двумя или более процессорами, каждый процессор может иметь свое собственное, выделенное пространство SMRAM. Содержимое PSMBASE регистра SMBASE процессора может задавать точки входа кода и ячейки сохранения состояния, в пределах SMRAM. Например, в пределах SMRAM стандартная точка входа кода может быть расположена по адресу CSMBASE+8000 hex (124). Значение CSMBASE может быть записано при инициализации системы в регистр SMBASE каждого процессора, таким образом позволяя каждому процессору переходить в точку входа кода SMM после приема SMI. До входа в код SMM процессор может, в одном варианте воплощения, сохранять данные состояния в области сохранения состояния между адресом PSMBASE+FEOO hex (128) и концом SMRAM в ячейке SMBASE+FFFF hex (132). В других вариантах воплощения, для того, чтобы поддерживать два или более процессоров, исполняющих код SMM одновременно, регистр SMBASE каждого процессора может содержать отличающееся от других значение PSMBASE, обеспечивая отличающиеся точки входа кода и ячейки для сохранения данных состояния.

Данные состояния могут включать в себя значения регистров управления, флажки, поле автоматического перезапуска с остановом поле команды перезапуска ввода/вывода (I/O) и идентификатор версии SMM. Некоторые из ячеек в пределах SMRAM могут быть изменены обработчиком SMI. После завершения исполнения кода SMM, может быть осуществлен повторный вход в первоначальную программу, когда процессор исполняет команду возобновления (RSM). Эта существующая команда RSM может только быть выдана в SMM, и она восстанавливает значения состояний, ранее сохраненные в SMRAM. Использование этой существующей схемы SMM широко известно в данной области техники.

Обратимся теперь к фиг.2, на которой показана диаграмма иллюстративной доверенной или защищенной программной среды, согласно одному варианту воплощения данного изобретения. В варианте воплощения по фиг.2 доверенное и недоверенное программное обеспечение может быть загружено одновременно и может исполняться одновременно на одной компьютерной системе. SVMM 250 выборочно разрешает или запрещает прямой доступ к аппаратным ресурсам 280 из недоверенной операционной системы 240 (или, если реализовано множество незащищенных виртуальных машин, из множества операционных систем) и недоверенных приложений 210-230. В этом контексте, «недоверенные» не обязательно подразумевает, что операционная система или приложения преднамеренно ведут себя ненадлежащим образом, но что размер и разнообразие взаимодействующего кода делают практически невозможным достоверно утверждать, что программное обеспечение ведет себя так, как это желательно, и что нет никаких вирусов или другого инородного кода, мешающего его выполнению. В типичном варианте воплощения, недоверенный код может состоять из нормальной операционной системы и приложений, характерных для современных персональных компьютеров.

SVMM 250 также выборочно разрешает или запрещает прямой доступ к аппаратным ресурсам 280 со стороны одного или более доверенных или защищенных ядер 260 и одного или более доверенных приложений 270. Такое доверенное или защищенное ядро 260 и доверенные приложения 270 могут быть ограничены по размеру и функциональным возможностям для того, чтобы быть способными исполнить анализ степени доверия. Доверенное приложение 270 может быть любым программным кодом, программой, процедурой или набором процедур, которые являются исполняемыми в защищенной среде. Таким образом, доверенное приложение 270 может представлять собой разнообразие приложений или последовательностей кодов, либо может представлять собой относительно небольшое приложение типа аплета Java.

Команды или операции, обычно выполняемые операционной системой 240 или ядром 260, которые могут изменять степень защиты или привилегии системных ресурсов, могут быть перехвачены SVMM 250 и выборочно разрешены, частично разрешены или отклонены. Как пример, в типичном варианте воплощения команды, которые изменяют таблицу страниц процессора и которые обычно исполняются операционной системой 240 или ядром 260, будут вместо этого перехвачены SVMM 250, который гарантирует, что запрос не пытается изменять привилегии в отношении страницы вне области ее виртуальной машины. Один из способов рассматривать эту систему состоит в том, что операционная система 240, ядро 260 и SVMM 250 все являются виртуальными машинами, при этом виртуальная машина операционной системы 240 и виртуальная машина ядра 260 исполняются в виртуальной машине SVMM 250. Таким образом, создана иерархия виртуальных машин. Здесь, в одном варианте воплощения, виртуальная машина может быть определена как любая многопользовательская операционная система с совместным использованием ресурсов, которая дает каждому пользователю впечатление монопольного управления всеми ресурсами системы, либо виртуальная машина может также быть определена как операционная система, управление которой в свою очередь осуществляет лежащая в основе управляющая программа.

Обратимся теперь к фиг.3, на которой показан один вариант воплощения системы микропроцессора 300, выполненной с возможностью поддержки защищенной программной среды по фиг.2. Центральный процессор А 310, центральный процессор В 314, центральный процессор С 318 и центральный процессор D 322 могут быть сконфигурированы с дополнительным микрокодом или дополнительной логической схемой для того, чтобы поддерживать исполнение специальных команд. В одном варианте воплощения, процессоры могут быть микропроцессорами класса Intel® Pentium® с некоторыми специальными модификациями в соответствии с вариантом воплощения данного изобретения. Эти специальные команды могут поддерживать выдачу специальных шинных сообщений на системной шине 320, которые могут обеспечить надлежащую синхронизацию функционирования SVMM 250 в процессорах. Аналогично, набор микросхем 330 может поддерживать вышеупомянутые специальные циклы на системной шине 320. Число физических процессоров может измениться при реализации конкретного варианта воплощения.

В варианте воплощения по фиг.3 эти четыре процессора, центральный процессор А 310, центральный процессор В 314, центральный процессор С 318 и центральный процессор D 322, показаны как четыре отдельных аппаратных объекта. В других вариантах воплощения число процессоров может отличаться. Действительно, процессоры могут быть заменены отдельными потоками, каждый из которых исполняется на одном из физических процессоров. В последнем случае эти потоки обладают многими из атрибутов дополнительных физических процессоров. Для того чтобы иметь универсальное выражение для обсуждения, используя любую комбинацию множества физических процессоров и множества потоков на процессорах, выражение «логический процессор» может использоваться для описания либо физического процессора, либо потока, работающего на одном из физических процессоров. Таким образом, один однопоточный процессор можно рассматривать как логический процессор и многопоточные или мульти-ядерные процессоры можно рассматривать как множество логических процессоров.

Модификации процессоров могут включать в себя, в одном варианте воплощения, изменения в поведение регистров и новые или измененные команды. Например, в одном варианте воплощения, центральный процессор С 318 может включать в себя новую команду 324 защищенного входа (SENTER). Команда 324 SENTER после исполнения может обеспечить инициирование безопасных или доверенных операций, как показано выше на фиг.2. SENTER 324 может дать возможность множеству логических процессоров синхронизировать их вход в защищенные или доверенные операции. В одном варианте воплощения, SENTER 324 может также разрешить запись в регистр 316 PSMBASE.центрального процессора С 318, при некоторых обстоятельствах для того, чтобы поддержать защищенные или доверенные операции SMM.

В одном варианте воплощения центральный процессор С 318 может также включать в себя измененную команду 326 возобновления (RSM). Модифицированная 326 RSM может разрешить возврат из SMM, который поддерживает защищенные или доверенные операции. Обычно команды RSM могут быть исполнены только из SMM. Модифицированная 326 RSM может быть исполнена из нормального страничного режима при инициировании. С активированными расширениями VM, модифицированная команда 326 RSM может выполнить специальный системный вызов, называемый VMexit, обратно в обработчик SVMM для SMI.

Набор микросхем 330 может обслуживать запросы чтения и записи, переносимые от центральных процессоров по системной шине 320, и может затем выполнять физические операции чтения и записи в физической памяти 334. Распределению SMRAM в пределах памяти 334 может содействовать регистр 331 SMBASE набора микросхем, содержащий значение CSMBASE. Набор микросхем 330 дополнительно может подсоединяться к специализированным каналам ввода-вывода (I/O), таким, как усовершенствованный графический порт 336 (AGP). Набор микросхем 330 может управлять доступом к страницам памяти в пределах физической памяти 334 из процессоров, а именно центрального процессора 310 А, центрального процессора 314 В, центрального процессора 318 С и центрального процессора 322 D, и дополнительно из устройств ввода-вывода. Такие устройства могут включать в себя запоминающие устройства большой емкости типа несменных носителей 344 или сменных носителей 348. Несменные носители 344 или сменные носители 348 могут быть магнитными дисками, магнитной лентой, магнитными дискетами, магнитооптическими дисками, ПЗУ на компакт-диске (CD-ROM), ПЗУ на цифровом многофункциональном диске (DVD-ROM), платами Флэш-памяти, или многими другими формами запоминающих устройств большой емкости. Несменные носители 344 или сменные носители 348 могут быть подсоединены к набору микросхем 330 через шину 346 межсоединения периферийных устройств (PCI), или, альтернативно, через универсальную последовательную шину 342 (USB), шину встроенного интерфейса устройств (IDE) (не показанную здесь) или шину интерфейса малых компьютерных систем (SCSI) (не показанную здесь).

SVMM 364 может разрешить или отказать в доступе VM к определенным страницам в памяти 334. Страницы памяти, к которым VM лишена доступа, можно назвать «блокированными» страницами, тогда как страницы, к которым VM разрешен доступ, можно назвать «неблокированными» страницами. В блокированных страницах 360 памяти может быть расположен SVMM 364 и модули в SVMM 364 для поддержки защищенной работы SMM. В одном варианте воплощения, такие модули могут включать в себя обработчик 366 SMM из состава SVMM и обработчик 368 выхода из виртуальной машины (VMexit)/вызова виртуальной машины (VMcall). В других вариантах воплощения функции обработчика 366 SMM из состава SVMM и обработчика 368 VMexit/VMcall могут быть объединены или могут быть распределены среди других модулей. Другие страницы памяти могут оставаться неблокированными, как, например, неблокированные страницы 362 памяти. В неблокированных страницах 362 памяти могут быть расположены стандартные операционные системы 372. Также в неблокированных страницах 362 памяти может быть размещена виртуальная машина 370 SMM (VM SMM). VM 370 SMM может включать в себя код программного обеспечения, подобный стандартному коду SMM, но модифицированный для работы в контейнере виртуальной машины. Такие модификации в VM 370 SMM могут включать в себя код, подготовленный к исполнению в страничном режиме, а не в нормальном SMM.

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

Обратимся теперь к фиг.4, на которой показана диаграмма кода режима управления системой (SMM), работающего в контейнере виртуальной машины (VM), согласно одному варианту воплощения данного изобретения. В варианте воплощения на фиг.4, SVMM 450 имеет два дополнительных модуля для поддержки защищенных или доверенных операций SMM. Обработчик 452 SMM из состава SVMM вводит код SMM в VM 490 SMM в качестве реакции на исполнение команды SENTER. Обработчик 454 VMexit/VMcall обрабатывает вход в и выход из VM 490 SMM вследствие намеренно более низкого уровня привилегий VM 490 SMM в пределах его контейнера VM. В некоторых вариантах воплощения, обработчик 452 SMM из состава SVMM и обработчик 454 VMexit/VMcall могут быть одним и тем же программным модулем.

Обработчик 452 SMM из состава SVMM может исполнять несколько функций. Во время перехода к защищенным или доверенным операциям после исполнения процессором команды SENTER, обработчик 452 SMM из состава SVMM загружает и инициирует код VM 490 SMM в контейнере виртуальной машины. В некоторых вариантах воплощения, обработчик 452 SMM из состава SVMM должен затем записать ячейку входа в пределах самого себя в модифицированный регистр SMBASE каждого процессора в системе. Эта ячейка входа разрешает SMI быть направленным сначала 'в обработчик 452 SMM из состава SVMM. Это может быть необязательным для других вариантов воплощения, которые вызывают обработчик 454 VMexit/VMcall непосредственно в качестве реакции на прерывания режима управления системой; для этих вариантов воплощения, обработчик 452 SMM из состава SVMM и обработчик 454 VMexit/VMcall будут объединены в один программный модуль. Обработчик 452 SMM из состава SVMM также обеспечивает пространство в блокированных страницах памяти для хранения данных состояния, которые должны быть сохранены после входа в операции SMM. Примеры этих данных состояния обсуждались выше при обсуждении фиг.1. Размещение этих данных состояния в блокированных страницах памяти предотвращает несанкционированное раскрытие или манипулирование данными состояния.

Обработчик 454 VMexit/VMcall может выполнять несколько функций. Обработчик 454 VMexit/VMcall может обрабатывать входы в и выходы из VM 490 SMM, следующие за начальным входом. Обработчик 454 VMexit/VMcall может также обрабатывать исключения, возникающие, когда VM 490 SMM пытается считывать из или записывать в блокированные страницы памяти. Части обработчика 454 VMexit/VMcall могут определить, можно ли решить выполнение некоторых из этих операций чтения из или записи в блокированные страницы памяти в зависимости от обстоятельств. В одном варианте воплощения, операции чтения из или записи в блокированные страницы памяти можно разрешить, если обработчиком 454 VMexit/VMcall определено, что целевая ячейка в пределах блокированных страниц памяти не содержит доверенных данных.

VM 490 SMM содержит требуемый код SMM, модифицированный из формата режима SMM для исполнения в режиме доступа к страницам памяти. В общем, код SMM в VM 490 SMM исполняется так, как он написан, исключая случаи тех команд, которые осуществляют чтение и запись в блокированных страницах памяти. В этих случаях код SMM может вызвать обработчик 454 VMexit/VMcall. Код SMM может осуществить явный вызов обработчика 454 VMexit/VMcall или может осуществить опосредованный вызов, позволяя исключению быть перехваченным обработчиком 454 VMexit/VMcall. В любом случае обработчик 454 VMexit/VMcall обработает эти обстоятельства.

Обратимся теперь к фиг.5, на которой показана диаграмма переадресации прерывания режима управления системой, согласно одному варианту воплощения данного изобретения. Рассмотрим событие, приводящее к SMI, в аппаратных средствах 480, следующее за инициированием защищенных или доверенных операций. Процессор исследует свой регистр SMBASE. Так как обработчик 452 SMM из состава SVMM после инициализации записал ячейку внутренней памяти в модифицированный регистр SMBASE в процессоре, процессор начинает исполнение обработчика 452 SMM из состава SVMM. Обработчик 452 SMM из состава SVMM сохраняет данные состояния в блокированной странице памяти, а затем выполняет вызов входа в виртуальный режим (VMenter) для фактического кода SMM в VM 490 SMM. В другом варианте воплощения, SMI может осуществить вызов обработчика VMexit из состава SVMM.

Код SMM в VM 490 SMM исполняется до тех пор, пока он не попытается считать из или записать в ячейку памяти в пределах блокированной страницы памяти. Тогда или явным запросом, или исключением, вызывающим системное прерывание, может быть выполнен VMexit/VMcall 524 для вызова обработчика 454 VMexit/VMcall. Обработчик 454 VMexit/VMcall осуществляет эти доступы к памяти, которые он считает допустимыми, а затем возвращается в VM 490 SMM посредством еще одного VMenter 522. Этот процесс может повторяться несколько раз, пока требующийся код SMM в VM 490 SMM не завершится. В это время код SMM осуществляет выход посредством заключительного VMexit/VMcall 524 в обработчик 454 VMexit/VMcall. Для некоторых вариантов воплощения, обработчик 454 VMexit/VMcall должен тогда выйти в обработчик 452 SMM из состава SVMM через исполнение кода RSM 526 модифицированной команды возобновления VM SMM. Это заставит обработчик 452 SMM из состава SVMM восстановить (потенциально измененные обработчиком 454 VMexit/VMcall) данные состояния, сохраненные в блокированных страницах памяти. Для других вариантов воплощения, обработчик 452 SMM из состава SVMM и обработчик 454 VMexit/VMcall могут быть объединены, и эти операции могут быть реализованы в программном обеспечении. После восстановления данных состояния процессор возобновляет свою первоначальную работу.

Обратимся теперь к фиг.6, на которой показана схематическая диаграмма иллюстративной системы микропроцессора, выполненной с возможностью поддержки программной среды по фиг.2, согласно другому варианту воплощения данного изобретения. Центральный процессор А 610, центральный процессор В 614, центральный процессор С 618 и центральный процессор D 622 могут быть сконфигурированы с дополнительным микрокодом или логической схемой для поддержки исполнения специальных команд. Модификации к процессорам могут включать в себя, в одном варианте воплощения, изменения в поведении регистров и новые или модифицированные команды. Например, в одном варианте воплощения, центральный процессор С 618 может включать в себя новую команду 624 «инициализация монитора виртуальных машин» (VMMINIT). Команда 624 VMMINIT после исполнения может обеспечить инициирование защищенных или доверенных операций, как показано на фиг.2. В одном варианте воплощения, VMMINIT 624 может также запрещать нормальные операции регистра PSMBASE 616 центрального процессора С 618 при некоторых обстоятельствах для поддержки защищенных или доверенных операций SMM. В таком варианте воплощения, центральный процессор С 618 может затем переадресовать SMI в точку входа кода и область сохранения состояний в пределах обработчика 668 VMexit/VMcall, заранее заданные согласно правилам защищенной среды.

В одном варианте воплощения, центральный процессор С 618 может также включать в себя модифицированную команду 626 возобновления (RSM). Модифицированная RSM 626 может разрешать возврат из SMM, который поддерживает защищенные или доверенные операции. Обычно команды RSM могут быть исполнены только SMM. Модифицированная RSM 626 может быть исполнена в нормальном страничном режиме. При инициировании с активированными расширениями VM, модифицированная команда 626 RSM может выполнить специальный системный вызов, называемый VMexit, в обратном направлении для вызова обработчика 668 VMexit/VMcall.

Набор микросхем 630 может обслуживать запросы на чтение и запись, которые переносятся от центральных процессоров по системной шине 620, и может затем осуществить физические операции чтения и записи в физической памяти 634. Распределению SMRAM в памяти 634 может содействовать регистр 631 SMBASE набора микросхем, содержащий значение CSMBASE.

SVMM 664 может разрешить или отказать в доступе VM к определенным страницам в памяти 634. Страницы памяти, к которым VM лишена доступа, можно назвать «блокированными» страницами, тогда как страницы, к которым VM разрешен доступ, можно назвать «неблокированными» страницами. В блокированных страницах памяти 660 может быть расположен SVMM 664 и модуль в SVMM 664 для поддержки защищенной работы SMM. В одном варианте воплощения, данный модуль может быть обработчиком 668 VMexit/VMcall. В других воплощениях функции обработчика 668 VMexit/VMcall могут быть объединены или могут быть распределены среди других модулей. Другие страницы памяти могут оставаться неблокированными, как, например, неблокированные страницы памяти 662. В неблокированных страницах памяти 662 могут быть расположены стандартные операционные системы 672. Также в неблокированных страницах памяти 662 могут быть размещены VM 670 SMM. VM 670 SMM может включать в себя код программного обеспечения, подобный стандартному коду SMM, но модифицированный для работы в контейнере виртуальной машины. Такие модификации в VM 670 SMM могут включать в себя код, предназначенный для исполнения в страничном режиме, а не в нормальном SMM.

Обратимся теперь к фиг.7, на которой показана диаграмма переадресации прерывания режима управления системой, согласно другому варианту воплощения данного изобретения. В варианте воплощения по фиг.7, SVMM 750 имеет два дополнительных модуля для поддержки защищенных или доверенных операций SMM. В одном варианте воплощения обработчик 754 VMexit/VMcall вводит код SMM в VM 790 SMM в качестве реакции на исполнение команды VMMINIT, и дополнительно обрабатывает вход в и выход из VM 790 SMM вследствие намеренно более низкого уровня привилегий VM 790 SMM в пределах его контейнера VM.

Обработчик 754 VMexit/VMcall может выполнять несколько функций. Во время перехода к защищенному или доверенным операциям после исполнения команды VMMINIT процессором, обработчик 754 VMexit/VMcall загружает и инициирует код VM 790 SMM в контейнере виртуальной машины. Обработчик 754 VMexit/VMcall также обеспечивает пространство в блокированных страницах памяти для хранения данных состояния, которые должны быть сохранены после входа в операции SMM.

Обработчик 754 VMexit/VMcall может выполнять несколько дополнительных функций. Обработчик 754 VMexit/VMcall может обрабатывать входы в и выходы из VM 790 SMM. Обработчик 754 VMexit/VMcall может также обрабатывать исключения, возникшие после попыток VM 790 SMM считать из или записать в блокированные страницы памяти. Части обработчика 754 VMexit/VMcall могут определять, следует ли разрешить выполнение некоторых из этих операций чтения из или записи в блокированные страницы памяти в зависимости от обстоятельств. В одном варианте воплощения, операции чтения из или записи в блокированные страницы памяти можно разрешить, если обработчик 754 VMexit/VMcall решит, что целевая ячейка в пределах блокированных страниц памяти не содержит доверенных данных.

VM 790 SMM содержит требующийся код SMM, модифицированный, в одном варианте воплощения, из формата режима SMM для исполнения в режиме доступа к страницам памяти. В общем случае, код SMM в VM 790 SMM исполняется так, как он написан, исключая случаи тех команд, которые осуществляют чтение из и запись в блокированные страницы памяти. В этих случаях код SMM может вызвать обработчик 754 VMexit/VMcall. Код SMM может сделать явный вызов обработчика 754 VMexit/VMcall, или может сделать опосредованный вызов, позволяя исключению быть перехваченным обработчиком 754 VMexit/VMcall. В любом случае обработчик 754 VMexit/VMcall обрабатывает эти обстоятельства.

Рассмотрим событие, приводящее к SMI, в аппаратных средствах 780, следующее за инициированием защищенных или доверенных операций. Процессор проверяет свой регистр SMBASE. Так как исполнение VMMINIT запретило нормальное функционирование модифицированного регистра SMBASE в процессоре, процессор начинает исполнение обработчика 754 VMexit/VMcall из точки входа кода, заранее заданной согласно правилам защищенной среды. Обработчик 754 VMexit/VMcall сохраняет данные состояния в блокированной странице памяти, а затем выполняет вызов 722 VMenter к фактическому коду SMM в VM 790 SMM.

Код SMM в VM 790 SMM исполняется до тех пор, пока он не попытается считать из или записать в ячейку памяти в блокированной странице памяти. Тогда или явным вызовом, или исключением, вызывающим системное прерывание, может быть осуществлен VMexit/VMcall 724 для вызова обработчика 754 VMexit/VMcall. Обработчик 754 VMexit/VMcall осуществляет те доступы к памяти, которые он считает допустимыми, и затем возвращается к VM 790 SMM посредством еще одного VMenter 722. Этот процесс может повторяться несколько раз, пока требующийся код SMM в VM 790 SMM не завершится. В это время код SMM осуществит выход посредством завершающего VMexit/VMcall 724 в обработчик 754 VMexit/VMcall. Для некоторых вариантов воплощения, обработчик 754 VMexit/VMcall должен тогда выйти к нормальным операциям 750 SVMM с помощью изначального исполнения модифицированной команды возобновления. Это заставит обработчик 754 VMexit/VMcall восстановить (потенциально измененные обработчиком 754 VMexit/VMcall) данные состояния, сохраненные в блокированных страницах памяти. После восстановления данных состояния процессор возобновляет свою первоначальную работу.

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

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

Изобретение относится к системе и способу для обеспечения возможности исполнения кода режима управления системой (SMM) во время защищенной работы в микропроцессорной системе. Техническим результатом является расширение функциональных возможностей. Система для обработки прерывания содержит процессор, первую программу, которая содержится в первой виртуальной машине, и первый обработчик, который содержится в доверенной программе во второй виртуальной машине. Прерывание режима управления системой (SMI) вначале направляется в обработчик в защищенном мониторе виртуальных машин (SVMM). SMI может быть затем переадресовано в код SMM, расположенный в виртуальной машине (VM), которая находится под защищенным управлением SVMM. Эта переадресация может быть реализована посредством разрешения SVMM считывать и записывать данные в базовый регистр управления системой (SM) в процессоре. 2 н. и 24 з.п. ф-лы, 7 ил.

1. Система для обработки соответствующего управлению системой прерывания в доверенной среде, включающая в себя

процессор, выполненный с возможностью функционирования в непривилегированном режиме, привилегированном режиме и режиме управления системой;

программа управления системой, которая содержится в пределах первой виртуальной машины; и

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

переадресуют соответствующее управлению системой прерывание в первый обработчик в доверенной программе в пределах второй виртуальной машины;

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

входят в программу управления системой в пределах первой виртуальной машины для обслуживания упомянутого соответствующего управлению системой прерывания под управлением упомянутой доверенной программы.