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.