Kody ´zródłowe QEFI oraz dodatkowe zasoby mo˙zna znale´z´c w repozytorium projektu znajduj ˛acym si˛e pod adresem http://chylek.name/qefi/.
A.1. QEFI
Narz˛edzie QEFI składa si˛e z kilku współpracuj ˛acych ze sob ˛a programów w celu realizacji eksperymentów symulowania bł˛edów w systemie komputerowym.
A.1.1. QEMU
Podstawowym komponentem QEFI jest emulator systemu komputerowego QEMU. W QEFI wykorzystano oprogramowanie QEMU w wersji 1.1.2. W celu realizacji metodyki symulowania bł˛edów zmodyfikowane zostały nast˛epuj ˛ace moduły QEMU:
Moduł Fault Injection – Opracowano nowy moduł realizuj ˛acy zaburzanie pami˛eci oraz kontroluj ˛acy wyzwalanie warunkowego wstrzykiwania bł˛edu.
Moduł ´sledzenia wykonania – Opracowano nowy moduł realizuj ˛acy nieinwazyjne
´sledzenie wykonania poprzez rejestrowanie wykonania instrukcji skoków przez emulowany procesor.
Moduł konsoli sterowania – Modyfikacja modułu konsoli sterowania umo˙zliwiaj ˛aca wykonywanie komend steruj ˛acych procesem symulacji bł˛edów oraz profilowania.
Moduł translacji binarnej – Modyfikacje polegaj ˛ace na wplataniu w kod wygenerowany w procesie binarnej translacji dodatkowych funkcji realizuj ˛acych zarówno symulowanie bł˛edów, jak i profilowanie.
Moduł dost˛epu do pami˛eci – Modyfikacje umo˙zliwiaj ˛ace symulowanie bł˛edów danych przy odczycie, wykorzystane w procesie zaburzania pami˛eci alokowanej przez system operacyjny.
Moduł emuluj ˛acy urz ˛adzenie USB MSD – Modyfikacje umo˙zliwiaj ˛ace symulowanie bł˛edów w pakietach wysyłanych z urz ˛adzenia USB MSD.
Moduł emuluj ˛acy urz ˛adzenie USB UHCI – Modyfikacje umo˙zliwiaj ˛ace symulowanie bł˛edów w rejestrach kontrolera USB UHCI.
Moduł emuluj ˛acy urz ˛adzenie e1000 – Modyfikacje umo˙zliwiaj ˛ace symulowanie bł˛edów w deskryptorach pakietów pochodz ˛acych z urz ˛adzenia sieciowego e1000.
Poni˙zej zamieszczony jest listing nowych komend konsoli sterowania QEMU:
fi_enable – Komenda powoduje wł ˛aczenie funkcji zwi ˛azanych ze wstrzykiwaniem bł˛edów.
fi_disable – Komenda powoduje wył ˛aczenie funkcji zwi ˛azanych ze wstrzykiwaniem bł˛edów.
fi_write_pmem – Parametry: adres fizyczny, nowa warto´s´c bajtu. Komenda pozwala zapisa´c dowolny bajt w pami˛eci operacyjnej wskazany adresem fizycznym.
fi_write_vmem – Parametry: adres pami˛eci wirtualny, nowa warto´s´c bajtu. Komenda pozwala zapisa´c dowolny bajt w pami˛eci operacyjnej wskazany adresem pami˛eci wirtualnej.
Komenda mo˙ze by´c wykonana wył ˛acznie po wstrzymaniu procesu emulacji, a zaburzana pami˛e´c wirtualna jest pami˛eci ˛a procesu wykonywanego przed wstrzymaniem.
fi_random_bit_vmem_range – Parametry: pocz ˛atek zakresu pami˛eci wirtualnej, koniec zakresu pami˛eci wirtualnej. Komenda powoduje wprowadzenie pojedynczego bł˛edu typu bit-flip w losowo wybran ˛a komórk˛e pami˛eci spo´sród zadanego zakresu. Komenda mo˙ze by´c wykonana wył ˛acznie po wstrzymaniu procesu emulacji, a zaburzana pami˛e´c wirtualna jest pami˛eci ˛a procesu wykonywanego przed wstrzymaniem.
fi_disturb_usb_msd – Parametry: prawdopodobie´nstwo zaburzenia pakietu. Komenda powoduje wprowadzenie pojedynczego bł˛edu typu bit-flip w losowo wybrany bit pakietu danych wysyłanych z urz ˛adzenia USB MSD. Wybór zaburzanego pakietu jest warunkowy, sterowany prawdopodobie´nstwem – tzn. przy ka˙zdej operacji wysyłania pakietu z urz ˛adzenia USB MSD wybierana jest losowa liczba z zakresu [0−1]; je˙zeli jest ona mniejsza ni˙z zadane prawdopodobie´nstwo, to do pakietu wprowadzany jest bł ˛ad.
fi_disturb_usb_uhci – Parametry: prawdopodobie´nstwo wprowadzenia bł˛edu przy aktualizacji stanu rejestrów USB UHCI. Komenda powoduje wprowadzenie pojedynczego bł˛edu typu bit-flip w losowo wybrany bit w losowo wybranym rejestrze kontrolera USB UHCI – wybór momentu wprowadzenia bł˛edu jest warunkowy, sterowany prawdopodobie´nstwem – tzn. przy ka˙zdej operacji aktualizacji stanu rejestrów USB UHCI wybierana jest losowa liczba z zakresu [0 − 1]; je˙zeli jest ona mniejsza ni˙z zadane prawdopodobie´nstwo, to do losowego rejestru wprowadzany jest bł ˛ad.
fi_disturb_e1000 – Parametry: prawdopodobie´nstwo zaburzenia deskryptora pakietu.
Komenda powoduje wprowadzenie pojedynczego bł˛edu typu bit-flip w losowo wybrany bit deskryptora pakietu danych pochodz ˛acych z urz ˛adzenia sieciowego e1000. Wybór zaburzanego deskryptora pakietu jest warunkowy, sterowany prawdopodobie´nstwem – tzn. przy ka˙zdej operacji wysyłania deskryptora pakietu z urz ˛adzenia e1000 wybierana jest losowa liczba z zakresu [0 − 1]; je˙zeli jest ona mniejsza ni˙z zadane prawdopodobie´nstwo, to do pakietu wprowadzany jest bł ˛ad.
fi_disturb_stack – Parametry: prawdopodobie´nstwo wprowadzenia bł˛edu, zakres zaburzanej przestrzeni stosu. Komenda powoduje wprowadzenie pojedynczego bł˛edu typu bit-flip w losowo wybrany bit danych w okre´slonym zakresie liczonym od wierzchołka stosu. Wybór momentu wprowadzenia bł˛edu jest warunkowy, sterowany prawdopodobie´nstwem – tzn. przy ka˙zdym wykonaniu przez emulowany procesor instrukcji call, wybierana jest losowa liczba z zakresu [0 − 1]; je˙zeli jest ona mniejsza ni˙z zadane prawdopodobie´nstwo, to w okre´slonym zakresie danych wprowadzany jest bł ˛ad.
fi_disturb_allocked_mem – Parametry: prawdopodobie´nstwo wprowadzenia bł˛edu, adres funkcji trace_kmalloc, adres funkcji kfree. Komenda powoduje wprowadzenie pojedynczego bł˛edu typu bit-flip w losowo wybrany bit danych spo´sród danych zaalokowanych przez system operacyjny od momentu wydania komendy. Zbiór danych jest wyznaczany dynamicznie poprzez ´sledzenie wywoła´n funkcji kmalloc oraz kfree.
Wybór momentu wprowadzenia bł˛edu jest warunkowy, sterowany prawdopodobie´nstwem – tzn. przy ka˙zdej operacji odczytu danych przez emulowany procesor z wyznaczonego zbioru danych alokowanych, wybierana jest losowa liczba z zakresu [0−1]; je˙zeli jest ona mniejsza ni˙z zadane prawdopodobie´nstwo, to w odczytywanych zakresie danych wprowadzany jest bł ˛ad.
fi_enable_trace – Komenda powoduje wł ˛aczenie trybu ´sledzenia wykonania. W katalogu roboczym QEMU tworzony jest plik zawieraj ˛acy skompresowan ˛a algorytmem GZIP histori˛e skoków wykonanych przez procesor.
fi_disable_trace – Komenda powoduje wył ˛aczenie trybu ´sledzenia wykonania.
A.1.2. Nadzorca
Nadzorca jest programem kontroluj ˛acym przebieg wykonania testu. Jego głównym zadaniem jest uruchomienie instancji QEMU i wykonanie kroków scenariusza testowego.
Oprogramowanie nadzorcy nawi ˛azuje poł ˛aczenia konsol ˛a sterowania QEMU oraz emulowanym portem szeregowym emulowanego systemu. Opcjonalnie Nadzorca uruchamia dodatkowe programy przeprowadzaj ˛ace interakcj˛e z emulowanym systemem (np. skrypty programu expect realizuj ˛ace szyfrowane poł ˛aczenia ssh). Predefiniowane jest kilka typów scenariuszy testowych (dokładny wykaz poni˙zej), a nowe scenariusze mog ˛a by´c dodawane według potrzeb poprzez rozszerzenie programu Nadzorcy. Mo˙zliwe jest uruchomienie scenariusza testowego w trybie profilowania, gdzie bł ˛ad nie jest wstrzykiwany, natomiast zbierane s ˛a dane z nieinwazyjnego
´sledzenia wykonania. Dla niektórych scenariuszy konieczne mo˙ze by´c dostarczenie danych z profilowania.
Flagi uruchamiania programu Nadzorcy:
trace – Wykonanie scenariusza bez symulacji bł˛edu, natomiast zbierane s ˛a dane z nieinwazyjnego ´sledzenia wykonania.
fault – Typ bł˛edu spo´sród typów bł˛edów zdefiniowanych dla danego scenariusza testowego.
port_control – Numer portu, na którym ma by´c prowadzona komunikacja Nadzorcy z konsol ˛a sterowania QEMU.
port_serial – Numer portu, na którym ma by´c prowadzona komunikacja Nadzorcy z emulowanym portem szeregowym SUT.
scenario – Uruchomiony scenariusz testowy. Dost˛epne scenariusze:
— wget – Scenariusz realizuj ˛acy kroki opisane w Scenariuszu 4.1 (strona 75). Dost˛epne typy bł˛edów: zaburzanie pami˛eci fizycznej, zaburzanie danych pami˛eci wirtualnej, zaburzanie kodu wyznaczonego z profilowania, zaburzanie danych alokowanych, zaburzanie danych na stosie.
— curl – Scenariusz analogiczny do scenariusza wget wykorzystuj ˛acy program curl zamiast wget. Dost˛epne typy bł˛edów: zaburzanie pami˛eci fizycznej.
— pendrive – Scenariusz realizuj ˛acy kroki opisane w Scenariuszu (strona 4.2).
Dost˛epne typy bł˛edów: zaburzanie pakietów wysyłanych z urz ˛adzenia USB MSD, zaburzanie warto´sci zawarto´sci rejestrów urz ˛adzenia USB UHCI.
— srv – Scenariusz realizuj ˛acy kroki opisane w Scenariuszu 4.3 (strona 108).Dost˛epne typy bł˛edów: zaburzanie kodu wyznaczonego z profilowania, zaburzanie danych alokowanych, zaburzanie danych na stosie.
W wyniku działania programu Nadzorcy wytworzone s ˛a nast˛epuj ˛ace artefakty:
appxLogFile.log – Dziennik programu Nadzorcy.
login.txt – Zapis interakcji programu Nadzorcy z SUT na kanale konsoli szeregowej od momentu uruchomienia SUT do uruchomienia systemu operacyjnego działaj ˛acego w SUT.
experiment.txt – Zapis interakcji programu Nadzorcy z SUT na kanale konsoli szeregowej od momentu uruchomienia systemu operacyjnego działaj ˛acego w SUT.
monitor.txt – Zapis interakcji programu Nadzorcy z konsol ˛a sterowania QEMU.
serr.txt, sout.txt – Zrzut danych wypisanych przez program QEMU na standardowy strumie´n wyj´scia oraz standardowy strumie´n bł˛edów.
run.log – Dziennik wykonania scenariusza przez program Nadzorcy.
output.gz – Opcjonalny plik zawieraj ˛acy skompresowane dane z profilowania.
kallsyms.txt – Opcjonalny plik (zale˙zny od scenariusza) zawieraj ˛acy zrzut pliku /proc/kallsymssystemu operacyjnego działaj ˛acego w SUT.
sshout.txt, sshserr.txt, wgetserr.txt, wgetsout.txt, ... – Opcjonalne pliki zawieraj ˛ace zrzut danych wypisanych przez dodatkowe programy uruchomione przez program Nadzorcy na standardowy strumie´n wyj´scia oraz standardowy strumie´n bł˛edów.
A.1.3. Ekstraktor
Program Ekstraktor jest programem pomocniczym realizuj ˛acym dekodowanie pliku z zapisanymi informacjami z profilowania – adresy skoków wykonanych przez procesor tłumaczone s ˛a na nazwy funkcji j ˛adra systemu operacyjnego. Program działa na podstawie plików output.gz i kallsyms.txt, które s ˛a artefaktami wykonania scenariusza testowego przez program Nadzorcy w trybie trace. Szczegółowy schemat działania programu jest opisany w [24].
A.1.4. Eksperyment
Eksperyment jest to skrypt realizuj ˛acy uruchomienie wielu instancji par programów Nadzorca-QEMU w celu wykonania zadanej liczby testów. Parametry skryptu to:
rootdir – Główny katalog, w którym tworzone s ˛a podkatalogi b˛ed ˛ace katalogami roboczymi par programów Nadzorca-QEMU (w podkatalogach składowane s ˛a artefakty ka˙zdej instancji programu Nadzorcy).
port_range_control_start – liczba, na podstawie której wyliczany jest parametr port_control programu Nadzorcy (port_control = port_range_control_start + identyfikator instancji programu Nadzorcy nadany przez skrypt Eksperyment z zakresu 1..jobs).
port_range_serial_start – liczba, na podstawie której wyliczany jest parametr port_serial programu Nadzorcy (port_serial = port_range_serial_start + identyfikator instancji programu Nadzorcy nadany przez skrypt Eksperyment z zakresu 1..jobs).
jobs – Liczba jednocze´snie uruchomionych instancji par programów Nadzorca-QEMU. W momencie zako´nczenia działania jednej z instancji uruchamiana jest nowa instancja, której przydzielany jest nowy katalog roboczy.
tests – Liczba testów do wykonania.
A.1.5. Analizator
Program Analizator dokonuje podsumowania wyników wygenerowanych z u˙zyciem skryptu Eksperyment. Wyposa˙zony jest on w baz˛e komunikatów, których obecno´s´c sprawdza w artefaktach programu Nadzorca. Posiada on te˙z wbudowane referencyjne dane scenariuszy – w szczególno´sci funkcje oceny pozwalaj ˛ace okre´sli´c, czy dany test zako´nczył si˛e wynikiem prawidłowym. Wynikiem działania programu jest plik CSV zawieraj ˛acy podsumowanie wykrytych cech dla ka˙zdego z przeprowadzonych testów. Parametry wywołania programu to:
rootdir – Główny katalog, w którym znajduj ˛a si˛e katalogi z artefaktami przeznaczonymi do analizy.
workers – Liczba w ˛atków równocze´snie analizuj ˛acych artefakty.
scenario – Referencyjny scenariusz. Dost˛epne scenariusze: wget, curl, pendrive, srv.
csv – Nazwa pliku stanowi ˛acego wynik działania programu.
viewerrors – Przeł ˛acznik umo˙zliwiaj ˛acy przegl ˛ad dzienników wykonania testów z zamanifestowanym bł˛edem.
performance – Przeł ˛acznik powoduj ˛acy zbieranie dodatkowych danych dotycz ˛acych czasu wykonania testów.
A.2. Zmiany w j ˛ adrze systemu GNU/Linux
W celu implementacji mechanizmów zwi˛ekszania niezawodno´sci wprowadzono nast˛epuj ˛ace zmiany w j ˛adrze systemu GNU/Linux (wersja 2.6.32):
arch/x86/mm/fault.c – Zmodyfikowana została funkcja no_context_fail odpowiedzialna za zgłoszenie awarii wykonywanego zadania w przypadku zgłoszenia przerwania nieprawidłowego odwołania do pami˛eci. Wykonanie tej funkcji zostało uzale˙znione od warto´sci zwracanej przez now ˛a funkcj˛e no_context_fail_check, która działa zgodnie z opisem funkcji F opisanej w 5.6.1 (strona 126) i jej działanie mo˙ze by´c zmodyfikowane z u˙zyciem mechanizmu kprobes. Je˙zeli funkcja no_context_fail_checkzwróci warto´s´c TRUE, to zgłoszenie awarii jest zaniechane, a działanie zadania zgłaszaj ˛acego przerwanie jest wznowione.
arch/x86/kernel/traps.c – Zmodyfikowana została funkcja fixup_exception odpowiedzialna za podj˛ecie próby naprawy przerwania general protection fault. Je˙zeli domy´slne działanie funkcji nie przyniosło efektu, wywoływana jest dodatkowa funkcja fixup_exception_check, która działa zgodnie z opisem funkcji F opisanej w 5.6.1 (strona 126) i jej działanie mo˙ze by´c zmodyfikowane z u˙zyciem mechanizmu kprobes.
Je˙zeli funkcja fixup_exception_check zwróci warto´s´c TRUE, to sygnalizowane jest naprawienie bł˛edu i działanie zadania zgłaszaj ˛acego przerwanie jest wznowione.