Metoda obsługi przerwa´n procesora dla kodu systemu operacyjnego

Analiza wyników eksperymentów zaburzania kodu, stosu i danych opisanych w sekcji 4.5.3 pozwala stwierdzi´c, ˙ze znaczna cz˛e´s´c wstrzykni˛etych bł˛edów powoduje awarie niedozwolonego dost˛epu do pami˛eci („Paging request failed”). Obserwacja ta jest podstaw ˛a bada´n nad metodami zwi˛ekszania niezawodno´sci przedstawionymi w niniejszym podrozdziale.

W celu opracowania mechanizmu obsługi awarii „Paging request failed” poddano analizie scenariusz jej wyst˛epowania. Składa si˛e on z nast˛epuj ˛acych etapów:

— aktywacja bł˛edu poprzez wykonanie zaburzonych instrukcji,

— odwołanie do niedost˛epnej pami˛eci,

— jednostka MMU zgłasza przerwanie sygnalizuj ˛ace nieprawidłowy dost˛ep do pami˛eci,

— sterowanie przekazane jest do systemu operacyjnego, którego zadaniem jest obsługa przerwania.

System operacyjny sprawdza, czy ˙z ˛adany adres docelowy jest dost˛epny dla zadania b˛ed ˛acego

´zródłem przerwania – sytuacja taka mo˙ze mie´c miejsce w przypadku dost˛epno´sci danych na partycji wymiany pami˛eci wirtualnej. W tym przypadku dane s ˛a pobierane z partycji wymiany do pami˛eci RAM, obsługa przerwania jest zako´nczona, a zadanie jest wznawiane od instrukcji, która spowodowała przerwanie. Je˙zeli dane s ˛a niedost˛epne, zadanie zostaje zako´nczone w trybie awaryjnym – powoduje to zgłoszenie awarii „Paging request failed” dla zada´n wykonywanych w trybie j ˛adra systemu oraz „Segfault” dla zada´n wykonywanych w trybie nieuprzywilejowanym (aplikacje u˙zytkownika).

Dzi˛eki przeprowadzonym badaniom nad liczb ˛a wykona´n zaburzonej instrukcji kodu oraz odległo´sci ˛a mi˛edzy zaburzan ˛a instrukcj ˛a i instrukcj ˛a, której wykonanie wywołuje awari˛e (rysunki 4.25 i 4.26) mo˙zna stwierdzi´c, ˙ze znaczna grupa wstrzykni˛etych bł˛edów powoduje awari˛e ju˙z przy wykonaniu pierwszej zaburzonej instrukcji. Poł ˛aczenie tego faktu z mo˙zliwo´sci ˛a modyfikacji procedury obsługi przerwania zgłoszonego przez MMU jest podstaw ˛a opracowania oryginalnej metody zwi˛ekszania niezawodno´sci. Metoda ta polega na wykonaniu sprawdzenia kodu, który zgłosił przerwanie, pod k ˛atem obecno´sci bł˛edu i ewentualne podj˛ecie procedury naprawczej.

Architektura

Przygotowane rozwi ˛azanie jest modułem naprawczym, który podobnie jak moduł opisany w podrozdziale 5.5 wykonuje kopi˛e statycznego kodu j ˛adra w celu wykorzystania jej do odtwarzania zaburzonego obrazu. Odtwarzanie jest wykonywane w momencie zgłoszenia przerwania, które powodowałoby awari˛e. Podstawowa wersja zaproponowanej metody modyfikuje kod obsługi przerwania zgłoszonego przez MMU tak, aby realizował on algorytm zilustrowany na rysunku 5.1. W domy´slnej konfiguracji j ˛adra nie jest mo˙zliwe modyfikowanie procedur obsługi przerwa´n. W celu przechwycenia sterowania przed zgłoszeniem awarii konieczne było zmodyfikowanie kodu j ˛adra w ten sposób, aby zgłoszenie awarii było uzale˙znione od wywołania pewnej funkcji F zwracaj ˛acej warto´s´c logiczn ˛a. W zale˙zno´sci od warto´sci zwracanej przez funkcj˛e F procedura obsługi przerwania zgłasza awari˛e (dla wyniku TRUE funkcji F ) lub wznawia wykonanie zadania (dla wyniku FALSE). W implementacji umieszczonej w kodzie j ˛adra systemu operacyjnego funkcja F zawsze zwraca warto´s´c TRUE, co oznacza zachowanie niezmienione wzgl˛edem domy´slnej implementacji.

W momencie załadowania opracowanego modułu naprawczego wywołania funkcji F s ˛a przechwytywane przez moduł naprawczy z wykorzystaniem mechanizmu kprobes⁶. Mechanizm kprobes pozwala na przechwycenie wywoła´n okre´slonej funkcji poprzez podmienienie pierwszych instrukcji funkcji na instrukcj˛e skoku do procedur zdefiniowanych przez u˙zytkownika kprobes. W ten sposób mo˙zliwe jest przekazanie sterowania do modułu naprawczego zamiast wykonania funkcji F .

Dodatkowym rozszerzeniem tej metody jest przekazywanie do funkcji F parametrów kontekstu procedury obsługi przerwania – w szczególno´sci wska´znika do struktury danych opisuj ˛acych zadanie, które jest ´zródłem przerwania. Struktura ta zawiera warto´sci rejestrów procesora w momencie zgłoszenia przerwania przez zadanie, flagi uprzywilejowania zadania (zadanie wykonywane w przestrzeni j ˛adra systemu operacyjnego lub przestrzeni u˙zytkownika) oraz informacje o pami˛eci wykorzystywanej przez zadanie. W oryginalnej implementacji funkcji F parametr ten nie jest wykorzystywany, jednak dane te s ˛a konieczne dla prawidłowego działania modułu naprawczego.

Moduł naprawczy działa w nast˛epuj ˛acy sposób: w oparciu o informacje o stanie zadania wykonywane jest sprawdzenie spójno´sci kodu wykonywanej przez zadanie funkcji wzgl˛edem referencyjnego obrazu. W przypadku wykrycia bł˛edu, moduł odtwarza prawidłowy kod funkcji oraz wstrzykuje warto´s´c FALSE jako warto´s´c zwracan ˛a przez przechwycon ˛a funkcj˛e F , co powoduje zablokowanie zgłoszenia awarii i wznowienie działania zadania w miejscu zgłoszenia przerwania. Przepływ sterowania pomi˛edzy ró˙znymi komponentami został przedstawiony na rysunku 5.2.

W przypadku, gdy moduł naprawczy przeprowadzi procedur˛e odtworzenia kodu funkcji, jednak instrukcja powoduj ˛aca zgłoszenie przerwania nie jest zaburzon ˛a instrukcj ˛a, wznowienie działania spowoduje ponowne zgłoszenie przerwania – w tym przypadku moduł nie wykryje zaburzenia kodu i zwróci warto´s´c TRUE powoduj ˛ac zgłoszenie awarii. Natomiast w przypadku, gdy zaburzona instrukcja jest ´zródłem przerwania, przeprowadzenie naprawy umo˙zliwia dalsze wykonanie kodu zadania oraz unikni˛ecie awarii.

Po przeprowadzeniu analiz pozostałych awarii zgłaszanych przez system operacyjny opisanych na stronie 82 zaobserwowano, ˙ze wiele z nich jest równie˙z wyzwalanych nieudan ˛a obsług ˛a przerwania. Wykorzystano ten fakt do przygotowania drugiej wersji modułu, która oprócz modyfikacji przerwa´n zgłoszonych przez MMU modyfikowała tak˙ze procedury obsługi pozostałych przerwa´n.

Konfiguracja eksperymentu

W celu zweryfikowania skuteczno´sci zaproponowanej metody przygotowano eksperyment identyczny z eksperymentem zaburzania kodu opisanym sekcji 4.5.3 dla ka˙zdego z opisanych w

6 http://sourceware.org/systemtap/kprobes/

ProceduraNobsługiN przerwaniaNMMU

CzyNmożnaN obsłużyć przerwanie?

CzyNwykryto błąd?

AwaryjneNzakończenie działaniaNzadania SprawdzenieNspójności

koduNzadania

WznowienieNdziałania zadania DomyśnaNprocedura

obsługiNprzerwania

Nie Tak

Naprawa koduNzadania

Tak

Nie

Rysunek 5.1: Algorytm obsługi przerwania

Zadanie System

operacyjny

Moduł naprawczy

zgłoszenie przerwania

procesora przechwycenie obsługi

z użyciem kprobes

rezultat procedury naprawczej wznowienie lub

zakończenie zadania

Rysunek 5.2: Przepływ sterowania procedury obsługi przerwania

Kod I RM v.1 I RM v.2 I Kod II RM v.1 II RM v.2 II

Testy % 020406080

Kod I RM v.1 I RM v.2 I Kod II RM v.1 II RM v.2 II

Testy % 020406080

PU+PS

NU+NS

Rysunek 5.3: Porównanie manifestacji bł˛edów dla ró˙znych wersji modułu naprawczego

nim scenariuszy. Jedyn ˛a ró˙znic ˛a było załadowanie modułów naprawczych przed wykonaniem scenariusza testowego. Uzyskane wyniki obu wersji modułów zostały porównane z wynikami uzyskanymi w sekcji 4.5.3.

Wyniki

Na rysunkach 5.3, 5.4, 5.5 i w tabeli 5.1 przyj˛eto nast˛epuj ˛ace oznaczenie eksperymentów:

„Kod I/II” s ˛a to powtórzone wyniki eksperymentów opisanych w sekcji 4.5.3, „RM v.1 I/II” s ˛a to eksperymenty wykorzystuj ˛ace moduł naprawczy realizuj ˛acy obsług˛e przerwa´n nieprawidłowego dost˛epu do pami˛eci, natomiast „RM v.2 I/II” s ˛a to eksperymenty wykorzystuj ˛ace moduł naprawczy obsługuj ˛acy wszystkie rodzaje przerwa´n.

Odsetek zamanifestowanych bł˛edów dla przeprowadzonych eksperymentów został przedstawiony na rysunku 5.3. Na rysunku 5.4 zobrazowany jest rozkład poszczególnych typów manifestacji, przy czym wprowadzono nast˛epuj ˛ace oznaczenia nowych typów manifestacji bł˛edów:

— P_R – prawidłowy wynik działania systemu, wykryto komunikat o przeprowadzeniu procedury naprawczej przez moduł,

— NRT – nieprawidłowy wynik działania systemu, wykryto komunikat o wyzwoleniu procedury naprawczej przez moduł, jednak zaburzenie nie zostało wykryte w obr˛ebie funkcji zgłaszaj ˛acej przerwanie,

— N_RD – nieprawidłowy wynik działania systemu, wykryto komunikat o przeprowadzeniu procedury naprawczej przez moduł.

Kod I RM v.1 I RM v.2 I Kod II RM v.1 II RM v.2 II

Testy % 020406080100

P_U PS

PR

NU

NRD

N_RT NS

Kod I RM v.1 I RM v.2 I Kod II RM v.1 II RM v.2 II

Testy % 020406080100

Rysunek 5.4: Rozkład typów bł˛edów dla ró˙znych wersji modułu naprawczego

Kod I RM v.1 I RM v.2 I Kod II RM v.1 II RM v.2 II

Testy % 020406080100

Kod I RM v.1 I RM v.2 I Kod II RM v.1 II RM v.2 II

Testy % 020406080100

DU

D_S NDU

NDS

Rysunek 5.5: Dost˛epno´s´c systemu operacyjnego dla ró˙znych wersji modułu naprawczego

Komunikat % Kod I RM v.1 I RM v.2 I Kod II RM v.1 II RM v.2 II

Bad page state 0,41 0,36 0,25 0,31 0,26 0,13

Bad PC value 14,92 13,52 13,76 13,73 16,98 18,26

Null dereference 29,42 22,68 23,47 29,12 27,28 28,58 Null dereference 0 11,56 9,58 9,56 11,18 10,99 12,26 Paging request failed 50,03 39,53 37,71 49,51 42,05 44,66

Sched while atomic 3,34 2,5 2,04 4,33 3,85 3,88

EXT FS error 0 0,6 0,29 0,68 0,85 0,93

General protection 17,71 14,77 12,02 24,74 24,26 21,18

I/O error 0 0,24 0,27 0,35 0,55 0,75

Page alocation failure 0,03 0,06 0 0,02 0,07 0,05

Panic in interrupt 19,37 16,78 16,58 40,45 41,57 38,82

Panic - kill init 8,49 5,31 5,37 4,55 2,66 3,21

Segfault 0,85 0,68 0,86 0,88 1,4 1,32

Stack protector 0,42 0,32 0,61 0,42 0,57 0,36

Undefined instruction 9,03 9,22 7,95 8,96 11,21 6,72

Recovery Done 0 29,82 37 0 14,72 17,84

Recovery Triggered 0 78 89,68 0 69,14 59,84

Unclassified 2,31 4,23 5,2 3,87 7,76 10,6

Tabela 5.1: Udział komunikatów zgłaszanych przez system operacyjny dla ró˙znych wersji modułu naprawczego

Rysunek 5.5 obrazuje dost˛epno´s´c systemu dla ka˙zdej z przeprowadzonych kampanii. W tabeli 5.1 przedstawiony jest rozkład typów zgłoszonych komunikatów wraz z uwzgl˛ednieniem komunikatów „Recovery Triggered” i „Recovery Done” oznaczaj ˛acych odpowiednio wyzwolenie procedury naprawczej oraz przeprowadzenie odtwarzania w trakcie działania tej procedury.

Wnioski

Dzi˛eki zastosowaniu zaproponowanej metody zwi˛ekszono liczb˛e testów, w których uzyskano prawidłowy wynik powierzonego zadania. Z wykresu 5.3 mo˙zna odczyta´c, ˙ze w przypadku obsługi przerwa´n zgłaszanych przez MMU zwi˛ekszono liczb˛e prawidłowych wyników o około 10 p.p., a dzi˛eki obsłudze pozostałych przerwa´n uzyskano dodatkowe 5 p.p. w przypadku obu badanych scenariuszy eksperymentów. Warto´s´c współczynnika detekcji bł˛edów F_d(patrz 2.5.2) mo˙zna odczyta´c jako suma P_R+ N_RDz wykresu 5.4, co z kolei umo˙zliwia wyznaczenie warto´sci współczynnika naprawy bł˛edów F_r na 46% oraz 55% dla obu modułów naprawczych w scenariuszu I. Dla scenariusza II nie było mo˙zliwe okre´slenie ilo´sci komunikatów PR z uwagi na charakter tego scenariusza (szerzej w 4.5.3). Zaproponowana metoda zwi˛ekszania niezawodno´sci nie gwarantuje przywrócenia prawidłowego stanu systemu operacyjnego, niemniej zmniejszone jest zagro˙zenie wyst ˛apienia awarii uniemo˙zliwiaj ˛acej prac˛e systemu.

Przywrócenie prawidłowej pracy systemu jest pewne wył ˛acznie w przypadku, gdy pierwsze

wykonanie zaburzonego kodu wyzwoli awari˛e. Dodatkowo analiza rysunku 5.5 pozwala stwierdzi´c, ˙ze zastosowanie modułu naprawczego nie wpłyn˛eło znacz ˛aco na charakterystyk˛e dost˛epno´sci systemu w przypadku nieprawidłowej pracy systemu – wynika z tego, ˙ze moduł naprawczy w równym stopniu zapobiegał awariom powoduj ˛acym niedost˛epno´s´c systemu, jak i tym, które nie powodowały takiego efektu.

Warto zwróci´c uwag˛e na fakt, ˙ze około 15% testów z zamanifestowanym bł˛edem spowodowało wykrycie zaburzenia w funkcji, która była wykonywana w trakcie zgłoszenia przerwania (warto´s´c N_RD na rysunku 5.4). Obsługa takiej sytuacji jest rozwa˙zana w 5.6.2.

Pewnym ograniczeniem jest obsługa przez moduł naprawczy tylko statycznego kodu systemu operacyjnego – istnieje mo˙zliwo´s´c potencjalnego zwi˛ekszenia niezawodno´sci poprzez napraw˛e kodu ładowanych modułów systemu operacyjnego. Warto zaznaczy´c, ˙ze procedury obsługi przerwa´n mog ˛a by´c wywołane zarówno przez kod systemu operacyjnego jak i aplikacje u˙zytkownika. Oznacza to, ˙ze je˙zeli system operacyjny dysponowałby referencyjnym obrazem kodu aplikacji u˙zytkownika, to mo˙zliwe byłoby rozszerzenie zastosowania zaproponowanej metody o ten obszar.