Система и способ контроля работоспособности процессов в операционной системе Российский патент 2024 года по МПК G06F12/14 G06F21/52 

Область техники

Изобретение относится к области информационной безопасности, а более конкретно к способам контроля работоспособности процессов в операционной системе компьютерной системы.

Уровень техники

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

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

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

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

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

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

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

Раскрытие сущности изобретения

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

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

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

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

В ещё одном варианте реализации способа при определении ошибки в работе целевого процесса осуществляют перезапуск целевого процесса

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

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

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

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

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

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

В другом варианте реализации способа при выявлении ошибки в работе целевого процесса останавливают работу процесса.

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

Краткое описание чертежей

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

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

Фиг. 2 иллюстрирует преобразование графа потока управления в граф потока вызова для функции main().

Фиг. 3 иллюстрирует преобразование графа потока управления в граф потока вызова для функции sleep().

Фиг. 4 иллюстрирует преобразование графа потока управления в граф потока вызова для функции nanosleep().

Фиг. 5 иллюстрирует преобразование графа потока управления в граф потока вызова для функции errno().

Фиг. 6 иллюстрирует способ контроля работоспособности процессов в операционной системе.

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

Осуществление изобретения

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

Глоссарий

Граф потока управления (англ. control flow graph или CFG) - это представление алгоритма исходного кода функции компилируемой программы в виде графа, которое отображает поток управления в исходном коде упомянутой функции. Граф потока управления состоит из узлов, представляющих блоки программного кода, и дуг, которые связывают эти блоки, отображая передачу управления между ними.

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

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

Базовый блок - блок в графе потока управления, представленный целевой инструкцией целевого процесса.

Сигнатура потока управления (англ. CFS - control flow signature) - это представление совокупности графов потока вызовов, состоящей из графов потока вызовов и дуг графов потока вызовов.

Целевой процесс - процесс в операционной системе, который контролируется монитором потока управления.

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

Считается, что работоспособность процесса нарушена в случае, если процесс:

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

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

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

Работу системы можно разделить на два этапа - этап компиляции и этап исполнения.

Этап исполнения реализован на операционной системе 170, установленной на первой компьютерной системе. Этап компиляции реализован на операционной системе (не представлена на Фиг. 1), установленной на второй компьютерной системе.

В частном варианте реализации этап исполнения и этап компиляции реализованы на одной операционной системе 170.

Этап компиляции.

Компилятор 120 получает на вход исходный код 110 программы для его компиляции. Исходный код 110 программы может быть представлен в виде кода как на языке высокого уровня (например, С++, Java и др.), так и на языке низкого уровня (например, assembler, C и др.).

Во время компиляции компилятор 120 преобразует исходный код 110 программы, написанной на языке программирования, в эквивалентный машинный код, который может исполняться на компьютерной системе, например такой, которая представлена при описании Фиг. 7. Процесс компиляции включает в себя несколько шагов, а именно: лексический анализ, синтаксический анализ и генерацию машинного кода. Лексический анализатор разбивает исходный код 110 программы на токены, такие как идентификаторы, операторы, числа и т. д. Синтаксический анализатор использует указанные токены для построения графов потока управления, которые отражают структуру и синтаксис исходного кода 110 программы. Затем компилятор 120 генерирует машинный код, который соответствует графам потока управления. По завершении компиляции компилятор 120 передает построенные графы потока управления генератору сигнатур потока управления 130, а также передает скомпилированный код (машинный код) в операционную систему 170.

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

В другом варианте реализации изобретения вместо компилятора 120 используется интерпретатор (не представлен на Фиг. 1). Например, если исходный код 110 представлен на интерпретируемом языке программирования (например, Python). Стоит отметить, что в данном варианте реализации изобретения интерпретатор в отличие от компилятора 120 выполняет все вышеописанные для компиляции шаги каждый раз при выполнении программы.

Генератор сигнатур потока управления 130 принимает графы потока управления от компилятора 120 и целевые инструкции 140 от операционной системы 170.

Стоит отметить, что целевой инструкцией 140 является по меньшей мере одна инструкция, переданная от операционной системы 170 с целью контроля работоспособности целевого процесса 160.

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

Далее генератор сигнатур потока управления 130 генерирует по меньшей мере одну сигнатуру потока управления на основании сформированных графов потока вызовов.

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

В другом варианте реализации генератор сигнатур потока управления 130 генерирует сигнатуру потока управления, представленную совокупностью графов потока вызовов. Генератор сигнатур потока управления 130 производит последовательную замену базовых блоков с целевыми инструкциями 140 на соответствующие им графы потока вызовов.

В ещё одном частном варианте реализации генератор сигнатур потока управления 130 генерирует сигнатуру потока управления путем преобразования по меньшей мере одного графа потока вызовов к виду конечного автомата вызовов целевых инструкций 140.

Конечный автомат вызовов - графовое представление всех возможных исходов передачи управления во время исполнения целевого процесса 160. Началом конечного автомата является точка входа, представленная целевой инструкцией, с которой начинается исполнение целевого процесса 160.

Генератор сигнатур потока управления 130 передает сгенерированные сигнатуры потока управления в монитор потока управления 150, который расположен в операционной системе 170.

Этап исполнения.

Операционная система 170 принимает от компилятора 120 скомпилированный код (машинный код) и запускает его в рамках целевого процесса 160.

Монитор потока управления 150 осуществляет контроль работы процесса (далее - целевого процесса 160) в операционной системе 170 во время исполнения запущенного скомпилированного исходного кода 110 путем мониторинга исполняемых в целевом процессе 160 инструкций с помощью по меньшей мере одной полученной сигнатуры потока управления. Мониторинг включает перехват исполняемых инструкции в целевом процессе 160 посредством операционной системы 170 и проверку их на соответствие по меньшей мере одной полученной сигнатуре потока управления. Если исполняемые инструкции соответствуют по меньшей мере одной сигнатуре, то монитор потока управления 150 определяет корректность в работе целевого процесса 160 при исполнении скомпилированного кода и продолжает мониторинг. Если же по меньшей мере одна исполняемая инструкция не соответствует сигнатуре потока управления, то определяют ошибку в работе целевого процесса 160.

В частном варианте реализации для восстановления работоспособности целевого процесса 160 монитор потока управления 150 осуществляет перезапуск целевого процесса 160 посредством операционной системы 170.

В другом частном варианте реализации при выявлении ошибки в работе целевого процесса 160, монитор потока управления 150 останавливает работу целевого процесса 160 посредством операционной системы 170.

В ещё одном частном варианте реализации монитор потока управления 150 уведомляет систему безопасности (например, SIEM или EDR) или пользователя о нарушении в работе целевого процесса 160, если исполняемые инструкции целевого процесса 160 не соответствуют сигнатуре потока управления.

В частном варианте реализации монитор потока управления 150 является процессом, запущенным операционной системой 170 перед запуском скомпилированного кода в целевом процессе 160.

Таким образом, на этапе исполнения операционная система 170 запускает монитор потока управления 150, после чего запускает скомпилированный код в целевом процессе 160. Монитор потока управления 150 перехватывает все инструкции целевого процесса 160 и проверяет их на соответствие сигнатуре потока управления. В случае если инструкции целевого процесса 160 не соответствуют сигнатуре потока управления, монитор потока управления 150 перезапускает целевой процесс 160 или останавливает его работу.

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

На Фиг. 2 - Фиг. 5 представлен пример формирования из графов потока управления графов потока вызовов для следующей программы:

#include <unistd.h>

int main(){

sleep(1);

return 0;

}

В данном примере целевыми инструкциями, предоставляемыми операционной системой 170 генератору сигнатур потока управления 130, являются следующие: SleepAPI и ErrnoAPI.

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

На Фиг. 2 показано преобразование графа потока управления функции main() в граф потока вызова функции main(). После преобразования остается только целевая инструкция sleep, относящаяся к SleepAPI.

На Фиг. 3 показано преобразование графа потока управления функции sleep() в граф потока вызова функции sleep(). После преобразования остается только целевая инструкция nanosleep, относящаяся к SleepAPI.

На Фиг. 4 показано преобразование графа потока управления функции nanosleep() в граф потока вызова функции nanosleep(). После преобразования остается только целевая инструкция errno, относящаяся к ErrnoAPI, и SleepAPI.

На Фиг. 5 показано преобразование графа потока управления функции errno() в граф потока вызова функции errno(). После преобразования остается только целевая инструкция ErrnoAPI.

Фиг. 6 иллюстрирует способ контроля работоспособности процессов в операционной системе на основе мониторинга последовательности исполняемых инструкций.

На предварительном шаге 605 преобразовывают исходный код 110 программы в эквивалентный машинный код посредством компилятора 120.

В частном варианте реализации изобретения вместо компилятора 120 используется интерпретатор (не представлен на Фиг. 1).

На шаге 610 строят графы потока управления, которые отражают структуру и синтаксис исходного кода 110 программы.

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

На шаге 630 с помощью генератора сигнатур потока управления 130 генерируют по меньшей мере одну сигнатуру потока управления на основании сформированных графов потока вызовов и передают ее в монитор потока управления 150.

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

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

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

На шаге 640 запускают монитор потока управления 150, после чего запускают целевой процесс 160 в операционной системе 170.

На шаге 645 перехватывают исполняемые инструкции целевого процесса 160 с помощью монитора потока управления 150 посредством операционной системы 170.

На шаге 650 перехваченные инструкции проверяют на соответствие сигнатуре потока управления указанного целевого процесса 160.

На шаге 660 при несоответствии инструкций целевого процесса 160 сигнатуре потока управления определяют ошибку в работе целевого процесса 160. для восстановления работоспособности целевого процесса 160 осуществляют перезапуск целевого процесса 160 посредством операционной системы 170.

В частном варианте реализации при определении ошибки в работе целевого процесса 160 осуществляют перезапуск целевого процесса 160.

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

В ещё одном частном варианте реализации при определении ошибки в работе целевого процесса 160 дополнительно уведомляют пользователя о нарушении работоспособности целевого процесса 160.

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

Как показано на Фиг. 7, компьютерная система 20 включает в себя: центральный процессор 21, системную память 22 и системную шину 23, которая связывает разные системные компоненты, в том числе память, связанную с центральным процессором 21. Системная шина 23 реализована, как любая известная из уровня техники шинная структура, содержащая в свою очередь память шины или контроллер памяти шины, периферийную шину и локальную шину, способную взаимодействовать с любой другой шинной архитектурой. Примерами шин являются: PCI, ISA, PCI-Express, HyperTransport™, InfiniBand™, Serial ATA, I2C и другие подходящие соединения между компонентами компьютерной системы 20. Центральный процессор 21 содержит один или несколько процессоров, имеющих одно или несколько ядер. Центральный процессор 21 исполняет один или несколько наборов машиночитаемых инструкций, реализующих способы, представленные в настоящем документе. Системная память 22 может быть любой памятью для хранения данных и/или компьютерных программ, исполняемых центральным процессором 21. Системная память может содержать как постоянное запоминающее устройство (ПЗУ) 24, так и память с произвольным доступом (ОЗУ) 25. Основная система ввода/вывода (BIOS) 26, содержит основные процедуры, которые обеспечивают передачу информации между элементами компьютерной системы 20, например, в момент загрузки операционной системы с использованием ПЗУ 24.

Компьютерная система 20 включает в себя одно или несколько устройств хранения данных, таких как одно или несколько извлекаемых запоминающих устройств 27, одно или несколько неизвлекаемых запоминающих устройств 28, или комбинации извлекаемых и неизвлекаемых устройств. Одно или несколько извлекаемых запоминающих устройств 27 и/или неизвлекаемых запоминающих устройств 28 подключены к системной шине 23 через интерфейс 32. В одном из вариантов реализации извлекаемые запоминающие устройства 27 и соответствующие машиночитаемые носители информации представляют собой энергонезависимые модули для хранения компьютерных инструкций, структур данных, программных модулей и других данных компьютерной системы 20. Системная память 22, извлекаемые запоминающие устройства 27 и неизвлекаемые запоминающие устройства 28 могут использовать различные машиночитаемые носители информации. Примеры машиночитаемых носителей информации включают в себя машинную память, такую как кэш-память, SRAM, DRAM, ОЗУ, не требующую конденсатора (Z-RAM), тиристорную память (T-RAM), eDRAM, EDO RAM, DDR RAM, EEPROM, NRAM, RRAM, SONOS, PRAM; флэш-память или другие технологии памяти, такие как твердотельные накопители (SSD) или флэш-накопители; магнитные кассеты, магнитные ленты и магнитные диски, такие как жесткие диски или дискеты; оптические носители, такие как компакт-диски (CD-ROM) или цифровые универсальные диски (DVD); и любые другие носители, которые могут быть использованы для хранения нужных данных и к которым может получить доступ компьютерная система 20.

Системная память 22, извлекаемые запоминающие устройства 27 и неизвлекаемые запоминающие устройства 28, содержащиеся в компьютерной системе 20 используются для хранения операционной системы 35, приложений 37, других программных модулей 38 и программных данных 39. Компьютерная система 20 включает в себя периферийный интерфейс 46 для передачи данных от устройств ввода 40, таких как клавиатура, мышь, стилус, игровой контроллер, устройство голосового ввода, устройство сенсорного ввода, или других периферийных устройств, таких как принтер или сканер через один или несколько портов ввода/вывода, таких как последовательный порт, параллельный порт, универсальная последовательная шина (USB) или другой периферийный интерфейс. Устройство отображения 47, такое как один или несколько мониторов, проекторов или встроенных дисплеев, также подключено к системной шине 23 через выходной интерфейс 48, такой как видеоадаптер. Помимо устройств отображения 47, компьютерная система 20 оснащена другими периферийными устройствами вывода (на Фиг. 7 не показаны), такими как динамики и другие аудиовизуальные устройства.

Компьютерная система 20 может работать в сетевом окружении, используя сетевое соединение с одним или несколькими удаленными компьютерами 49. Удаленный компьютер (или компьютеры) 49 является рабочим персональным компьютером или сервером, который содержит большинство или все упомянутые компоненты, отмеченные ранее при описании сущности компьютерной системы 20, представленной на Фиг. 7. В сетевом окружении также могут присутствовать и другие устройства, например, маршрутизаторы, сетевые станции или другие сетевые узлы. Компьютерная система 20 может включать один или несколько сетевых интерфейсов 51 или сетевых адаптеров для связи с удаленными компьютерами 49 через одну или несколько сетей, таких как локальная компьютерная сеть (LAN) 50, глобальная компьютерная сеть (WAN), интранет и Интернет. Примерами сетевого интерфейса 51 являются интерфейс Ethernet, интерфейс Frame Relay, интерфейс SONET и беспроводные интерфейсы.

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

Машиночитаемый носитель информации является осязаемым устройством, которое сохраняет и хранит программный код в форме машиночитаемых инструкций или структур данных, к которым имеет доступ центральный процессор 21 компьютерной системы 20. Машиночитаемый носитель может быть электронным, магнитным, оптическим, электромагнитным, полупроводниковым запоминающим устройством или любой подходящей их комбинацией. В качестве примера, такой машиночитаемый носитель информации может включать в себя память с произвольным доступом (RAM), память только для чтения (ROM), EEPROM, портативный компакт-диск с памятью только для чтения (CD-ROM), цифровой универсальный диск (DVD), флэш-память, жесткий диск, портативную компьютерную дискету, карту памяти, дискету или даже механически закодированное устройство, такое как перфокарты или рельефные структуры с записанными на них инструкциями.

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

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

Изобретение относится к области информационной безопасности. Технический результат изобретения заключается в повышении эффективности обнаружения нарушения работоспособности процесса в операционной системе. Технический результат достигается за счет этапов, согласно которым: преобразовывают исходный код программы в эквивалентный машинный код; строят графы потока управления, которые отражают структуру и синтаксис исходного кода программы; преобразовывают графы потока управления в графы потока вызовов с использованием целевых инструкций, полученных от операционной системы; генерируют по меньшей мере одну сигнатуру потока управления на основании сформированных графов потока вызовов; запускают монитор потока управления, после чего в операционной системе запускают целевой процесс, соответствующий указанной программе; перехватывают с помощью монитора потока управления исполняемые целевым процессом инструкции указанной программы; проверяют перехваченные инструкции на соответствие по меньшей мере одной сигнатуре потока управления указанного целевого процесса; при несоответствии инструкций целевого процесса сигнатуре потока управления определяют ошибку в работе целевого процесса. 2 н. и 9 з.п. ф-лы, 7 ил.

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

преобразовывают исходный код программы в эквивалентный машинный код;

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

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

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

запускают монитор потока управления, после чего в операционной системе запускают целевой процесс, соответствующий указанной программе;

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

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

при несоответствии инструкций целевого процесса сигнатуре потока управления определяют ошибку в работе целевого процесса.

2. Способ по п. 1, в котором преобразовывают исходный код программы в эквивалентный машинный код посредством компилятора или интерпретатора.

3. Способ по п. 1, в котором при определении ошибки в работе целевого процесса осуществляют перезапуск целевого процесса.

4. Способ по п. 1, в котором определяют ошибку в целевом процессе, связанную с одним из:

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

выполнением недопустимой инструкции.

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

6. Способ по п. 4, в котором недопустимой инструкцией является любая инструкция, которая не содержится в исходном коде.

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

8. Способ по п. 1, в котором генерируют сигнатуру потока управления по меньшей мере одним из способов:

объединением графов потока вызовов и связей графов потока вызовов;

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

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

10. Способ по п. 1, в котором при выявлении ошибки в работе целевого процесса останавливают работу процесса.

11. Система контроля работоспособности процессов в операционной системе для выявления ошибок в работе процессов, состоящая из компьютерного устройства с аппаратным процессором, настроенным для выполнения способа по любому из пп. 1-10.