Zapewnienie spójno´sci kodu wykonywalnego

W niniejszym podrozdziale przedstawiony jest sposób zapewnienia spójno´sci kodu j ˛adra systemu operacyjnego polegaj ˛acy na periodycznym sprawdzeniu załadowanego w pami˛eci

3 https://www.kernel.org/doc/Documentation/bad_memory.txt

RAM obrazu systemu. Metoda ta jest implementacj ˛a idei zapobiegania awariom i uzupełnia ona rozwi ˛azania przedstawione w podrozdziale 5.6, które polegaj ˛a na obsłudze sytuacji awaryjnych.

Zastosowanie rozwi ˛aza´n okresowego sprawdzania spójno´sci jest konieczne w celu przeciwdziałania istnieniu w systemie nieaktywowanych bł˛edów oraz wykrywaniu bł˛edów aktywowanych, które nie spowodowały awarii. Szczególnie istotn ˛a kwesti ˛a jest mo˙zliwo´s´c akumulacji bł˛edów w kodzie, który nie jest wykonywany podczas prawidłowej pracy systemu – np. kod obsługi sytuacji wyj ˛atkowych lub niewykorzystywanych usług. Mo˙zliwy jest scenariusz, gdzie bł˛edy zakumulowane w kodzie obsługi sytuacji wyj ˛atkowej uniemo˙zliwiaj ˛a przeprowadzenie procedury obsługi, co z kolei skutkuje awari ˛a systemu przy wyst ˛apieniu sytuacji wyj ˛atkowej. Prób ˛a przeciwdziałania takiej sytuacji jest wykorzystanie okna czasowego od wyst ˛apienia bł˛edu do wykonania zaburzonego kodu w celu przeprowadzenia procedury usuni˛ecia bł˛edu przed jego aktywowaniem. Sprawdzanie spójno´sci kodu istotne jest równie˙z w przypadku bł˛edów, które zostały aktywowane. Jak wykazano w eksperymentach przeprowadzonych w sekcji 4.5.3 współczynnik tolerancji dla bł˛edów typu bit-flip w kodzie systemu operacyjnego wynosi nawet 31%. Bł˛edy te mogły spowodowa´c ró˙znego typu odst˛epstwa od prawidłowego działania systemu. Stwierdzenie ich obecno´sci jest istotne przy ocenie zaufania do wygenerowanych przez system wyników.

Dodatkow ˛a kwesti ˛a jest zapewnienie poprawno´sci kodu realizuj ˛acego okresowe sprawdzanie spójno´sci kodu j ˛adra systemu operacyjnego, poniewa˙z w przypadku wyst ˛apienia bł˛edu w tym kodzie mo˙ze on nie realizowa´c swojej funkcji lub sygnalizowa´c fałszywe alarmy. Mo˙zliwym scenariuszem jest zastosowanie kilku oddzielnych instancji mechanizmu okresowego sprawdzania spójno´sci kodu uruchamianych naprzemiennie. Dzi˛eki takiemu rozwi ˛azaniu zwi˛ekszane jest prawdopodobie´nstwo wykrycia bł˛edu przed aktywacj ˛a, chocia˙z prawdopodobie´nstwo aktywacji bł˛edu nie jest wyeliminowane.

Implementacja programowego zapewniania spójno´sci kodu jest alternatyw ˛a dla mechanizmów sprz˛etowych – np. pami˛eci ECC (patrz 2.2.4). Niemniej zastosowanie pami˛eci ECC wi ˛a˙ze si˛e z wi˛ekszym kosztem systemu.

Architektura

W celu realizacji okresowego sprawdzania spójno´sci kodu j ˛adra systemu operacyjnego przygotowany został moduł j ˛adra systemu GNU/Linux. Rozwi ˛azanie to zostało wybrane w zwi ˛azku z zało˙zeniem minimalnego kosztu integracji mechanizmów niezawodno´sciowych z istniej ˛ac ˛a implementacj ˛a systemu operacyjnego (opisane w podrozdziale 5.2). Moduł j ˛adra mo˙ze by´c załadowany w dowolnym momencie działania systemu i realizuje on nast˛epuj ˛ace funkcje:

— wykonanie kopii zapasowej statycznego obrazu kodu j ˛adra⁴ w momencie załadowania modułu,

— okresowe porównywanie obrazu kodu i wykonanej kopii zapasowej,

— w przypadku wykrycia bł˛edu kod j ˛adra systemu operacyjnego jest odtwarzany z kopii zapasowej.

Eksperymentalna weryfikacja

Zaproponowana metoda została zweryfikowana eksperymentalnie. Scenariusz polegał na dwukrotnym uruchomieniu instancji QEMU emuluj ˛acej system GNU/Linux. Przy pierwszym uruchomieniu wprowadzono losowy bł ˛ad w procedurze tcp_v4_rcv⁵. Nast˛epnie uruchomiono program wget, który poprzez wywołanie usług sieciowych systemu operacyjnego aktywował wprowadzony bł ˛ad, co z kolei spowodowało awari˛e. Zapis przeprowadzonej interakcji z systemem został umieszczony na listingu 5.1.

1 root@debian-i386:~# wget www.pw.edu.pl

2 --2013-04-11 18:27:59-- http://www.pw.edu.pl/

3 Resolving www.pw.edu.pl... 194.29.151.5

4 Connecting to www.pw.edu.pl|194.29.151.5|:80...

5 [ 87.748803] BUG: unable to handle kernel paging request at e4de8b58

6 [ 87.749016] IP: [<c1206d9f>] tcp_v4_rcv+0x35/0x5a2

7 [ 87.749016] *pde = 00000000

8 [ 87.749016] Thread overran stack, or stack corrupted

9 [ 87.749016] Oops: 0000 [#1] SMP

10 ...

Listing 5.1: Przykład interakcji po wstrzykni˛eciu bł˛edu.

Podczas drugiego uruchomienia wstrzykni˛ecie takiego samego bł˛edu poprzedzono załadowaniem opracowanego modułu. Zapis interakcji z systemem został umieszczony na listingu 5.2. Zastosowanie modułu sprawdzaj ˛acego spójno´s´c kodu spowodowało wykrycie i naprawienie bł˛edu. W liniach 2-3 widoczny jest komunikat zgłaszany przez opracowany moduł o wykryciu bł˛edu oraz odtworzeniu obrazu kodu j ˛adra systemu z kopii zapasowej. Dzi˛eki przeprowadzeniu operacji odtworzenia obrazu kodu mo˙zliwe było pobranie pliku przez sie´c programem wget.

Wnioski

Przedstawiona metoda jest najprostszym mechanizmem zapewniania spójno´sci kodu j ˛adra systemu operacyjnego i została zaproponowana w celu sprawdzenia mo˙zliwo´sci implementacji tego typu mechanizmu w systemie operacyjnym GNU/Linux oraz wyznaczenia dalszych kierunków bada´n. Dzi˛eki okresowemu sprawdzaniu spójno´sci obrazu kodu j ˛adra mo˙zliwe

4 Statyczny obraz kodu j ˛adra systemu operacyjnego nie zawiera w sobie kodu załadowanych modułów.

5 Funkcja tcp_v4_rcv wykorzystywana jest przez system GNU/Linux podczas odbierania pakietów sieci TCP/IP.

1 root@debian-i386:~#

2 [ 95.439364] FixModule - found code image integrity error at c1206d7a.

3 [ 95.439924] FixModule - restoring from backup... success.

4 root@debian-i386:~# wget www.pw.edu.pl

5 --2013-05-11 18:31:48-- http://www.pw.edu.pl/

6 Resolving www.pw.edu.pl... 194.29.151.5

7 Connecting to www.pw.edu.pl|194.29.151.5|:80... connected.

8 HTTP request sent, awaiting response... 200 OK

9 Length: unspecified [text/html]

10 Saving to: "index.html"

11

12 [ <=> ] 35,790 --.-K/s in 0.02s

13

14 2013-05-11 18:31:49 (1.77 MB/s) - "index.html" saved [35790]

Listing 5.2: Przebieg interakcji po wstrzykni˛eciu bł˛edu i sprawdzeniu spójno´sci kodu.

jest zwi˛ekszenie warto´sci współczynnika detekcji bł˛edów, a tak˙ze tolerancji bł˛edów – niestety okre´slenie czy wykryty t ˛a metod ˛a bł ˛ad był aktywowany jest niemo˙zliwe. Zagadnienie to oraz wyznaczenie optymalnej cz˛esto´sci przeprowadzania sprawdzenia spójno´sci wymaga dalszych bada´n.

W przypadku docelowej implementacji, w celu zwi˛ekszenia niezawodno´sci, nale˙załoby rozwa˙zy´c uzupełnienie kopii zapasowej danych kodami korekcji bł˛edów i sumami kontrolnymi, co pozwoliłoby na zapewnienie spójno´sci tak˙ze danych słu˙z ˛acych do naprawy uszkodzonego obrazu j ˛adra. Istotnym rozszerzeniem zaproponowanej metody byłoby równie˙z uwzgl˛ednienie w chronionym obszarze kodu ładownych modułów j ˛adra systemu operacyjnego, a tak˙ze kodu aplikacji u˙zytkownika.