Wstrzykiwanie błędów oparte na modelach

Transkrypt

Wstrzykiwanie błędów oparte na modelach
ZESZYTY NAUKOWE WYDZIAŁU ELEKTRONIKI,
TELEKOMUNIKACJI I INFORMATYKI POLITECHNIKI GDAŃSKIEJ
Nr 9
Seria: ICT Young
2011
WSTRZYKIWANIE BŁĘDÓW OPARTE NA MODELACH ZASTOSOWANIA QEMU W ANALIZIE NIEZAWODNOŚCI
URZĄDZEŃ MOBILNYCH
Marcin Goliszewski1), Sławomir Chyłek1)
1)
Politechnika Warszawska, Instytut Informatyki
Streszczenie
Stosowane powszechnie metody wstrzykiwania błędów wykazują znaczące zróżnicowanie w
zależności od tego, czy aplikowane są do rzeczywistego systemu czy też do jego modelu. Artykuł ten
prezentuje kilka różnych podejść do problemu wstrzykiwania błędów w systemach modelowanych, a
także porównuje te podejścia z rozwiązaniami implementowanymi na rzeczywistych urządzeniach.
Największy nacisk położony został na opis metody analizy niezawodności urządzeń mobilnych
poprzez zastosowanie środowiska emulowanego. Przedstawione są podstawowe założenia tej
koncepcji, a także wyczerpująca dyskusja możliwości zastosowania oprogramowania QEMU w takim
wypadku wraz z uzasadnieniem poprawności tego podejścia. Przedstawione zostają również
możliwości dalszego rozwoju prezentowanych koncepcji oraz potencjalne kierunki przyszłych
działań w omawianym obszarze.
1. WSTĘP
Wstrzykiwanie błędów oparte na modelach jest metodą opartą na wykorzystaniu
środowisk emulowanych zamiast poddawania rzeczywistego sprzętu działaniu
niekorzystnych warunków. Modele mogą być tworzone na różnych poziomach abstrakcji od niskopoziomowych symulacji sprzętu do bardzo skomplikowanych symulacji środowisk
uruchomieniowych (ang. runtime) pracujących pod kontrolą istniejących systemów
operacyjnych. Symulacje mogą być przeprowadzane na poziomie mikroarchitektury (np.
modele sprzętu przygotowane w języku VHDL [1]), na poziomie instrukcji (np. QEMU,
Bochs), maszyn wirtualnych (np. VMWare, Xen) czy nawet na poziomie emulowanego
systemu operacyjnego (np. User Mode Linux [2]). Takie podejście ma wiele zalet w
porównaniu do tradycyjnych narzędzi typu SWIFI1) - np. możliwość testowania
niezmodyfikowanych programów czy też zdolność symulacji komponentów sprzętowych.
Obszarem naszych badań jest wstrzykiwanie błędów oraz obserwowanie propagacji
ich skutków w platformach mobilnych. Jako model urządzenia wybraliśmy platformę
1)
Software Implemented Fault Injection - Wstrzykiwanie Błędów Zrealizowane Programowo
Marcin Goliszewski, Sławomir Chyłek
QEMU. Platforma ta została wybrana ze względu na jej rozbudowane wsparcie dla
architektury ARM - niezwykle popularnej w konstrukcji urządzeń mobilnych. Dodatkową
zaletą QEMU jest jego dobra wydajność. Warto również nadmienić, iż QEMU jest
produkcyjnie stosowane w emulatorze telefonu komórkowego w Android SDK oraz było
uprzednio stosowane w badaniach naukowych [3], [4].
2. QEMU JAKO MODEL URZĄDZENIA MOBILNEGO
QEMU jest szybką i uniwersalną platformą emulacyjną oferującą wsparcie dla wielu
architektur docelowych, jak np. x86, ARM, SPARC itp. Wysoka wydajność QEMU została
osiągnięta dzięki zastosowaniu dynamicznej translacji kodu. Zasada działania tego
mechanizmu opiera się na tłumaczeniu każdej instrukcji emulowanej platformy na zestaw
natywnych instrukcji, które modyfikują struktury danych emulowanego procesora zamiast
operować na rejestrach procesora rzeczywistego. Wsparcie dla wielu architektur
docelowych osiągnięte zostało poprzez stworzenie serii implementacji odpowiadających za
odczyt instrukcji procesora docelowego i symulację wyników ich działania na strukturach
danych reprezentujących stan procesora. W celu zapewnienia kompletnej symulacji
rzeczywistego systemu, QEMU zapewnia zestaw wirtualnych urządzeń takich, jak karty
MMC, podsystem USB czy interfejsy sieciowe. Unikalną funkcjonalnością QEMU jest
możliwość emulacji nie tylko całego systemu, ale również pojedynczych procesów.
Dzięki emulacji niskopoziomowych elementów systemu zaimplementowanej w
QEMU możliwe jest zakłócanie różnych aspektów pracy emulowanego środowiska.
Istnieje możliwość implementacji szerokiego wachlarza technik wstrzykiwania błędów:
— zakłóceń w pamięci RAM,
— zakłóceń w rejestrach procesora,
— wadliwych urządzenia peryferyjnych,
— błędów w komponentach zintegrowanych w układzie scalonym (np. kontroler OHCI),
— zakłóceń komunikacji sieciowej.
Analogicznie, zastosowanie QEMU jako narzędzia wstrzykiwania błędów daje zysk w
postaci bardzo dobrej obserwowalności - możliwe jest obserwowanie rezultatów
wstrzykniętych błędów nie tylko na poziomie aplikacji, ale również na poziomie systemu
operacyjnego.
Biorąc pod uwagę szybkie tempo rozwoju produktów w przemyśle urządzeń
mobilnych oraz stale rosnące oczekiwania co do skracania cyklu rozwojowego sprzętu i
oprogramowania, zastosowanie QEMU jako modelu przyszłego systemu może przynosić
wymierne zyski. Jego użycie może pomóc w rozwiązaniu problemu tworzenia
oprogramowania dla platform sprzętowych będących w fazie przygotowania poprzez
tworzenie wirtualnych urządzeń podobnych do tych, które są dostarczane razem z QEMU szczególnie użyteczne w przypadku rozwoju sterowników sprzętowych, których jakość
niejednokrotnie odbija się w sposób znaczący na niezawodności systemu jako całości.
Niestety, tworzenie wirtualnego sprzętu jest zadaniem wymagającym niejednokrotnie
znaczącego nakładu pracy - emulowane urządzenia zazwyczaj są skomplikowanymi
maszynami stanów i posiadają nieoczywiste zależności czasowe od innych komponentów
systemu. Mimo wszystko, tworzenie i wykorzystywanie wirtualnego sprzętu wydaje się
być bardzo opłacalne nie tylko ze względu na możliwość jednoczesnego rozwoju sprzętu i
oprogramowania, ale również z uwagi na jego większą kontrolowalność, pozwalającą na
implementację technik wstrzykiwania błędów.
Wstrzykiwanie błędów oparte na modelach - zastosowania QEMU w analizie niezawodności...
Problemy niezawodności sterowników urządzeń i wpływu błędów we współpracy
sterowników ze sprzętem oraz z jądrem systemu operacyjnego są również opisywane w
literaturze [5], [6], [7]. Jednakże, dotychczasowe badania skupiały się wokół testowania i
pomiarów niezawodności systemów. Wydaje się, że potencjalne zyski wynikające z
tworzenia wirtualnych urządzeń nie powinny być zaniedbywane, gdyż technika ta może
przyspieszyć proces rozwoju sterowników sprzętowych, umożliwić tworzenie aplikacji dla
danego urządzenia zanim sprzęt z nim związany stanie się dostępny, a także pozwolić na
dogłębną walidację sprzętu względem jego specyfikacji.
3. PORÓWNANIE Z ROZWIĄZANIAMI IMPLEMENTOWANYMI NA
RZECZYWISTYCH URZĄDZENIACH
Najczęściej wymienianym zarzutem w stosunku do technik typu FIM 1) jest dokładność
wyników uzyskiwanych przy wykorzystaniu modeli. Główną wątpliwość stanowi pytanie o
odpowiedniość między symulowanym środowiskiem testowym a rzeczywistym sprzętem.
Dostępne są badania analizujące tę kwestię. W [8] zaprezentowane jest środowisko
wstrzykiwania błędów zrealizowane jako moduł jądra systemu Linux pozwalający na
symulację błędów typu bit-flip. Zostało ono przetestowane zarówno na rzeczywistym
komputerze x86, jak i na jego emulowanym odpowiedniku. Uzyskane wyniki są bardzo
obiecujące, gdyż rzeczywisty sprzęt i maszyna emulowana zdają się zachowywać bardzo
podobnie. Przykładowe wyniki tych eksperymentów zaprezentowane są poniżej:
Tablica 3.1
Statystyki wstrzykiwania błędów (eksperyment matrix) zaprezentowane w [8]
Prototyp emulowany
Prototyp rzeczywisty
IFN
NER
DR
FR
NER
DR
FR
D
8,256
86.38
2.97
10.65
87.06
2.89
10.05
C
8,240
18.68
60.84
20.48
20.43
59.45
20.12
R
1,152
19.53
79.43
1.04
18.84
79.51
1.65
Tablica 3.2
Statystyki wstrzykiwania błędów (eksperyment quick-sort) zaprezentowane w [8]
Prototyp emulowany
1)
Prototyp rzeczywisty
IFN
NER
DR
FR
NER
DR
FR
D
8,192
53.30
0.06
46.64
51.61
0.07
48.32
C
5,928
23.94
64.25
11.81
21.36
64.84
13.80
R
1,152
25.87
72.14
2.00
24.83
72.22
2.95
Fault Injection based on Models - Wstrzykiwanie Błędów oparte na Modelach
Marcin Goliszewski, Sławomir Chyłek
Tablica 3.3
Statystyki wstrzykiwania błędów (eksperyment Susan) zaprezentowane w [8]
Prototyp emulowany
Prototyp rzeczywisty
IFN
NER
DR
FR
NER
DR
FR
D
b.d.
b.d.
b.d.
b.d.
b.d.
b.d.
b.d.
C
281,248
72.40
20.12
7.48
75.96
17.93
6.11
R
1,152
20.12
73.92
5.96
18.97
74.79
6.24
gdzie: IFN
NER
DR
FR
D
C
R
Injected Faults Number - całkowita liczba wstrzykniętych błędów.
No Effect Ratio - odsetek wstrzyknięć bez obserwowanych wyników w
stosunku do całkowitej liczby przebiegów (w procentach). Miara ta
uwzględnia całkowitą liczbę wstrzyknięć, które nie wywołały usterki oraz
nie zostały zaobserwowane żadne anomalie podczas porównywania
wyników ze zbiorami referencyjnymi.
Detected Ratio - odsetek wstrzyknięć z wykrytymi błędami w stosunku
do całkowitej liczby przebiegów (w procentach). Miara ta uwzględnia
tylko liczbę błędów wykrytych przez system operacyjny i środowisko,
bez uwzględniania anomalii zaobserwowanych podczas porównywania
wyników ze zbiorami referencyjnymi.
Failure Ratio - odsetek wstrzyknięć zakończonych błędnym wynikiem w
stosunku do całkowitej liczby przebiegów (w procentach). Miara ta
uwzględnia całkowitą liczbę błędów wykrytych poprzez zaobserwowanie
anomalii podczas porównywania wyników ze zbiorami referencyjnymi.
Wstrzyknięcia w segment danych.
Wstrzyknięcia w segment kodu.
Wstrzyknięcia w plik rejestru.
Różnice wielkości NER, DR i FR między prototypem emulowanym i rzeczywistym
we wszystkich przeprowadzonych eksperymentach są mniejsze niż 3%. Praca ta pokazuje,
że nawet wstrzykiwanie niskopoziomowych błędów, jak błędy typu bit-flip, może dawać na
maszynie emulowanej wyniki bardzo podobne do maszyn rzeczywistych. Można
bezpiecznie założyć, że podobna charakterystyka wyników zostanie osiągnięta dla
architektury ARM, gdyż przedstawione eksperymenty nie wykorzystywały żadnych
specyficznych dla platformy x86 cech. W związku z tym, że ARM jest architekturą typu
RISC, można również założyć, że będzie ona mniej podatna na błędy typu bit-flip, zgodnie
z tym, co zostało pokazane w [9] w porównaniu przebiegu kampanii wstrzykiwania błędów
na procesorze Pentium 4 (CISC) i procesorze PowerPC G4 (RISC) , gdzie zaobserwowano,
że tego typu błędy na architekturze typu RISC dużo częściej nie są wcale widoczne.
Wstrzykiwanie błędów oparte na modelach - zastosowania QEMU w analizie niezawodności...
Tablica 3.4
Podatność na błędy typu bit-flip procesorów typu CISC i RISC zaprezentowane w [9]
P4
G4
Stos
43.9%
78.9%
Rejestry
systemow
Dane
e
Kod
89.5%
95.1%
34.1%
78.3%
31.4%
41.0%
Eksperymenty te prowadzą do wniosku, że niskopoziomowe błędy są dość
jednoznacznie przenoszone na błędy i usterki wyższego poziomu, a zatem błędy logiczne,
jak np. zmiana argumentów wywołania czy wartości zwracanych z funkcji w jądrze
systemu (np. w sterownikach urządzeń), powinny być również odpowiednio obserwowane
w środowisku emulowanym.
Wykonywanie eksperymentów w środowiskach emulowanych jest również znacząco
prostsze, gdyż nie wymagają one żadnych dodatkowych elementów sprzętowych do
monitorowania przebiegu eksperymentu, jak np. watchdog (podejście zastosowane w [9]),
które mogą być kosztowne. Innym zyskiem jest możliwość analizy stanu wewnętrznego
platformy docelowej w celu stwierdzenia przyczyn możliwych awarii systemu - uzyskanie
tego typu danych z rzeczywistego sprzętu może być bardzo kłopotliwe, szczególnie gdy
awaria wpłynie również na działanie interfejsów diagnostycznych. Brak tego typu danych o
śladzie wykonania w momencie zawieszenia pracy systemu został wytknięty w [10], gdzie
autorzy starali się analizować tego typu problemy na podstawie relacji programistów. W
QEMU istnieje możliwość zbierania tego typu danych poprzez modyfikację procedury
translacji binarnej w taki sposób, aby zapisywane były wszystkie akcje (nawet na poziomie
pojedynczych instrukcji) - podejście podobne do zaprezentowanego w [11] i [12].
Symulowane platformy mają również dodatkową zaletę - uruchamiane są na innej
maszynie sprzętowej. Jako, że urządzenia wbudowane charakteryzują się limitowanymi
zasobami, system emulowany może pracować szybciej niż rzeczywiste urządzenie. Warto
również zauważyć, że zapewnienie wielu urządzeń do wykonania kampanii testowania
niezawodności może być bardzo kosztowne, zaś uruchomienie wielu instancji QEMU na
kilku serwerach może znacząco te koszty zredukować.
4. ZAKOŃCZENIE
Opisane powyżej własności podejścia typu FIM sprawiają, że jest ono bardzo
interesującym, choć jak do tej pory słabo zbadanym obszarem badań. Prace opisane w
niniejszym artykule zostały przeprowadzone we współpracy z Centrum BadawczoRozwojowym Samsung Electronics Polska w Warszawie jako część wspólnego projektu
Adapting fault injection techniques to improve Samsung mobile products. Projekt ten jest
współfinansowany przez Polską Agencję Rozwoju Przedsiębiorczości w ramach działania
1.4 Wsparcie projektów celowych osi priorytetowej 1 Badania i rozwój nowoczesnych
technologii oraz działania 4.1 Wsparcie wdrożeń wyników prac B+R osi priorytetowej
4 Inwestycje w innowacyjne przedsięwzięcia. W trakcie tego projektu wiele metod
wykorzystania podejścia FIM zostało zaproponowanych, zaimplementowanych i
przetestowanych. Najważniejsze z nich to: implementacja wirtualnych urządzeń
Marcin Goliszewski, Sławomir Chyłek
testujących, testowanie w środowisku emulowanych przypadków użycia krytycznych dla
użytkowników końcowych oraz wsparcie rozwoju komponentów jądra systemu
operacyjnego. Planujemy opublikować szczegółowe informacje na temat wykorzystanych
metod oraz uzyskanych wyników w kilku następnych artykułach. Istotny jest fakt, że cały
zaprezentowany materiał dowodzi, że wstrzykiwanie błędów oparte na modelach stwarza
możliwość poszukiwania nowatorskich podejść do procesów wstrzykiwania błędów zarówno jeśli chodzi o prace teoretyczne, jak i ich zastosowania w przemyśle. Planujemy
kontynuować badania w tej dziedzinie i zaprezentować je w niedalekiej przyszłości.
BIBLIOGRAFIA
[1] Jenn, E., Arlat, J., Rimen, M., Ohlsson, J., Karlsson, J.: Fault injection into VHDL
models: the MEFISTO tool, 1994.
[2] Buchacker, K., Sieh, V.: Framework for testing the fault-tolerance of systems
including OS and network aspects: Proceedings of the Sixth IEEE International
Symposium on High Assurance Systems Engineering. 24-26 October 2001,
Albuquerque, NM, USA, s. 95.
[3] Han, A.H., Young-Si Hwang, Young-Ho An, So-Jin Lee, Ki-Seok Chung: Virtual
ARM Platform for embedded system developers, 2008.
[4] Onoue, K., Oyama, Y., Yonezawa, A.: A Virtual Machine Migration System Based on
a CPU Emulator, 2006.
[5] Albinet, A., Arlat, J., Fabre, J.: Characterization of the impact of faulty drivers on the
robustness of the Linux kernel: Proceedings of the 2004 International Conference on
Dependable Systems and Networks, June 28th - July 1, 2004, Florence, Italy, s. 867.
[6] Duraes, J., Madeira, H.: Characterization of operating systems behavior in the
presence of faulty drivers through software fault emulation: Proceedings of the 2002
Pacific Rim International Symposium on Dependable Computing, 16-18 December
2002, Tsukuba-City, Ibarski, Japan, s. 201.
[7] Edwards, D., Matassa, L.: An approach to Injecting Faults into Hardened Software:
Proc. OLS, Ottawa, ON, Canada, s. 146-175
[8] Murciano, M., Violante: Validating the dependability of embedded systems through
fault injection by means of loadable kernel modules: Proceedings of the 2007 IEEE
International High Level Design Validation and Test Workshop, s. 179.
[9] Weining Gu, Kalbarczyk, Z., Iyer, R.K.: Error sensitivity of the Linux kernel
executing on PowerPC G4 and Pentium 4 processors: Proceedings of the 2004
International Conference on Dependable Systems and Networks, June 28th - July 1,
2004, Florence, Italy, s. 887.
[10] Cotroneo, D., Natella, R., Russo, S.: Assessment and Improvement of Hang Detection
in the Linux Operating System: Proceedings of the 28th IEEE International
Symposium on Reliable Distributed Systems, 2009, s. 288.
[11] Liu, X., Liu, T., Bai, Z., Wang, Y., Mu, H., Li, C.: PORD: a Reversible Debugging
Tool using Dynamic Binary Translation, 2007.
[12] Chylek, S.: Collecting program execution statistics with QEMU processor emulator:
Proceedings of the 2009 International Multiconference on Computer Science and
Information Technology, 12-14 October 2009, Mrągowo, Poland, s. 555.

Podobne dokumenty