Диссертация (Разработка программного комплекса оценки качества и надежности программных продуктов без исходных текстов), страница 6

Тем не менее, пользовательские приложения и библиотеки никакоймодификации не требуют. При первоначальной установке Хеn автоматическисоздает первый домен - domain 0.Указанный домен несет ответственность за управление системой и решаеттакие задачи, как: создание дополнительных доменов для виртуальных машин,управление виртуальными устройствами для каждой виртуальной машины,приостановку виртуальных машин, возобновление работы виртуальных машин иперенос виртуальных машин.Припаравиртуализацииоперационнаясистемавзаимодействуетспрограммой гипервизора, который предоставляет ей гостевой API вместоиспользования напрямую таких ресурсов, как таблица страниц памяти.36LinuxAIXi/OSВиртуальнаямашинаВиртуальнаямашинаВиртуальнаямашинаГипервизор PowerVMФизическое оборудованиеРисунок 8 - Структурная схема гипервизора PowerVMLinuxВиртуальнаямашинаWindowsFreeBSDВиртуальнаямашинаВиртуальнаямашинаГипервизор VMware ESX serverФизическое оборудованиеРисунок 9 - Структурная схема гипервизора ESX Server37Linux(domain 0)LinuxLinuxВиртуальнаямашинаВиртуальнаямашинаВиртуальнаямашинаГипервизор XenФизическое оборудованиеРисунок 10 - Структурная схема гипервизора Хеn4.

Kernel-based Virtual Machine (KVM) - это полное решение платформеннозависимой виртуализации для Linux на процессорах х86 с расширениямивиртуализации (Intel VT или AMD-V) [47].Длягостевыхсистемдоступнатакжеограниченнаяподдержкапаравиртуализации для Linux и Windows в форме паравиртуального сетевогодрайвера.

Структурная схема KVM представлена на Рисунке 11. В архитектуреKVMвиртуальнаямашинавыполняетсякакобычныйLinux-процесс,запланированный стандартным планировщиком Linux [47]. На самом деле каждыйвиртуальный процессор представляется как обычный Linux-процесс. Это позволяетKVM пользоваться всеми возможностями ядра Linux.5. Гипервизор z/VM разработан с целью распространения преимуществтехнологии компьютер с архитектурой IBM System/360, 370, 390, zSeries напредприятии путем интеграции приложений и данных с гарантией исключительновысокого уровня надежности, безопасности и простоты эксплуатации [1].6.

Технология виртуализации z/VM предоставляет возможность выполнятьсотни и тысячи Linux-серверов на одном суперкомпьютере [1]. Структурная схемаz/VM представлена на Рисунке 12.387. Гипервизор Bochs отличается тщательной эмуляцией процессора, можетбыть запущен на любой аппаратной платформе, в том числе на SPARC, PowerPC,MIPS [1].Структурная схема Bochs представлена на Рисунке 13.Гипервизорпрограммуинтерпретируетработатьболееинструкцииестественно,процессора, чтооднакоэтозаставляетсказываетсянапроизводительности. Часто применяется для отладки операционных систем и ихкомпонентов.

Очень часто Bochs используют в Nix5 системах, для эмуляции DOS изапуска приложений под эту операционную систему.LinuxВиртуальная машинаWindowsВиртуальная машинаГипервизор KVMЯдро операционной системы LinuxФизическое оборудованиеРисунок 11 - Структурная схема гипервизора KVMUNIX-подобная операционная система (иногда сокр.

как *nix) — операционная система,которая образовалась под влиянием UNIX.539Linuxz/OSВиртуальная машинаВиртуальная машинаГипервизор z/VMФизическое оборудованиеРисунок 12 - Структурная схема гипервизора z/VMDosWindowsВиртуальная машинаВиртуальная машинаГипервизор BochsФизическое оборудованиеРисунок 13 - Структурная схема гипервизора Bochs40В Таблице 4 приведена сравнительная характеристика вышеуказанныхгипервизоров. Исходя из данных Таблицы 4, можно сделать вывод, чтозначительными преимуществами обладают гипервизоры, имеющие исходный код.Выполним дальнейшее сравнение гипервизоров Xen, KVM, Bochs и представимсравнительные характеристики в Таблице 5.№п/пНаименованиеПроизводительТип гипервизораНаличиеисходного кодаПоддержка паравиртуализацииLinuxWindowsz/OSDOSFreeBSDЯзык программированияТаблица 4 - Сравнительная характеристика гипервизоров1PowerVMIBM1--+-+--нет данных2VMwareVMware, Inc.1--++--+нет данных3XenThe Xen Project,XenSource, Inc1+++----Си4KVMRed Hat2+-++---Си5z/VMIBM1--+-+--нет данных6BochsBochs Project1+--+-+-Си++Поддерживаемыегостевые операционныесистемы41XenKVMBochs++++++__+Объем исходного кодапоследней версии, КбайтПошаговый контрольвыполнения инструкцийпроцессораВозможностьмодернизации№ п/пСвободноераспространениеТаблица 5 - Сравнение гипервизоров Xen, KVM, Bochs15 2296 6804 262Из Таблицы 5 очевидно преимущество гипервизора Bochs по основнымпараметрам: пошаговый контроль выполнения инструкций процессора инаименьший объем исходного кода.

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

Следовательно, все конструкции,определенные в разделе 1.3 и представляющие потенциальную угрозу дляработоспособности системы в целом, можно выявить и контролировать припомощи гипервизора. Учитывая изложенное, дополним классификацию на Рисунке3 методом контроля и использования системных ресурсов (полная виртуализация),приоритетом – контроль и анализ областей памяти (Рисунок 14).42Методы контроля программного продукта без исходных текстовПредварительное дизассемблирование с исходным кодомКонтроль использования системных ресурсов (полнаявиртуализация)СтатическийФормирование перечнямаршрутов выполненияфункциональных объектовНаличие заданныхконструкций в исходныхтекстахКонтроль и анализобластей памятиКонтрольпериферийныхустройствКонтроль командцентральногопроцессораАнализ критическихмаршрутовВыявление действий по скрытию своего присутствияПродвижение констант икопийВыявление действий по искажению результатовработы других программАнализ сигнатурВыявление действий самомодификация илиизменению кода других программПостроение графа потокауправленияВыявление действий по сохранению информацииВыявление действий по передаче управленияВыявление действий по самодублированиюпрограммРисунок 14 - Классификация методов анализа программного продукта42Контроль сетевыхустройств431.6.

Определение среды для исследованийВ работе в качестве среды для исследования выбрана операционная системаDOS.Еёвыборобусловленследующимиособенностями:ОСявляетсяоднозадачной, хорошо изученной, свободно распространяемой, процессы,происходящие в данной системе, можно интерпретировать на более сложныесистемы семейства Windows. Трудоемкость работ, выполняемых с DOS,подразумевает их осуществление за приемлемое время одним человеком.Выдвигаемые теоретические предположения в рамках работымогут бытьпроверены и апробированы под операционной системой DOS и при необходимостиповторены под Windows, только гораздо бо́льшим числом исполнителей.1.7. Цели и задачи работыВ настоящее время, несмотря на устаревшую нормативную базу,разработчики и исследователи используют средства автоматизации поискапотенциально опасных конструкций (уязвимостей), а также специализированноепрограммное обеспечение с собственно написанными плагинами, которыеобеспечивают им удобство поиска дефектов.

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

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

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

Проанализированысовременные методы, способы и инструменты оценки качества и надежностипрограммных продуктов. Сформулированы основные задачи исследования.По результатам выполненных исследований, сформулированы следующиеосновные задачи:1. Разработка алгоритма контроля обращений процессора к областям памяти,используемой программным продуктом.2. Разработкаалгоритмаконтроляиспользованияобластейпамятипрограммным продуктом без исходных текстов.3. Разработка принципа оценки качества функционирования программногопродукта без исходных текстов на основе визуализации событий выполненияпрограммы.4. Разработка программного инструментария, позволяющего выполнятьоценку качества и надежности программных продуктов без исходных текстов.Вторая глава посвящена моделированию общих требований к качествупрограммных продуктов, выбору и обоснованию моделей предназначенных дляоценки надежности программных продуктов.46ГЛАВА 2.