4. Badania eksperymentalne
4.5. Eksperymenty ukierunkowane na j ˛ adro systemu operacyjnego
4.5.3. Zastosowanie profilowania do zaburzania kodu, stosu oraz danych alokowanych
Eksperymenty zaburzaj ˛ace pami˛e´c RAM przedstawione do tej pory wymagały minimalnej ingerencji w ´srodowisko emulatora. Niemniej uzyskane w nich rezultaty nie s ˛a pełne, poniewa˙z brakowało w nich informacji o zaburzanych danych (patrz 4.2) lub zaburzany był kod systemu operacyjnego, niezale˙znie od tego, czy kod ten był wykonywany w przebiegu scenariusza (patrz 4.5.2). Istotnym problemem jest równie˙z niska efektywno´s´c przeprowadzanych eksperymentów, gdzie maksymalny odsetek zamanifestowanych bł˛edów wynosił zaledwie 5%
dla zaburzania rejonu pami˛eci zawieraj ˛acego kod systemu operacyjnego.
W celu rozwi ˛azania wymienionych problemów podj˛ete zostały działania polegaj ˛ace na wzbogaceniu ´srodowiska emulatora QEMU o autorskie mechanizmy pozwalaj ˛ace profilowa´c i zaburza´c zarówno kod, stos, a tak˙ze dane alokowane przez system operacyjny. Wprowadzone zmiany polegaj ˛a na modyfikacji procesu binarnej translacji opisanej w podrozdziale 3.2 oraz sekcji 3.4.3. Opracowany został zintegrowany z QEMU moduł ´sledzenia wykonania (patrz 3.4.6). ´Sledzenie ka˙zdego z wymienionych typów danych wymagało zastosowania innych technik, które s ˛a opisane w dalszej cz˛e´sci rozdziału. Dzi˛eki zastosowaniu profilowania osi ˛agni˛eto du˙z ˛a efektywno´s´c przeprowadzanych eksperymentów w sensie współczynnika manifestacji wstrzykni˛etych bł˛edów.
Eksperymenty opisane poni˙zej maj ˛a na celu wyznaczenie charakterystyki niezawodno´sci systemu operacyjnego przy ró˙znych obci ˛a˙zeniach. Wykorzystano dwa scenariusze testowe.
Pierwszy z nich to scenariusz opisany w 4.2. Wyniki uzyskane w eksperymencie pozwalaj ˛a
na ocen˛e zysku z zastosowania profilowania wzgl˛edem eksperymentów przeprowadzonych w 4.2 oraz 4.5.2. Natomiast drugi scenariusz wzorowany jest na cz˛estym zastosowaniu systemu komputerowego jako serwera HTTP.
Profilowanie i zaburzanie kodu systemu operacyjnego
Poprawa efektywno´sci zaburzania kodu systemu operacyjnego zwi ˛azana jest z wyznaczeniem funkcji, które s ˛a wywoływane w trakcie przebiegu scenariusza testowego. Jednym z mo˙zliwych rozwi ˛aza´n byłoby skorzystanie z mechanizmów profilowania dost˛epnych w j ˛adrze systemu GNU/Linux. Alternatywn ˛a opcj ˛a było zastosowanie nieinwazyjnego ´sledzenia opracowanego przez autora i opisanego w [24]. Technika ta polega na nagraniu adresów docelowych skoków wykonanych przez procesor pracuj ˛acy w trybie j ˛adra systemu operacyjnego (w celu odfiltrowania skoków wykonywanych przez programy u˙zytkownika) oraz na ich podstawie wyznaczenie wykonywanych funkcji z pomoc ˛a informacji zawartych w pliku /proc/kallsyms15. Podczas przeprowadzanych eksperymentów wybrana została metoda nieinwazyjna, poniewa˙z jest to metoda dokładna16i w czasie profilowania nie anga˙zuje w ˙zaden sposób badanego systemu operacyjnego.
Zastosowanie profilowania powoduje konieczno´s´c jednokrotnego uruchomienia eksperymentu bez wstrzykni˛ecia bł˛edu w celu wyznaczenia zbioru funkcji j ˛adra wykorzystywanych podczas zadanego scenariusza testowego. Zebrane informacje słu˙z ˛a nast˛epnie do okre´slenia zakresów zaburzanej pami˛eci. Reasumuj ˛ac, wykorzystanie profilowania w eksperymencie wi ˛a˙ze si˛e z nast˛epuj ˛acymi czynno´sciami:
1. modyfikacja scenariusza o krok odczytuj ˛acy zawarto´s´c pliku /proc/kallsyms,
2. przeprowadzenie pojedynczego testu bez wstrzykiwania bł˛edu i zebranie informacji o funkcjach wykonanych w przestrzeni systemu operacyjnego17,
3. podczas przeprowadzania testów ze wstrzykiwaniem bł˛edu:
a) losowe wybranie funkcji systemu operacyjnego, która jest celem zaburzenia, b) wyznaczenie zakresu pami˛eci, pod którym znajduje si˛e docelowa funkcja18,
c) wykorzystanie wyznaczonego zakresu jako parametru procedury wstrzykiwania bł˛edu.
Dodatkowym mechanizmem, który został wprowadzony do translacji binarnej, jest wykrywanie liczby wykona´n zaburzonej instrukcji. Modyfikacja ta polega na umieszczeniu w buforze translacji binarnej procedury pozostawiaj ˛acej ´slad w dzienniku eksperymentu.
15 Plik /proc/kallsyms udost˛epnia list˛e wszystkich funkcji systemu operacyjnego zawartych w statycznym obrazie j ˛adra oraz modułach wraz z ich adresami w wirtualnej przestrzeni adresowej.
16 Standardowe mechanizmy profilowania (np. oprofile) systemu GNU/Linux polegaj ˛a na zbieraniu próbek co pewien okre´slony interwał czasu, przez co zbierane s ˛a informacje o cz˛esto wykonywanych procedurach, ale nie o wszystkich procedurach wykonanych podczas profilowania.
17 Wyznaczenie zbioru wykonanych funkcji odbywa si˛e poprzez dopasowanie nagranych technik ˛a nieinwazyjnego ´sledzenia adresów instrukcji do funkcji systemu operacyjnego, do których te funkcje nale˙z ˛a.
18 Wyznaczenie to odbywa si˛e na podstawie odczytanej zawarto´sci pliku /proc/kallsyms w danym te´scie, poniewa˙z funkcje zdefiniowane w ładowanych modułach mog ˛a by´c załadowane w inne rejony pami˛eci dla ka˙zdego testu.
Dodawana procedura jest zawsze umieszczana bezpo´srednio przed kodem emuluj ˛acym zmienion ˛a instrukcj˛e. Zebrane dzi˛eki temu dane pozwalaj ˛a stwierdzi´c ile razy wykonana była przekłamana instrukcja i powi ˛aza´c te wyniki z informacjami o manifestacji bł˛edów.
Zaburzanie stosu systemu operacyjnego
Zaburzenie stosu w ˛atków wykonania w przestrzeni systemu operacyjnego jest zadaniem, które wymaga dynamicznego wyznaczania docelowych adresów wstrzykni˛e´c bł˛edów. Jest to spowodowane faktem, ˙ze stos jest struktur ˛a cz˛esto modyfikowan ˛a. Próba dwuetapowego wstrzykni˛ecia, jak to miało miejsce w przypadku kodu, mo˙ze by´c nieskuteczna w zwi ˛azku ze zwini˛eciem stosu w odst˛epie czasu mi˛edzy wyznaczeniem zaburzanej przestrzeni, a faktycznym wstrzykni˛eciem.
W przeprowadzonych eksperymentach wykorzystano mo˙zliwo´s´c modyfikacji procesu translacji binarnej. Podobnie jak w przypadku profilowania kodu przed ka˙zd ˛a instrukcj ˛a skoku w przestrzeni j ˛adra wykonywana jest specjalna procedura. Niemniej zamiast zbierania informacji o adresie docelowym skoku przed wykonaniem instrukcji wywołania procedury call zaburzana jest pami˛e´c stosu w zakresie n bajtów pocz ˛awszy od wierzchołka stosu (czyli od adresu zawartego w rejestrze ESP19. Moment wstrzykni˛ecia jest wybierany warunkowo według zadanego prawdopodobie´nstwa (patrz 3.4.5).
Zaburzanie danych alokowanych
Wyznaczenie adresów danych alokowanych w przestrzeni j ˛adra systemu operacyjnego jest zadaniem wymagaj ˛acym dogł˛ebnej znajomo´sci badanego systemu operacyjnego. System GNU/Linux dysponuje kilkoma mechanizmami przydziału pami˛eci (patrz 2.1.2). S ˛a to mi˛edzy innymi kmalloc, kmem_cache oraz vmalloc. Ka˙zdy z tych mechanizmów jest zoptymalizowany do innego scenariusza u˙zycia: kmalloc słu˙zy do alokacji małych porcji pami˛eci ogólnego przeznaczenia (najefektywniej buforów o rozmiarze mniejszym ni˙z pojedyncza strona pami˛eci, czyli 4096 bajtów), kmem_cache wyspecjalizowany jest w przechowywaniu obiektów jednego typu o tym samym rozmiarze (np. w˛ezłów struktur drzewiastych), natomiast vmalloc pozwala alokowa´c du˙ze i w miar˛e mo˙zliwo´sci ci ˛agłe (w sensie fizycznej przestrzeni adresowej) obszary pami˛eci. W przeprowadzonych eksperymentach skupiono si˛e na zaburzaniu pami˛eci alokowanej z u˙zyciem mechanizmu kmalloc, poniewa˙z jest to najbardziej ogólny z wymienionych mechanizmów alokacji.
Zaproponowan ˛a metod˛e mo˙zna rozszerzy´c na pozostałe strategie alokacji.
Procedura wstrzykni˛ecia bł˛edu w pami˛e´c alokowan ˛a wymaga dynamicznego ´sledzenia, gdzie w przestrzeni adresowej znajduje si˛e ten typ pami˛eci. Dodatkowo bardzo istotne jest równie˙z monitorowanie dost˛epu do wyznaczonych rejonów, poniewa˙z wstrzykni˛ecie w
19 Ang. Extended Stack Pointer – rejestr zawieraj ˛acy wska´znik stosu w architekturach z rodziny x86.
momencie alokacji powoduje zaburzenie pami˛eci, która jeszcze nie została wypełniona danymi do przetworzenia, co czyni tak ˛a operacj˛e bezcelow ˛a.
W celu zbierania informacji o alokowanej pami˛eci zastosowano strategi˛e zbli˙zon ˛a do sposobu działania przedstawionego przy zaburzaniu stosu. W odró˙znieniu od wspomnianego mechanizmu punktem zastosowania wstrzykni˛etej procedury nie s ˛a instrukcje wywoła´n wszystkich funkcji wykonywanych w przestrzeni j ˛adra, a jedynie instrukcje wywoła´n funkcji trace_kmalloc oraz kfree. Funkcja trace_kmalock jest wywoływana zawsze na ko´ncu działania procedury przydziału pami˛eci (funkcja kmalloc) w celu poinformowania wewn˛etrznych mechanizmów j ˛adra GNU/Linux o fakcie przydziału pami˛eci (m.in. w celu zbierania statystyk o fragmentacji). Funkcja ta została wybrana, poniewa˙z jej argumentami s ˛a zarówno parametry wywołania kmalloc (rozmiar alokowanego bufora) oraz jej rezultat (adres przydzielonego bufora). W analogiczny sposób monitorowana jest funkcja kfree, która odpowiedzialna jest za zwolnienie poprzednio przydzielonej pami˛eci. Dzi˛eki informacjom zebranym w ten sposób mo˙zliwe jest przechowywanie w ´srodowisku emulatora pełnej informacji o pami˛eci przydzielonej wewn ˛atrz emulowanego systemu operacyjnego bez ingerencji w jego działanie.
W celu zapewnienia, ˙ze zaburzone dane s ˛a wykorzystywane przez system operacyjny, moment wstrzykni˛ecia został ´sci´sle powi ˛azany z odczytem tych danych. Zrealizowane to zostało poprzez zmodyfikowanie wewn˛etrznych procedur QEMU odpowiedzialnych za odczyt emulowanej pami˛eci w ten sposób, aby przed dost˛epem do danych wykonane było sprawdzenie, czy odczytywany adres znajduje si˛e w puli pami˛eci wyznaczonej przez mechanizm ´sledzenia.
Je˙zeli adres nale˙zy do puli, to nast˛epuje zaburzenie odczytywanych danych z zadanym prawdopodobie´nstwem (patrz 3.4.5).
Konfiguracje eksperymentów
W ramach przeprowadzonych eksperymentów wykorzystano scenariusz 4.1 (patrz 4.2) oraz scenariusz 4.3. Pozostałe parametry konfiguracji eksperymentów były identyczne z konfiguracj ˛a zastosowan ˛a w eksperymencie opisanym w 4.2 z wyj ˛atkiem zastosowania systemu operacyjnego Debian Squeeze opartego o j ˛adro GNU/Linux w wersji 2.6.32 oraz konfiguracj ˛a momentu wstrzykni˛ecia bł˛edu charakterystyczn ˛a dla zaburzanych danych.
Scenariusz 4.3 imituje wyst ˛apienie bł˛edu w systemie realizuj ˛acym usług˛e serwera HTTP, gdzie po próbie pobrania dokumentu z serwera emulowany administrator loguje si˛e do systemu protokołem SSH20 w celu zbadania logów serwera oraz systemu operacyjnego. W przypadku scenariusza 4.3 wynik uznany jest za prawidłowy, je˙zeli udało si˛e poprawnie pobra´c dokument z serwera HTTP (krok 5). Je˙zeli odpowied´z serwera jest prawidłowa, to test jest przerywany.
W przeciwnym przypadku symulowane jest podj˛ecie akcji diagnostycznej przez administratora
20 Ang. Secure Shell. Popularna usługa realizuj ˛aca zdalny, szyfrowany dost˛ep do konsoli systemu.
1 [QEMU] Uruchomienie SUT.
2 [ SUT] Zalogowanie si˛e do systemu administratora przez konsol˛e dost˛epn ˛a ,→ przez port szeregowy.
3 [ SUT] Wypisanie zawarto´sci pliku /proc/kallsyms na konsol˛e.
4 [QEMU] Wstrzykni˛ecie pojedynczego bł˛edu typu bit-flip w kod systemu ,→ operacyjnego lub konfiguracja warunkowego wstrzykni˛ecia bł˛edu.
5 [ SUT] Nawi ˛azanie poł ˛aczenia TCP/IP przez Nadzorc˛e na port 80 SUT i ,→ wysłanie ˙z ˛adania HTTP z zastosowaniem programu wget.
6 [ SUT] Je˙zeli odpowied´z serwera jest ró˙zna od referencyjnej, to ,→ nawi ˛azanie poł ˛aczenia TCP/IP przez Nadzorc˛e na port 22 SUT i ,→ zalogowanie si˛e protokołem SSH do SUT na konto administratora.
7 [ SUT] W ramach sesji SSH wylistowanie zawarto´sci logów serwera HTTP.
8 [ SUT] W ramach sesji SSH wylistowanie zawarto´sci logów systemu ,→ operacyjnego.
9 [QEMU] Wył ˛aczenie SUT.
Scenariusz QEFI 4.3: Zaburzanie pami˛eci RAM przy realizowaniu usługi serwera HTTP
systemu (linie 7-9). System uznany jest za dost˛epny, je˙zeli udało si˛e nawi ˛aza´c poł ˛aczenie SSH oraz wypisa´c zawarto´s´c plików z logami (linie 8 i 9).
Kod był zaburzany w stałym momencie eksperymentu wykorzystuj ˛ac informacje z profilowania oraz działa´n przygotowawczych (linia 3) pozwalaj ˛acych okre´sli´c miejsce załadowania poszczególnych funkcji systemu operacyjnego. Wstrzykiwanie w stos było wyzwalane warunkowo poprzez wykonanie przez emulowany procesor instrukcji ret21, a bł ˛ad był wstrzykni˛ety z prawdopodobie´nstwem 1:10 000 w zakresie 64 bajtów od warto´sci przechowywanej w rejestrze ESP. W przypadku danych alokowanych informacje o alokacjach były zbierane od momentu zalogowania si˛e administratora systemu, natomiast symulacja bł˛edu sterowana była warunkiem odczytu tej pami˛eci – wstrzykni˛ecie bł˛edu nast˛epowało z prawdopodobie´nstwem 1:1 000. Dla ka˙zdego typu zaburzanych danych zostało przeprowadzone 10 000 iteracji eksperymentu.
Wyniki
Dla obu serii eksperymentów (oznaczonych cyframi rzymskimi: I – scenariusz 4.1;
II – scenariusz 4.3) przygotowane zostało zestawienie warto´sci współczynnika Fs zamanifestowanych bł˛edów (rysunek 4.21), typów zamanifestowanych bł˛edów (rysunek 4.22), dost˛epno´sci systemu dla testów zako´nczonych nieprawidłowym wynikiem (rysunek 4.23) oraz rozkładu typów komunikatów j ˛adra systemu operacyjnego (tabela 4.6). Tak jak w przypadku zaburzania danych systemu operacyjnego z 4.5.2 zostało przygotowane graficzne przedstawienie lokalizacji zaburzanych danych dla scenariusza 4.1 (rysunek 4.24).
Sporz ˛adzone zostały wykresy obrazuj ˛ace dodatkowe cechy przeprowadzonych eksperymentów. Na rysunku 4.25 przedstawiono rozkład procentowy testów z zamanifestowanym bł˛edem w zale˙zno´sci od liczby ile razy wykonana została zaburzona
21 Instrukcja powrotu z wywołania procedury.
Kod I Stos I Dane I Kod II Stos II Dane II
Testy % 020406080
Kod I Stos I Dane I Kod II Stos II Dane II
Testy % 020406080
PU+PS
NU+NS
Rysunek 4.21: Warto´s´c współczynnika Fsdla ró˙znych typów danych
Kod I Stos I Dane I Kod II Stos II Dane II
Testy % 020406080100
PU
PS
NU
NS
Kod I Stos I Dane I Kod II Stos II Dane II
Testy % 020406080100
Rysunek 4.22: Rozkład typów bł˛edów dla ró˙znych typów danych
Kod I Stos I Dane I Kod II Stos II Dane II
Testy % 020406080100
Kod I Stos I Dane I Kod II Stos II Dane II
Testy % 020406080100
DU
DS
NDU
NDS
Rysunek 4.23: Dost˛epno´s´c systemu operacyjnego przy bł˛edach w ró˙znych typach danych
Komunikat % Kod I Stos I Dane I Kod II Stos II Dane II
Bad page state 0,41 0,49 0 0,31 0,17 0
Bad PC value 14,92 23,5 7,27 13,73 16,1 9,41 Null dereference 29,42 23,84 12,57 29,12 22,26 19,91 Null dereference 0 11,56 10,43 4,94 11,18 8,94 3,33 Paging request failed 50,03 52,7 43,26 49,51 57 55,61
Sched while atomic 3,34 0,3 0,09 4,33 3,88 0,07
Double fault 0 0,6 0 0 0 0
EXT FS error 0 0 0 0,68 0,25 0
General protection 17,71 21,99 1,46 24,74 17,37 20,49
I/O error 0 0 0 0,35 0,08 0
Page alocation failure 0,03 0,04 0 0,02 0,08 0 Panic in interrupt 19,37 28,86 4,44 40,45 70,32 93,63
Panic - kill init 8,49 0,04 0 4,55 0 0
Segfault 0,85 1,17 10,11 0,88 0,17 0
Stack protector 0,42 0 0 0,42 0,42 0
Undefined instruction 9,03 7,74 8,55 8,96 7,08 15,93
Unclassified 2,31 6,16 30 3,87 2,95 5,79
Tabela 4.6: Komunikaty o bł˛edach zgłaszane przy zaburzaniu ró˙znych typów danych systemu
Dane alokowane Stos Kod
0 4 8 12 16 20 24 28 32 36 40 44
Pamięć fizyczna MB
Rysunek 4.24: Lokalizacja w pami˛eci fizycznej zaburzanych danych
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Liczba wykonan
Testy % 01020304050
Kod I Kod II
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Liczba wykonań
Testy %
Rysunek 4.25: Liczba wykona´n zaburzonego kodu
instrukcja kodu (tj. instrukcja, która na skutek wstrzykni˛ecia bł˛edu zmieniła swoj ˛a semantyk˛e lub parametry). Przykładowo mo˙zna na nim odczyta´c, ˙ze spo´sród testów, w których bł ˛ad został zamanifestowany, w 45% przypadków zaburzona instrukcja została wykonana tylko jeden raz dla eksperymentu I. Na rysunku 4.26 przedstawiono zale˙zno´s´c pomi˛edzy lokalizacj ˛a wstrzykni˛ecia bł˛edu a miejscem wyst ˛apienia awarii wykrytej przez system operacyjny – miejsce zamanifestowania bł˛edu wyznaczone zostało na podstawie analizy komunikatów systemu operacyjnego zawieraj ˛acych stack-trace awarii (patrz 2.1.2, 3.4.5, 4.2). Wykres opracowano na podstawie odpowiednio 58% i 89% testów eksperymentów zaburzania kodu I i II z zamanifestowanym bł˛edem – dzienniki wykonania tych testów zawierały komunikaty zawieraj ˛ace stack-trace, w którym wyst˛epowała zaburzana funkcja. Na wykresie uwzgl˛edniono równie˙z informacje o liczbie wykona´n zaburzonej instrukcji. Przykładowo mo˙zna z niego odczyta´c, ˙ze w 13% przypadków dla scenariusza 4.1 zaburzony bajt był pierwszym bajtem instrukcji, która spowodowała wygenerowanie raportu o awarii (odległo´s´c 0), z czego w 7%
przypadków zaburzona instrukcja była wykonana tylko raz.
Rysunek 4.27 przedstawia zale˙zno´s´c pomi˛edzy zaburzeniem konkretnego bitu w bajcie, a spowodowaniem zamanifestowania bł˛edu. Na rysunku 4.28 zobrazowana jest relacja mi˛edzy odległo´sci ˛a zaburzonego bajtu od warto´sci rejestru ESP, a spowodowaniem zamanifestowania bł˛edu.
Z analizy artefaktów eksperymentów zaburzenia kodu wynika, ˙ze współczynnik naturalnej odporno´sci na bł˛edy dla eksperymentów zaburzania kodu I i II wynosi odpowiednio I = 31% i I = 42%. Warto´sci te wyznaczaj ˛a współczynnik naturalnej odporno´sci na bł˛edy dla bł˛edu typu bit-flipw kodzie systemu operacyjnego dla zbadanych scenariuszy.
Odlegl
Testy=% 051015
−10 −8 −6 −4 −2 0 2 4 6 8 10
Odlegl
Testy=%Kod I
Odlegl
Testy=% 051015
−10 −8 −6 −4 −2 0 2 4 6 8 10
Odlegl
Testy=%Kod II
Liczba=wykonanń===1 Liczba=wykonanń=>=1
[B]
Rysunek 4.26: Odległo´s´c mi˛edzy zaburzan ˛a instrukcj ˛a, a miejscem manifestacji bł˛edu
1 2 4 8 10 20 40 80
Maska
Testy % 0204060
Kod I Kod II
1 2 4 8 10 20 40 80
Maska
Testy %
Rysunek 4.27: Maska zaburzonego bitu, a manifestacja bł˛edu
[B]
Testy %
Stos I Stos II
−56 −48 −40 −32 −24 −16 −8 0
[B]
Testy % 0255075100
Rysunek 4.28: Wstrzykiwanie bł˛edu w stos, a manifestacja bł˛edu
Wnioski
Zastosowanie technik ´sledzenia wykonania spowodowało znaczny wzrost efektywno´sci eksperymentów testowych – od 5% zamanifestowanych bł˛edów dla statycznego wyznaczenia kodu j ˛adra systemu operacyjnego (patrz 4.5.2) do 70% zamanifestowanych bł˛edów dla zaburzania kodu wyznaczonego metod ˛a profilowania. Dodatkowo dzi˛eki zastosowanym technikom analizowane s ˛a jedynie aktywowane bł˛edy.
Sporz ˛adzone zestawienie lokalizacji zaburzanych danych w pami˛eci fizycznej (rysunek 4.24) pozwala stwierdzi´c, ˙ze dane alokowane, stosy oraz kod ładowanych modułów znajduj ˛a si˛e w losowych miejscach pami˛eci fizycznej. Wyniki te pozwalaj ˛a zinterpretowa´c w pełni wykres podatno´sci na bł ˛ad w przestrzeni adresów fizycznych (rysunek 4.9). Zwi˛ekszona wra˙zliwo´s´c na bł˛edy w niskich adresach przestrzeni fizycznej spowodowana jest faktem, ˙ze alokacja pami˛eci przez j ˛adro systemu cz˛esto wykorzystuje ten region. Podatno´s´c w zakresach 16-18MB pami˛eci fizycznej wynika z zaburzania kodu j ˛adra systemu, a pozostała pami˛e´c losowo zawiera dane wykorzystywane podczas scenariusza testowego.
Przeprowadzone badania wskazuj ˛a na wyra´zne ró˙znice w podatno´sci na bł˛edy poszczególnych typów danych (rysunek 4.21). Zaburzanie kodu powoduje zamanifestowanie bł˛edu w najwi˛ekszej liczbie przypadków (69% i 58% testów). Warto zauwa˙zy´c, ˙ze ponad 90% bł˛edów generuje niepoprawny wynik dla eksperymentu I, a w przypadku eksperymentu II nie zaobserwowano manifestacji bł˛edu przy wygenerowaniu poprawnego wyniku scenariusza.
Brak obserwacji prawidłowych wyników dla eksperymentu II wynika z przyj˛etego scenariusza, gdzie uznanie wyniku za prawidłowy wi ˛a˙ze si˛e jedynie z analiz ˛a odpowiedzi serwera HTTP
działaj ˛acego w SUT. Oznacza to, ˙ze przykładowo współczynnik naturalnej odporno´sci na bł˛edy jest ´sci´sle zwi ˛azany z zadaniami realizowanymi przez system i obserwowanymi wynikami działania systemu. Dodatkowo potwierdza to analiza dost˛epno´sci systemu operacyjnego (rysunek 4.23) – w przypadku eksperymentu II system w wi˛ekszo´sci testów stawał si˛e niedost˛epny.
Warto zwróci´c uwag˛e na podobie´nstwo tabel 4.5/Kod statyczny (strona 103) i 4.6/Kod I oraz rysunków 4.18/Kod statyczny (strona 102) i 4.22 Kod I, które potwierdza zachowanie charakterystyki manifestowania bł˛edu przy uzyskaniu znacznie wi˛ekszej liczby raportów o bł˛edach. Bardzo istotne okazało si˛e wprowadzenie mechanizmu wykrywania, czy zaburzona instrukcja została wykonana. Pozwoliło to uzyska´c współczynnik naturalnej odporno´sci na bł˛edy (patrz 2.5.2), który został wyznaczony na I = 31-42%. Prowadzi to do pytania, jak zmodyfikowane zostało działanie realizowanych przez ten kod algorytmów i czy zaburzenie ma istotny wpływ na działanie systemu operacyjnego równie˙z w przypadku realizacji innych usług systemu operacyjnego. Istotn ˛a obserwacj ˛a jest odkrycie, ˙ze w blisko 45% iteracji eksperymentów zako´nczonych manifestacj ˛a bł˛edu zaburzona instrukcja została wykonana tylko raz. Informacja ta poł ˛aczona z danymi uzyskanymi z rysunku 4.26, gdzie 55%
lokalizacji manifestacji bł˛edu było poło˙zone w bezpo´srednim s ˛asiedztwie (od -1 do 4 bajtów) zaburzanych instrukcji pozwala wnioskowa´c o niewielkim odst˛epie czasu pomi˛edzy wykonaniem nieprawidłowej instrukcji a zamanifestowaniem bł˛edu. Ponadto widoczna na rysunku 4.27 tendencja, ˙ze zaburzanie wy˙zszych bitów bajtu cz˛e´sciej powoduje manifestacj˛e bł˛edu jest zgodna z wynikami prac prowadzonych w Instytucie Informatyki Politechniki Warszawskiej (patrz [41, 42]).
Wstrzykiwanie bł˛edów w dane alokowane powoduje zamanifestowanie bł˛edu na poziomie 38% i 12%, czyni ˛ac ten rodzaj danych drugim pod wzgl˛edem wra˙zliwo´sci na bł˛edy. Warto zaznaczy´c, ˙ze wprowadzenie bł˛edu odbywało si˛e zaraz przed odczytem, czyli w ka˙zdym przypadku zmienione dane przetwarzane były przez system operacyjny.
Dane przechowywane na stosie wykazuj ˛a si˛e współczynnikiem podatno´sci na zaburzenie wysoko´sci około 29% i 12%. Przedstawiona na rysunku 4.28 tendencja do znacznie cz˛estszego manifestowania bł˛edów przy zaburzaniu adresów w odległo´sci 4 bajtów od adresu przechowywanego w rejestrze ESP wynika z wybranego momentu wstrzykni˛ecia – zawsze podczas zaburzania pod tymi adresami znajduje si˛e adres powrotny wywoływania funkcji. Dane odło˙zone wcze´sniej na stosie maj ˛a zbli˙zony współczynnik manifestacji bł˛edu.
Wyniki uzyskane wskutek zaburzania ró˙znych typów danych s ˛a zbie˙zne z wynikami uzyskanymi w eksperymentach przeprowadzonych w [48], gdzie wstrzykiwanie bł˛edu oparte było o ładowany moduł j ˛adra systemu operacyjnego.
4.6. Podsumowanie
W niniejszym rozdziale przedstawione zostały eksperymenty b˛ed ˛ace zastosowaniem metodyki opisanej w rozdziale 3. Podj˛eta została próba opracowania reprezentatywnych scenariuszy testów. Przeprowadzone eksperymenty wykazały praktyczne zastosowanie metodyki umo˙zliwiaj ˛ac uzupełnienie stanu wiedzy o nowe informacje – porównanie wra˙zliwo´sci na bł˛edy architektur sprz˛etowych (4.3), systemów operacyjnych (4.4), poszczególnych typów danych wykorzystywanych przez system operacyjny (4.5.2, 4.5.3) oraz na bł˛edy wyst˛epuj ˛ace w ró˙znych urz ˛adzeniach systemu komputerowego (4.5.1). Przedstawiono szeroki przekrój eksperymentów i mo˙zliwe jest poszerzanie spektrum bada´n o dodatkowe modele bł˛edów i zaburzane urz ˛adzenia. Reasumuj ˛ac, atuty opracowanej metodyki wzgl˛edem rozwi ˛aza´n znanych z literatury to:
— mo˙zliwo´s´c porównania wielu architektur sprz˛etowych bez konieczno´sci opracowywania dodatkowego oprogramowania,
— mo˙zliwo´s´c porównania implementacji wielu systemów operacyjnych bez konieczno´sci opracowywania dodatkowego oprogramowania,
— mo˙zliwo´s´c zbadania wra˙zliwo´sci na bł˛edy obszarów pami˛eci fizycznej,
— badanie niezawodno´sci systemu operacyjnego bez konieczno´sci modyfikacji badanego oprogramowania,
— opracowana technika nieinwazyjnego ´sledzenia wykonania,
— zaburzanie pracy urz ˛adze´n na poziomie komunikacji z systemem operacyjnym.
Dodatkowym atutem metodyki jest mo˙zliwo´s´c przeprowadzania eksperymentów na szerok ˛a skal˛e z zastosowaniem wielu maszyn do przeprowadzania oblicze´n, co jest zalet ˛a w porównaniu do rozwi ˛aza´n wykorzystuj ˛acych rzeczywiste systemy komputerowe. Pozwala to na przeprowadzanie długookresowych testów ukierunkowanych na ró˙zne komponenty systemu operacyjnego.
Dzi˛eki przeprowadzonym eksperymentom mo˙zna stwierdzi´c, ˙ze zarówno wykorzystana architektura ISA, jak i zainstalowany system operacyjny maj ˛a wpływ na poziom manifestacji bł˛edów. Badania ukierunkowane na ró˙zne komponenty systemu operacyjnego maj ˛a szczególne znaczenie, poniewa˙z pozwoliły okre´sli´c, które z komponentów s ˛a najbardziej wra˙zliwe na bł˛edy, co stanowi podstaw˛e rozwa˙za´n opisanych w rozdziale 5.