Architektura QEFI

Metodyka opisana w sekcji 3.4.5 została zaimplementowana w ´srodowisku QEFI. W niniejszej sekcji przedstawiona jest architektura, która pozwoliła na implementacj˛e wszystkich funkcji opisanej metodyki.

Zało˙zenia b˛ed ˛ace podstaw ˛a opracowanej architektury to:

1. minimalna ingerencja w oprogramowanie QEMU,

2. rozdzielenie procesu emulacji od sterowania przebiegiem testu, 3. rozdzielenie przeprowadzania testu od analizy wyników, 4. mo˙zliwo´s´c uruchamiania równolegle wielu instancji testów.

Zało˙zenie 1 zostało opracowane z my´sl ˛a o mo˙zliwej integracji opracowanych rozszerze´n z oficjaln ˛a wersj ˛a QEMU – minimalna ingerencja w kod ´zródłowy zwi˛eksza szanse na przyj˛ecie

11 Dotyczy eksperymentów zaburzania kodu systemu operacyjnego SUT.

12 Wykorzystane w eksperymencie opisanym w 4.5.3.

13 Dotyczy eksperymentów zaburzania kodu systemu operacyjnego SUT.

takiego kodu przez autorów projektu QEMU. Zało˙zenie 2 jest rozszerzeniem zało˙zenia 1 nios ˛acym dodatkowe korzy´sci: uniezale˙znienie od technologii, w której zostało wykonane QEMU (j˛ezyk C), oraz mo˙zliwo´s´c zarejestrowania ewentualnej awarii oprogramowania QEMU. Zało˙zenie 3 umo˙zliwia rozszerzanie bazy procedur analizuj ˛acych cechy dzienników wykonania bez konieczno´sci ponownego przeprowadzania eksperymentu. Zało˙zenie 4 ma na celu umo˙zliwienie skrócenia czasu przeprowadzania eksperymentu poprzez wykorzystanie wieloprocesorowych serwerów.

Na podstawie opracowanych zało˙ze´n przygotowane zostały trzy programy:

— Zmodyfikowana na potrzeby QEFI wersja emulatora QEMU,

— Nadzorca – oprogramowanie automatyzuj ˛ace wykonanie testu,

— Analizator – oprogramowanie analizuj ˛ace dzienniki wykonania.

Test jest przeprowadzany z udziałem instancji QEMU oraz instancji Nadzorcy, gdzie testowany system komputerowy (SUT) jest emulowany przez QEMU. Nadzorca oraz QEMU s ˛a osobnymi procesami w systemie operacyjnym i komunikuj ˛a si˛e poprzez sie´c protokołem TCP/IP. Zało˙zenie 4 realizowane jest poprzez uruchamianie wielu par procesów QEMU i Nadzorca, a sterowane jest to z udziałem skryptów powłoki systemu GNU/Linux.

Zebrane przez Nadzorc˛e dzienniki wykonania testów przekazywane s ˛a do Analizatora po przeprowadzeniu eksperymentu w trybie wsadowym. Analizator jest programem w j˛ezyku Pythonrealizuj ˛acym przetwarzanie dzienników pod k ˛atem wyst˛epowania poszczególnych cech zgodnie z algorytmem 3.5.

Współpraca wymienionych komponentów przedstawiona jest na rysunku 3.1. Na rysunku komponenty oznaczone kolorem pomara´nczowym s ˛a opracowane przez autora.

Kolorem niebieskim zaznaczone s ˛a miejsca implementacji algorytmów opisanych w sekcji 3.4.5, kolorem szarym oznaczone jest oryginalne oprogramowanie QEMU, a kolorem zielonym oprogramowanie poddawane testom. Poni˙zej zamieszczony jest szczegółowy opis opracowanych programów oraz procesu przeprowadzania eksperymentów.

Nadzorca

Nadzorca jest głównym komponentem realizuj ˛acym automatyczne przeprowadzanie testu na podstawie przygotowanego scenariusza. Jest to osobny proces w systemie operacyjnym, który komunikuje si˛e z SUT poprzez jeden lub wi˛ecej kanałów (poł ˛aczenie 1 z rysunku 3.1):

— tunelem do portu szeregowego SUT¹⁴,

— poprzez sie´c TCP/IP:

— bezpo´srednie poł ˛aczenie z usługami SUT,

14 Tunel do portu szeregowego działa w sposób nast˛epuj ˛acy: oprogramowanie QEMU uruchamia serwer TCP/IP, gdzie dane przychodz ˛ace s ˛a przekazywane do portu szeregowego emulowanego systemu, a dane wysyłane przez emulowany system s ˛a przekazywane do klientów serwera TCP/IP.

QEMU

— poprzez uruchomienie dodatkowych programów (np. ssh lub wget) skonfigurowanych na interakcj˛e z SUT.

Tunel do portu szeregowego jest szczególnym kanałem komunikacji z SUT – systemy operacyjne uruchamiane w emulowanym systemie komputerowym skonfigurowano tak, aby udost˛epni´c konsol˛e operatora oraz komunikowa´c wszelkie wykryte bł˛edy przez port szeregowy.

Podczas uruchamiania Nadzorca nawi ˛azuje równie˙z poł ˛aczenie TCP/IP konsol ˛a sterowania QEMU (poł ˛aczenie 2 z rysunku 3.1). Konsola sterowania udost˛epnia wszelkie operacje maj ˛ace zwi ˛azek z przebiegiem emulacji i wstrzykiwania bł˛edów – np. pauza/wznowienie emulacji, podgl ˛ad/modyfikacja zawarto´sci pami˛eci RAM emulowanego systemu, czy konfiguracja warunkowego wstrzykni˛ecia bł˛edu. Dodatkowo na konsoli wypisywane s ˛a informacje pochodz ˛ace z profilowania i procesu wstrzykiwania bł˛edów.

Dzienniki wykonania stanowi ˛ace pełen zapis interakcji z SUT oraz emulatorem umieszczane s ˛a w plikach tekstowych. Pliki te s ˛a przedmiotem pó´zniejszej analizy przez Analizator.

Modyfikacje QEMU

Oprogramowanie QEMU zostało wzbogacone na potrzeby QEFI o dwa dodatkowe moduły:

moduł ´sledzenia wykonania oraz moduł wstrzykiwania bł˛edów. Moduł ´sledzenia wykonania jest odpowiedzialny za monitorowanie skonfigurowanych przy uruchomieniu QEMU zdarze´n.

Przykładowymi zdarzeniami s ˛a:

— wykonanie instrukcji skoku przez emulowany procesor SUT,

— wykonanie kodu SUT zaburzonego poprzednio wstrzykni˛eciem bł˛edu,

— wywołanie wskazanych funkcji j ˛adra systemu operacyjnego,

— zgłoszenie przerwania przez wskazane urz ˛adzenie,

— wykonanie akcji przez wskazane urz ˛adzenie.

Cz˛e´s´c z wymienionych zdarze´n nie jest dost˛epna do wykorzystania w ka˙zdej z konfiguracji SUT – szczegółowy opis wykorzystania poszczególnych zdarze´n wykorzystanych w eksperymentach przedstawiony jest w rozdziale 4.

Moduł wstrzykiwania bł˛edów słu˙zy modyfikacji ´srodowiska wykonania SUT w sposób, który symuluje wyst ˛apienie bł˛edu. Dowolne z emulowanych przez QEMU urz ˛adze´n mo˙ze by´c wzbogacone o funkcj˛e wstrzykiwania bł˛edów. Moduł wstrzykiwania bł˛edów realizuje zarówno natychmiastowe wstrzykni˛ecie bł˛edu (algorytm 3.3), jak i warunkowe (algorytm 3.4). Diagram sekwencji realizacji warunkowego wstrzykni˛ecia przedstawiony jest na rysunku 3.2.

Analizator

Analizator przetwarza dzienniki wykonania i realizuje algorytmy oceny w celu przygotowania zbiorczych statystyk kampanii. Wyj´sciowe dane zapisywane s ˛a w formacie CSV¹⁵

15 Ang. Comma-separated Values.

Nadzorca QEMU SUT

setupConditionalFaultInjection()

obsługa emulowanej funkcji issueCommand()

conditionalFaultInjectionCallback()

Rysunek 3.2: Diagram sekwencji warunkowego wstrzykni˛ecia bł˛edu

pozwalaj ˛acym na wizualizacj˛e oraz dalsz ˛a analiz˛e przez operatora z u˙zyciem oprogramowania typu Microsoft Excel, czy pakietu R-project¹⁶.

Przeprowadzanie eksperymentów

Sposób wykonania pojedynczego testu umo˙zliwia uruchomienie wielu testów jednocze´snie.

Jest to istotna cecha, dzi˛eki której wykorzystane s ˛a mo˙zliwo´sci wieloprocesorowych systemów komputerowych do przeprowadzania eksperymentów na masow ˛a skal˛e. QEFI zostało wyposa˙zone w funkcj˛e uruchamiania wielu instancji testów jednocze´snie. Prawidłowe działanie takiej konfiguracji zostało zapewnione poprzez nast˛epuj ˛ace decyzje projektowe:

— ka˙zda para programów Nadzorca/QEMU uruchamiana jest w dedykowanym katalogu roboczym,

— ka˙zda para programów Nadzorca/QEMU wykorzystuje unikatowe numery portów dla poł ˛acze´n TCP/IP,

— liczby słu˙z ˛ace do inicjalizacji generatorów liczb pseudolosowych s ˛a przydzielane globalnie ka˙zdej instancji Nadzorcy¹⁷,

— obrazy dysków twardych emulowanych systemów komputerowych u˙zywane s ˛a w trybie migawki, czyli ˙zadna modyfikacja zawarto´sci dysku nie jest zapisywana do pliku obrazu, a jedynie przechowywana w pami˛eci przez czas działania SUT.

QEFI z powodzeniem zostało uruchomione na serwerach Instytutu Informatyki Politechniki Warszawskiej, dzi˛eki czemu mo˙zliwe było znaczne skrócenie czasu potrzebnego na

16 http://www.r-project.org

17 Generatory liczb pseudolosowych wykorzystywane s ˛a przy wyznaczaniu zaburzanych lokalizacji oraz w funkcji delayedF aultInjectionCallback przedstawionej w algorytmie 3.4.

przeprowadzanie eksperymentów. Kolejnym etapem zwi˛ekszaj ˛acym mo˙zliwo´sci równoległego uruchamiania testów byłoby przystosowanie QEFI do rozproszonych ´srodowisk typu cluster¹⁸ oraz grid¹⁹. Instytut Informatyki Politechniki Warszawskiej z powodzeniem opracował rozwi ˛azanie przeprowadzania eksperymentów SWIFI w ´srodowiskach rozproszonych [99, 100]. Przystosowanie QEFI do takiego trybu pracy wymagałoby opracowania nast˛epuj ˛acych mechanizmów:

— konfiguracji ´srodowiska QEFI na w˛ezłach przetwarzania,

— dystrybucji ´srodowiska eksperymentu,

— zbierania dzienników wykonania przeprowadzonych testów,

— automatyzacji działania w˛ezłów przetwarzania.

Mo˙zliwym rozwi ˛azaniem problemu konfiguracji w˛ezłów przetwarzania byłoby przygotowanie obrazu maszyny wirtualnej (plik o wielko´sci około 3GB), który zawierałby przygotowane

´srodowisko QEFI (skompilowane wersje programów Nadzorca oraz QEMU). Obraz nale˙załoby pobra´c na w˛ezły przetwarzania i uruchomi´c maszyn˛e wirtualn ˛a. Rozwi ˛azanie tego typu jest mniej pracochłonne od konfiguracji QEFI na ka˙zdym z w˛ezłów osobno, poniewa˙z maskowane s ˛a ró˙znice poszczególnych w˛ezłów przetwarzania (np. ró˙zne systemy operacyjne, inne wersje zainstalowanych bibliotek programistycznych). Dystrybucja ´srodowiska eksperymentu sprowadza si˛e do dystrybucji na w˛ezły przetwarzania trzech plików: obrazu dysku twardego SUT, konfiguracji QEMU dla SUT oraz konfiguracji Nadzorcy. Najwi˛ekszym z wymienionych plików jest obraz dysku SUT – w zale˙zno´sci od konfiguracji mo˙ze to by´c od kilkuset MB to kilkunastu GB. Natomiast zbieranie dzienników wykonania mo˙ze by´c realizowane poprzez automatyczne wysyłanie ich na dedykowany serwer plików. Oprogramowanie automatyzacji działania w˛ezłów przetwarzania powinno realizowa´c nast˛epuj ˛ace zadania:

automatyczne pobieranie ´srodowiska eksperymentu, przeprowadzenie eksperymentu oraz wysłanie dzienników wykonania przeprowadzonych testów do wskazanego repozytorium.