4. Badania eksperymentalne
4.2. Profilowanie wra˙zliwo´sci na bł˛edy badanej architektury sprz˛etowej
Podstawowym zagadnieniem zwi ˛azanym z przeprowadzaniem eksperymentów jest okre´slenie liczby testów wystarczaj ˛acej do okre´slenia wiarygodnej charakterystyki wra˙zliwo´sci na bł˛edy systemu. W celu wyznaczenia tej liczby dla eksperymentu wstrzykiwania pojedynczego bł˛edu typu bit-flip w pami˛e´c RAM emulowanego systemu przeprowadzono eksperyment składaj ˛acy si˛e z 500 000 testów. Nast˛epnie zbadano statystyczn ˛a wiarygodno´s´c uzyskanych wyników, okre´slono bł ˛ad w przypadku zmniejszenia liczby testów w eksperymencie oraz wyznaczono liczb˛e testów dla eksperymentów opisanych w 4.3 i 4.4. Cele poboczne przeprowadzonego eksperymentu to zebranie ogólnej charakterystyki zgłaszanych awarii oraz zbadanie wykorzystania pami˛eci przez system.
Konfiguracja eksperymentu
Emulowany system komputerowy jest to system x86 działaj ˛acy pod kontrol ˛a systemu operacyjnego Debian Lenny z j ˛adrem GNU/Linux w wersji 2.6.26. Obraz dysku twardego z zainstalowanym systemem pochodzi z oficjalnych repozytoriów projektu Debian4. SUT ma dost˛ep do zasobów sieciowych poprzez emulowany interfejs Ethernet.
Według zało˙ze´n eksperymentu przekłamana komórka pami˛eci RAM jest wybrana losowo, a moment wstrzykni˛ecia bł˛edu jest stały (patrz 3.4.5) – zało˙zenia takie zostały wprowadzone, poniewa˙z w podstawowej konfiguracji emulator nie ma mo˙zliwo´sci okre´slenia przeznaczenia poszczególnych rejonów pami˛eci, ani nie jest wyposa˙zony w dodatkow ˛a instrumentacj˛e pozwalaj ˛ac ˛a okre´sli´c stan emulowanego systemu operacyjnego. Wprowadzenie mechanizmów zbieraj ˛acych wymienione informacje wymaga dodatkowego nakładu pracy. Prace te zostały wykonane dla architektury x86, a ich wynik opisany jest w sekcjach 4.5.2 oraz 4.5.3).
Niemniej warto zaznaczy´c, ˙ze atutami wynikaj ˛acymi z modyfikacji bezpo´srednio adresów pami˛eci fizycznej jest mo˙zliwo´s´c badania podatno´sci na bł˛edy poszczególnych obszarów przestrzeni pami˛eci RAM oraz jednakowa procedura wstrzykiwania bł˛edów niezale˙znie od tego, czy wybrane komórki pami˛eci zawieraj ˛a kod, czy dane emulowanego systemu (tak jak to ma miejsce w 4.5.3). Wad ˛a takiego rozwi ˛azania s ˛a przypadki zaburzania pami˛eci niewykorzystywanej przez system w momencie wstrzykni˛ecia, co powoduje, ˙ze bł˛edy nie s ˛a aktywowane. W celu ograniczenia tego efektu do minimum, podj˛eta została decyzja o u˙zyciu najmniejszej ilo´sci pami˛eci, która pozwala na uruchomienie emulowanego systemu komputerowego i przeprowadzenie eksperymentu. Wielko´s´c pami˛eci została wyznaczona poprzez seri˛e prób uruchomienia emulowanego systemu komputerowego z
4 http://people.debian.org/˜aurel32/qemu/i386
1 [QEMU] Uruchomienie SUT.
2 [ SUT] Zalogowanie si˛e do systemu administratora przez konsol˛e dost˛epn ˛a ,→ przez port szeregowy.
3 [QEMU] Wstrzykni˛ecie pojedynczego bł˛edu typu bit-flip w losowo wybran ˛a ,→ komórk˛e pami˛eci RAM.
4 [ SUT] Pobranie przez sie´c pliku z lokalizacji sieciowej za pomoc ˛a ,→ programu wget.
5 [ SUT] Wypisanie na konsol˛e operatora zawarto´sci pobranego pliku.
6 [ SUT] Utworzenie katalogu i przeniesienie do niego pobranego pliku.
7 [ SUT] Ponowne wypisanie na konsol˛e operatora zawarto´sci pobranego pliku.
8 [QEMU] Wył ˛aczenie SUT.
Scenariusz QEFI 4.1: Zaburzanie pami˛eci RAM przy obsłudze konsoli operatora, komunikacji sieciowej oraz wykorzystaniu systemu plików
ró˙zn ˛a pojemno´sci ˛a pami˛eci RAM. W pierwszym kroku sprawdzane było 8 MB pami˛eci, a w ka˙zdym nast˛epnym pami˛e´c o 8 MB wi˛eksza od wielko´sci w kroku poprzednim.
Dla architektury x86 wymagana ilo´s´c pami˛eci została ustalona na 32 MB. Niemniej w celu umo˙zliwienia porównywania wyników eksperymentów opisanych w niniejszym rozdziale (eksperymenty AMD64-GNU/Linux, PowerPC-GNU/Linux, MIPS-GNU/Linux, ARM-GNU/Linux, x86-GNU/Linux, x86-FreeBSD, x86-Minix) wprowadzone zostało dodatkowe zało˙zenie, aby wszystkie badane konfiguracje emulowanych systemów były wyposa˙zone w tak ˛a sam ˛a ilo´s´c pami˛eci. Minimalna ilo´s´c pami˛eci, która spełnia te wymagania, została wyznaczona na 48 MB – próba ustawienia mniejszej ilo´sci pami˛eci RAM powodowała,
˙ze system operacyjny skompilowany na architektur˛e AMD64 nie uruchamiał si˛e.
Scenariusz testu5 uruchamianego w ramach eksperymentu składa si˛e z kroków zamieszczonych w scenariuszu 4.1. W powy˙zszym zapisie znacznikami [QEMU] oznaczono komendy ´srodowiska emulacji, natomiast znacznikami [SUT] komendy wysyłane do SUT (patrz 3.4.5, 3.4.6). Zdefiniowany scenariusz oprócz podstawowych usług systemu operacyjnego takich jak zarz ˛adzanie procesami czy pami˛eci ˛a wykorzystuje dodatkowo nast˛epuj ˛ace usługi: obsług˛e konsoli operatora, uruchamianie nowych procesów, stos sieciowy oraz system plików.
Wyniki
Artefaktami przeprowadzenia eksperymentu s ˛a dzienniki wykonania, które zgodnie z metodyk ˛a (patrz 3.4.5) zostały poddane analizie. Badanie cech dzienników wykonano poprzez dopasowywanie wyra˙ze´n regularnych na plikach b˛ed ˛acych zapisem przebiegu ka˙zdego eksperymentu. Okre´slenie, czy zadanie zostało wykonane poprawnie polega na sprawdzeniu, czy dwukrotnie została wypisana na konsol˛e operatora zawarto´s´c pobranego pliku (odpowiedzi SUT w krokach 5 i 7 scenariusza 4.1). Komunikaty j ˛adra systemu operacyjnego s ˛a wykrywane
5 W dalszej cz˛e´sci rozprawy poj˛ecia „scenariusz testu” oraz „scenariusz eksperymentu” stosowane s ˛a zamiennie i odnosz ˛a si˛e do serii kroków interakcji z SUT zgodnie z definicj ˛a zamieszczon ˛a w 3.4.5.
dzi˛eki specjalnemu znacznikowi, który poprzedza wszelkie tego typu wiadomo´sci wypisywane na konsol˛e operatora6. Rozstrzygni˛ecie, czy system operacyjny pozostał dost˛epny polega na sprawdzeniu wyra˙zeniem regularnym, czy po kolejnych komendach wydawanych przez emulowanego administratora pojawiał si˛e znak zach˛ety7.
Czas wykonania pojedynczego testu wynosi od 3 do 4 minut w zale˙zno´sci od wydajno´sci maszyny przeprowadzaj ˛acej eksperyment. Wi˛ekszo´s´c czasu po´swi˛econego na test przypada na rozruch emulowanego systemu komputerowego (krok 1 w scenariuszu 4.1) – około 2 minut.
Pozostały czas jest podzielony na okresy oczekiwania na odpowied´z systemu po wydanej komendzie. Czas wykonania eksperymentu składaj ˛acego si˛e z 500 000 iteracji testów to około 30 dni, przy czym wykorzystywane były maszyny o nast˛epuj ˛acych konfiguracjach: 4 x AMD Opteron 16C 6276 2.33GHz (64 procesory logiczne), 320 GB RAM; 2 x Intel Xeon CPU E5-2630 2.30GHz (24 procesory logiczne), 32 GB RAM.
W przeprowadzonym eksperymencie bł˛edy zamanifestowały si˛e w 0,58% testów (jest to warto´s´c współczynnika Fs). Dokładno´s´c tego współczynnika zale˙zna jest od liczby przeprowadzonych testów i mo˙zliwe jest okre´slenie przedziału ufno´sci. W tym celu mo˙zna przedstawi´c eksperyment jako ci ˛ag prób Bernoulliego z parametrem p. Zgodnie z teori ˛a statystyczn ˛a (na podstawie [66]) przedział ufno´sci dla obserwowanego parametru ˆp i dokładno´sci α wyra˙zony jest wzorem:
Wzór 4.2.1.
[ˆp − zα/2
sp(1 − p)
N ; ˆp + zα/2
sp(1 − p)
N ]
,gdzie
p – parametr rozkładu Bernoulliego, ˆ
p – obserwowana warto´s´c parametru p, α – dokładno´s´c oszacowania ufno´sci,
zα/2– kwantyl rz˛edu1 − α/2 standaryzowanego rozkładu normalnego, N – liczba prób.
Dla α = 0, 05, czyli przedziałowi o ufno´sci 95% warto´s´c zα/2 wynosi 1,96. Pewnym problemem jest zale˙zno´s´c wzoru 4.2.1 od nieznanej warto´sci parametru p. Niemniej mo˙zna zastosowa´c nierówno´s´c, ˙ze dla 0 ≤ p ≤ 1 zachodzi p(1 − p) ≤ 14. Przy podstawieniu wyznaczonych warto´sci przedział ufno´sci wynosi [ˆp − 0, 001386; ˆp + 0, 001386]. Niemniej oszacowanie to jest zawy˙zone w przypadku, gdy warto´s´c parametru p jest z zakresu 0 ≤ p ≤
6 Znacznik ten składa si˛e ma nast˛epuj ˛acy format: „[znacznik czasowy wyst ˛apienia komunikatu]”. Przykład komunikatów opatrzonych takim zancznikiem znajduje si˛e na listingu 4.3 w liniach 2-34.
7 Znak konsoli operatora informuj ˛acy o gotowo´sci przyj˛ecia kolejnej komendy.
●
●
●
●●
●●●●●
●●●●●●
●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●●
Zakres przedzialu 95% ufnosci
Liczba testów
50000 150000 250000 350000 450000
00,00100,0020
Rysunek 4.1: Bł ˛ad wzgl˛edny w zale˙zno´sci od liczby testów w eksperymencie
0, 01, gdy˙z wtedy zachodzi nierówno´s´c p(1 − p) ≤ 0, 0099, co z kolei pozwala wyznaczy´c zakres ufno´sci na [ˆp − 0, 000276; ˆp + 0, 000276].
Z uwagi na długi czas przeprowadzania eksperymentu przygotowana została analiza maj ˛aca na celu okre´slenie z ilu testów mo˙ze składa´c si˛e eksperyment, aby zachowa´c zbli˙zony poziom manifestacji bł˛edów jednocze´snie minimalizuj ˛ac czas potrzebny do przeprowadzenia testów.
Na rysunku 4.1 przedstawiony jest wykres rozpi˛eto´sci zakresu przedziału ufno´sci w przy zało˙zeniu ˆp = 0, 0058 (warto´s´c ta została wybrana jako najdokładniejszy dost˛epny pomiar współczynnika manifestacji bł˛edów) dla ró˙znej liczby testów (N ) według wzoru 4.2.1. Na podstawie wykresu wybrana została liczba 50 000 testów w eksperymencie z uwagi na akceptowalny czas przeprowadzenia takiego eksperymentu (około 3 dni) oraz zakres przedziału ufno´sci 95% na poziomie ˆp ± 0, 00066 (0,066 p.p.).
W dalszej cz˛e´sci niniejszego podrozdziału wyniki przeprowadzonego eksperymentu 500 000 testów zostały przedstawione jako 10 iteracji eksperymentu składaj ˛acego si˛e 50 000 testów w celu zobrazowania ró˙znic pomi˛edzy kolejnymi próbkami. Dodatkowo liczba 50 000 testów w eksperymencie została przyj˛eta w testach opisanych w podrozdziałach 4.3 oraz 4.4, co umo˙zliwia porównywanie uzyskanych wyników.
Wyniki przedstawiaj ˛ace odsetek wstrzykni˛etych bł˛edów, które zostały zamanifestowane (współczynnik Fs) w poszczególnych iteracjach eksperymentu, zostały zamieszczone na rysunku 4.2. Kolorem zielonym zaznaczono odsetek testów, w których wynik zadania realizowanego w scenariuszu był prawidłowy, natomiast kolorem czerwonym odsetek testów zako´nczonych nieprawidłowym wynikiem zadania – według kategorii manifestacji bł˛edu
1 2 3 4 5 6 7 8 9 10 Testy % 0.00.20.40.60.8
1 2 3 4 5 6 7 8 9 10
Testy % 0.00.20.40.60.8
PU+PS
NU+NS
Rysunek 4.2: Warto´s´c współczynnika Fs dla ró˙znych iteracji eksperymentu badanej architektury sprz˛etowej
opisanej w 2.5.2 warto´sci te s ˛a wyra˙zone jako Ps + Pu i Ns + Nu. Procentowy udział poszczególnych kategorii manifestacji bł˛edu został przedstawiony na rysunku 4.3.
Przykłady typów manifestacji zostały przedstawione w dalszej cz˛e´sci niniejszego podrozdziału.
Dost˛epno´s´c systemu przy nieprawidłowym wyniku ko´ncowym (dla kategorii manifestacji Nu
i Ns) została przedstawiona na rysunku 4.4 z zastosowaniem kategorii dost˛epno´sci systemu opisanych w 2.5.2.
W przypadku testów, w których pojawiły si˛e komunikaty j ˛adra systemu operacyjnego, przeprowadzono analiz˛e typów bł˛edów zgodnie z metodyk ˛a opisan ˛a w 3.4.5. Zestawienie procentowych udziałów ró˙znych typów bł˛edów przedstawiono w tabeli 4.1.
Rysunek 4.5 przedstawia współczynnik manifestacji bł˛edów w pami˛eci fizycznej dla obszarów pami˛eci wielko´sci 1 MB. Współczynnik ten wyra˙zony jest jako procent testów, podczas których zamanifestowany został bł ˛ad, w stosunku do wszystkich testów wstrzykni˛ecia bł˛edu w dany obszar pami˛eci. Przykładowo dla iteracji 1 mo˙zna odczyta´c, ˙ze w przedziale adresów fizycznych od 0 do 1048576 (1 MB) 7% wstrzykni˛etych bł˛edów spowodowało zamanifestowanie bł˛edu.
tbhp
Przykłady manifestacji bł˛edów
Poni˙zej przedstawione s ˛a zaobserwowane w dziennikach wykonania ró˙zne typy manifestacji bł˛edów: Pu, Nu, Ns. Typ Pszostał pomini˛ety, poniewa˙z ró˙zni si˛e on od Nsjedynie uzyskaniem prawidłowego wyniku, pomimo pojawienia si˛e komunikatów systemu operacyjnego.
1 2 3 4 5 6 7 8 9 10
Testy % 020406080100
PU
PS
NU
NS
1 2 3 4 5 6 7 8 9 10
Testy % 020406080100
Rysunek 4.3: Rozkład typów zamanifestowanych bł˛edów w ró˙znych iteracjach eksperymentu badanej architektury sprz˛etowej
1 2 3 4 5 6 7 8 9 10
Testy % 020406080100
1 2 3 4 5 6 7 8 9 10
Testy % 020406080100
DU
DS
NDU
NDS
Rysunek 4.4: Dost˛epno´s´c systemu operacyjnego w ró˙znych iteracjach eksperymentu badanej architektury sprz˛etowej
Testy %
Rysunek 4.5: Współczynnik Fs / MB pami˛eci fizycznej dla ró˙znych iteracji eksperymentu badanej architektury sprz˛etowej
Komunikat [%] 1 2 3 4 5 6 7 8 9 10 Paging request failed 27,12 24,86 23,84 29,54 26,21 25,1 23,13 23,91 27,02 28,3
Segfault 21,02 23,74 24,15 21 20,71 25,1 19,93 26,71 17,19 22,64 Null dreference 10,85 14,53 12,07 11,39 13,27 14,12 12,81 13,04 12,28 13,21 Null dereference 0 6,44 4,47 4,33 3,56 4,53 7,45 4,63 4,97 7,02 5,35
Panic in interrupt 8,81 8,1 8,36 12,46 13,92 7,06 7,12 9,94 9,82 8,81 General protection 7,46 9,78 9,6 9,25 10,36 10,59 8,19 6,83 9,82 8,49 Bad PC value 3,73 5,03 8,05 3,2 7,77 3,53 7,83 6,52 7,37 5,35 Panic - kill init 3,39 3,35 3,1 4,27 2,91 1,96 4,27 5,28 3,51 3,77 Undefined instruction 2,03 3,63 6,5 6,76 8,41 4,31 6,76 7,14 7,37 5,03 Double fault 1,36 1,12 1,24 0,71 0,65 0,39 1,42 0,93 3,86 2,2 Bad page state 0,68 1,96 1,86 1,42 0,97 2,75 1,07 1,86 3,16 2,83 Tabela 4.1: Udział komunikatów zgłaszanych przez system operacyjny w ró˙znych iteracjach eksperymentu
1 debian-i386:~# wget --progress=dot 194.29.167.156:2000
2 --%s-- 2013-02-24 07:48:40
3 Connecting to 194.29.167.156:2000... connected.
4 HTTP request sent, awaiting response... 200 OK
Listing 4.1: Przykład Pu
Na listingu 4.1 przedstawiono zaobserwowan ˛a manifestacj˛e bł˛edu polegaj ˛ac ˛a na zmianie komunikatów prezentowanych u˙zytkownikowi, co nie miało wpływu na wykonanie przez SUT powierzonego zadania (Pu). Nieprawidłowo´sci znajduj ˛a si˛e w linii 2, gdzie wyst˛epuje znacznik %s oraz data. W eksperymentach, w których bł ˛ad si˛e nie manifestuje linia wypisywana na tym etapie wykonania scenariusza ma posta´c: „-2013-03-26 03:46:12-http://194.29.167.156:2000/”, czyli wyst ˛apiły dwie zmiany:
— w miejscu wypisywania daty pojawił si˛e znacznik %s,
— w miejscu wypisywania docelowego adresu URL wypisana została data.
Obrazuje to jak bł˛edy wyst˛epuj ˛ace w systemie mog ˛a mie´c pozornie nieszkodliwe efekty. W tym przypadku wynik powierzonego zadania nie zale˙zał od przekłamanej linii, jednak łatwo wyobrazi´c sobie przypadek, gdy zmiana formatu wypisywanych danych mo˙ze mie´c negatywny wpływ na inne programy korzystaj ˛ace z tych danych.
1 debian-i386:~# rm tmp/index.html
2 rm: relocation error: rm: symbol sc0<vdcR+G9E0_e, version GLIBC_2.0 not ,→ defined in file libc.so.6 with link time reference
Listing 4.2: Przykład Nu
Listing 4.2 przedstawia manifestacj˛e typu Nu, która powoduje niewykryt ˛a przez system sytuacj˛e awaryjn ˛a. Wprowadzone zaburzenie spowodowało, ˙ze nie jest mo˙zliwe uruchomienie
˙zadnego programu wykorzystuj ˛acego standardow ˛a bibliotek˛e j˛ezyka C (libc), poniewa˙z uszkodzenie zaburzyło proces ładowania tej biblioteki współdzielonej (patrz 2.1.2). Awaria tego typu powoduje brak mo˙zliwo´sci uruchomienia jakiegokolwiek nowego procesu w systemie.
Listing 4.3 przedstawia manifestacj˛e typu Ns, w której j ˛adro systemu operacyjnego zgłosiło sytuacj˛e awaryjn ˛a. Jest to typowy dla systemu GNU/Linux komunikat, w którym zawarte s ˛a mi˛edzy innymi nast˛epuj ˛ace informacje:
— opis typu awarii (linia 2),
— identyfikator procesora, który wykonywał zadanie ulegaj ˛ace awarii (linia 5),
— lista modułów załadowanych do j ˛adra systemu operacyjnego (linia 6),
— identyfikator procesu ulegaj ˛acego awarii i informacja o wersji j ˛adra systemu operacyjnego (linia 8),
— zawarto´sci rejestrów procesora (linie 9-13),
— informacje o procesie/w ˛atku systemu, na rzecz którego wykonywany był kod wywołuj ˛acy awari˛e (linia 14),
— zawarto´s´c stosu (linie 15-17),
— stos wywoła´n funkcji stack-trace (linie 19-30),
— zrzut pami˛eci zawieraj ˛acej instrukcje wykonywane przez procesor (linia 32).
Opis zgłaszanych komunikatów
Komunikaty najcz˛e´sciej zgłaszane przez system operacyjny wymienione w tabeli 4.1 maj ˛a nast˛epuj ˛ace znaczenie:
Paging request failed Próba odwołania si˛e przez kod wykonywany w przestrzeni j ˛adra systemu operacyjnego do pami˛eci, która nie została wcze´sniej zaalokowana (patrz 2.1.2).
Segfault Jest to komunikat analogiczny do Paging request failed, z t ˛a ró˙znic ˛a, ˙ze program wykonuj ˛acy nieprawidłowe odwołanie uruchomiony był w przestrzeni u˙zytkownika (patrz 2.1.2).
Null dereference Próba dereferencji wska´znika maj ˛acego warto´s´c 0.
Null dereference 0 Komunikat ten jest analogiczny do komunikatu Null dereference, gdzie sam wska´znik równie˙z jest przechowywany pod adresem 0.
Panic in interrupt Wyst ˛apienie bł˛edu w trakcie wykonywania procedury obsługi przerwa´n (patrz 2.1.2).
General protection Komunikat ten zgłaszany jest przy wszelkich naruszeniach zasad ochrony zdefiniowanych w procesorze. Oprócz nieprawidłowego dost˛epu do pami˛eci (np. pisanie do pami˛eci read-only, próba wykonania kodu ze strony nie maj ˛acej uprawnie´n wykonania) jest to tak˙ze próba wykonania instrukcji uprzywilejowanych.
Bad PC value Rejestr wska´znika instrukcji ma niedozwolon ˛a warto´s´c (wykaz niedozwolonych warto´sci mo˙zna znale´z´c w [56]).
1 debian-i386:~# wget --progress=dot 194.29.167.156:2000
2 [1471925.388302] BUG: unable to handle kernel NULL pointer dereference at ,→ 00000282
3 [1471925.394970] IP: [<c227b080>]
4 [1471925.397151] *pde = 00000000
5 [1471925.399116] Oops: 0000 [#1] SMP
6 [1471925.400822] Modules linked in: loop button serio_raw parport_pc ,→ parport snd_pcsp psmouse snd_pcm snd_timer i2c_piix4 snd soundcore ,→ i2c_core snd_page_alloc evdev ext3 jbd mbcache ata_generic
,→ ide_cd_mod cdrom ide_disk libata scsi_mod dock ide_pci_generic piix ,→ ide_core e1000 floppy thermal processor fan thermal_sys
7 [1471925.400822]
8 [1471925.400822] Pid: 2028, comm: bash Not tainted (2.6.26-2-686 #1)
9 [1471925.400822] EIP: 0060:[<c227b080>] EFLAGS: 00000282 CPU: 0
10 [1471925.400822] EIP is at 0xc227b080
11 [1471925.400822] EAX: 00000282 EBX: c0117357 ECX: 0000000a EDX: 00000002
12 [1471925.400822] ESI: c1046a40 EDI: b7000000 EBP: c1065580 ESP: c21e3e1c
13 [1471925.400822] DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
14 [1471925.400822] Process bash (pid: 2028, ti=c21e2000 task=c24584a0 ,→ task.ti=c21e2000)
15 [1471925.400822] Stack: 08000000 c0163c45 00046a40 c1000000 00000000 ,→ 08356000 c21e3ea4 08356000
16 [1471925.400822] 00000000 00000001 bfae4000 c227bbf8 c2dc6b74 ,→ c2dc6b5c 08355fff c18416fc
17 [1471925.400822] c18416fc c18416fc 08048000 c0164bc3 00000000 ,→ b73e3000 00000000 c21e3ea4
33 [1471925.400822] EIP: [<c227b080>] 0xc227b080 SS:ESP 0068:c21e3e1c
34 [1471925.472978] ---[ end trace 1cb41acd1be81ded
]---Listing 4.3: Przykład Ns
Panic - kill init Bł˛edy, które wyst ˛apiły spowodowały zako´nczenie procesu init – tj. przodka wszystkich procesów uruchomionych w systemie operacyjnym (patrz 2.1.2).
Undefined instruction Próba wykonania instrukcji, która nie jest prawidłow ˛a instrukcj ˛a zdefiniowan ˛a w ISA.
Double fault Wyst ˛apienie bł˛edu podwójnego, czyli zgłoszenie bł˛edu przez procesor w trakcie wykonania procedury obsługi innego bł˛edu.
Bad page state Wykryto bł ˛ad w strukturach danych odpowiedzialnych za zarz ˛adzanie stronami pami˛eci wirtualnej (patrz 2.1.2).
Wnioski
Z analizy rysunku 4.3 wynika, ˙ze około 10-15% testów z zamanifestowanymi bł˛edami zako´nczyło si˛e uzyskaniem poprawnego wyniku (Ps + Pu), a system operacyjny wykrywa obecno´s´c bł˛edu w około 75% przypadków (Ps+ Ns). Warto równie˙z zauwa˙zy´c, ˙ze spo´sród testów zako´nczonych nieprawidłowym wynikiem (dost˛epno´s´c systemu przy nieprawidłowym wyniku przedstawiona jest na rysunku 4.4) ponad 60% cechuje brak dost˛epno´sci systemu (N DU + N DS), co uniemo˙zliwia dalsz ˛a interakcj˛e z systemem w celach diagnostycznych.
Dodatkowo analiza tabeli 4.1 pozwala stwierdzi´c, ˙ze najcz˛e´sciej zgłaszane komunikaty przez system s ˛a zwi ˛azane z bł˛edami pami˛eci (komunikaty Segfault, Paging request failed, Null dereferenceoraz Null dereference 0).
Analiza zakresów adresów fizycznych, które powoduj ˛a manifestacj˛e bł˛edów (rysunek 4.5), wskazuje wyra´znie, ˙ze niektóre obszary s ˛a kilkakrotnie bardziej podatne na wyst ˛apienie bł˛edu.
Oznacza to, ˙ze ró˙zne rodzaje danych składowanych w pami˛eci (kod, stos, przetwarzane dane) maj ˛a inny stopie´n podatno´sci na bł˛edy. Jest to cenna obserwacja, poniewa˙z uzupełniona o informacj˛e jakiego typu dane były składowane w tych obszarach pami˛eci stanowi wskazówk˛e dla projektantów systemów komputerowych o podwy˙zszonej odporno´sci na bł˛edy. Dzi˛eki tej wiedzy, mo˙zna obni˙zy´c koszty produkcji systemu umieszczaj ˛ac tylko dane pewnego rodzaju w dro˙zszej pami˛eci RAM wyposa˙zonej w system ECC. Niemniej zastosowanie takiego rozwi ˛azania wymaga wsparcia systemu operacyjnego.
Długi czas pojedynczego eksperymentu jest wad ˛a obecnej implementacji. Niemniej mo˙zliwe jest w przyszło´sci przy´spieszenie testu poprzez wykorzystanie opcji migawki stanu emulatora. Rozwi ˛azanie takie polega na przygotowaniu migawki systemu przed wstrzykni˛eciem bł˛edu i uruchamianie kolejnych instancji eksperymentu z wykorzystaniem tych danych – pozwoliłoby to na wyeliminowanie z eksperymentu czasu potrzebnego na rozruch emulowanego systemu operacyjnego, czyli czas potrzebny na przeprowadzenie pojedynczego testu potencjalnie mo˙ze by´c zredukowany z 4 do 2 minut.
Wybrana metoda wstrzykiwania bł˛edów bezpo´srednio w pami˛e´c fizyczn ˛a cechuje si˛e niskim poziomem manifestacji bł˛edów. Dodatkowym problemem wynikaj ˛acym ze sposobu implementacji QEMU s ˛a trudno´sci w sprawdzeniu, czy dane spod zaburzonego adresu
fizycznego zostały aktywowane, co pozwoliłoby na wyznaczenie współczynnika naturalnej odporno´sci I zgodnie z definicj ˛a przedstawion ˛a w sekcji 2.5.2. Rozwi ˛azanie tych problemów wi ˛a˙ze si˛e z wykonaniem dodatkowych prac specyficznych dla konkretnej architektury emulowanego systemu – prace te zostały wykonane i ich wyniki opisano w sekcji 4.5.3.