Politechnika Warszawska
Warsaw University of Technology http://repo.pw.edu.pl
Rodzaj dyplomu / Diploma type Rozprawa doktorska / PhD thesis
Autor / Author Chyłek Sławomir Grzegorz
Tytuł / Title
Zastosowanie symulacji błędów do oceny i optymalizacji niezawodności systemów operacyjnych / Adaptation of fault injection technique in assessment and reliability optimization of operating systems Rok powstania / Year of creation
Promotor / Supervisor Sosnowski Janusz
Jednostka dyplomująca / Certifying unit Wydział Elektroniki i Technik Informacyjnych / Faculty of Electronics and Information Technology
Adres publikacji w Repozytorium URL /
Publication address in Repository http://repo.pw.edu.pl/info/phd/WUT40e02bf030294a859cdd614d80d4f731/
Data opublikowania w Repozytorium / Deposited
in Repository on 2014-06-27
POLITECHNIKA WARSZAWSKA
Wydział Elektroniki i Technik Informacyjnych
ROZPRAWA DOKTORSKA
mgr in˙z. Sławomir Chyłek
Zastosowanie symulacji bł˛edów do oceny i optymalizacji niezawodno´sci systemów operacyjnych
Promotor prof. dr hab. in˙z. Janusz Sosnowski
Warszawa 2014
Podzi˛ekowania
Dzi˛ekuj˛e profesorowi Januszowi Sosnowskiemu za opiek˛e przez cały okres studiów doktoranckich oraz nieocenion ˛a pomoc podczas tworzenia niniejszej rozprawy.
Dzi˛ekuj˛e ˙Zonie Emilii, za wspieranie mnie oraz wyrzeczenia, które umo˙zliwiły mi napisanie niniejszej pracy.
Dzi˛ekuj˛e Kole˙zankom i Kolegom z Wydziału za wsparcie i pomoc podczas pracy nad doktoratem.
Streszczenie
Symulacja bł˛edów jest jedn ˛a z głównych technik ewaluacji niezawodno´sci oprogramowania.
Niniejsza rozprawa po´swi˛econa jest adaptacji symulacji bł˛edów w emulatorach systemów komputerowych, co umo˙zliwiło badanie niezawodno´sci oprogramowania systemów operacyjnych oraz tworzenie nowych mechanizmów wykrywania i obsługi bł˛edów.
W rozprawie zaprezentowana została metodyka testowania oprogramowania z zastosowaniem emulatora systemu komputerowego. Przedstawione zostały cechy emulacji szczególnie u˙zyteczne przy badaniu niezawodno´sci oraz opisano oryginalne rozszerzenia procesu emulacji o funkcje symulacji bł˛edów i nieinwazyjnego ´sledzenia wykonania.
Omówiony został aspekt masowego wykonania eksperymentów oraz analizowania dzienników wykonania b˛ed ˛acych ich artefaktami. Implementacja opisanej metodyki posłu˙zyła do opracowania oryginalnych metod przeprowadzania eksperymentów porównuj ˛acych ró˙zne architektury procesorów, systemy operacyjne, a tak˙ze pozwoliła przeprowadzi´c badania ukierunkowane na ewaluacj˛e wra˙zliwo´sci systemu operacyjnego na bł˛edy wyst˛epuj ˛ace w urz ˛adzeniach systemu komputerowego oraz poszczególnych typach danych systemu operacyjnego: kod, stos, dane alokowane, dane statyczne oraz dane tylko do odczytu. W rozprawie opisano przeprowadzone eksperymenty wraz z wynikami i płyn ˛acymi z nich wnioskami.
Przeprowadzone badania pozwoliły na okre´slenie krytycznych komponentów systemu operacyjnego. Uwzgl˛edniaj ˛ac ograniczenia oprogramowania wykonywanego w przestrzeni j ˛adra, zaproponowano oryginalny algorytm obsługi przerwa´n umo˙zliwiaj ˛acy detekcj˛e i obsług˛e lokalnych bł˛edów, a jego skuteczno´s´c została zweryfikowana opracowan ˛a metodyk ˛a testowania.
Zdefiniowano problem odtwarzalno´sci wraz z algorytmem brudnych zasobów stanowi ˛acym jedno z jego rozwi ˛aza´n. Dodatkowo zaprezentowano mechanizm ochrony wska´zników powrotu z funkcji przechowywanych na stosie.
Słowa kluczowe: wstrzykiwanie bł˛edów, emulacja, niezawodno´s´c oprogramowania, testowanie oprogramowania, systemy operacyjne, problem odtwarzalno´sci, detekcja bł˛edów, wra˙zliwo´s´c na bł˛edy, lokalizacja bł˛edów, tolerowanie bł˛edów.
Abstract
Adaptation of fault injection technique in assessment and reliability optimization of operating systems
Fault injection is one of the most commonly used techniques for software reliability evaluation. This thesis is focused on the subject of integration of fault injection technique into computer system emulation software. The approach enabled research on reliability of operating system’s software and development of novel fault detection and error handling mechanisms.
The thesis proposes methodology for testing software with utilization of computer software emulation. Emulation features especially advantageous in reliability evaluation are presented in detail followed by description of original extensions to emulation process: fault injection and nonintrusive execution tracing. The aspects of parallel experiment execution and analysis of experiments’ execution logs was discussed. Implementation of the proposed methodology was utilized to develop original experimental methods for processors’ architectures and operating systems comparison. Dedicated research was focused on evaluation of operating system’s susceptibility to faults in case of faults occurring in computer system’s devices or different types of operating system’s data: code, stack space, dynamically allocated data, static data and read-only data. The thesis includes descriptions of conducted experiments followed by results and conclusions.
Performed research enabled identification of most critical components of operating system.
While taking into account limitations of code executed in kernel mode a novel algorithm for detecting and handling faults in interrupt procedures was proposed. Its effectiveness was verified with presented testing methodology. The recovery problem was defined along with the dirty resources algorithm as one of its solution. In addition, a method for protecting functions’
return address stored on stack was proposed.
Keywords: fault injection, emulation, software reliability, software testing, operating systems, recovery problem, software fault detection, fault sensitivity, software debugging, error tolerance.
Spis tre´sci
1. Wprowadzenie . . . 11
1.1. Motywacja do powstania pracy . . . 11
1.2. Kierunek bada´n . . . 14
1.3. Teza i cel rozprawy . . . 14
1.4. Układ pracy . . . 15
2. Analiza wpływu bł˛edów na działanie systemu komputerowego . . . 17
2.1. Model systemu komputerowego . . . 17
2.1.1. Model zasobów sprz˛etowych . . . 18
2.1.2. Model oprogramowania . . . 20
2.2. Modele bł˛edów . . . 26
2.2.1. Zródła bł˛edów . . . .´ 26
2.2.2. Charakterystyka modeli bł˛edów . . . 27
2.2.3. Bł˛edy jednostek przetwarzaj ˛acych . . . 28
2.2.4. Bł˛edy pami˛eci operacyjnej . . . 29
2.2.5. Bł˛edy urz ˛adze´n zewn˛etrznych . . . 30
2.3. Mechanizmy zwi˛ekszania niezawodno´sci . . . 31
2.4. Symulacja bł˛edów w badaniu niezawodno´sci systemów komputerowych . . . 33
2.5. Analiza efektów bł˛edów . . . 36
2.5.1. Scenariusz wyst ˛apienia bł˛edu . . . 37
2.5.2. Symulowanie bł˛edów . . . 38
2.6. Podsumowanie . . . 40
3. Metodyka symulacji bł˛edów w emulowanym ´srodowisku . . . 43
3.1. Motywacja . . . 43
3.2. Emulacja systemów komputerowych . . . 44
3.3. Zastosowanie emulacji . . . 49
3.4. ´Srodowisko zautomatyzowanych testów . . . 51
3.4.1. Wybór emulatora systemu komputerowego . . . 52
3.4.2. Dokładno´s´c emulacji . . . 53
3.4.3. Nieinwazyjne ´sledzenie wykonania . . . 54
3.4.4. Wydajno´s´c emulacji . . . 54
3.4.5. Metodyka bada´n . . . 55
3.4.6. Architektura QEFI . . . 62
3.4.7. Charakterystyka bł˛edów symulowanych w QEFI . . . 67
3.4.8. Zastosowanie metodyki . . . 68
3.5. Podsumowanie . . . 69
4. Badania eksperymentalne . . . 71
4.1. Plan przeprowadzonych eksperymentów . . . 71
4.2. Profilowanie wra˙zliwo´sci na bł˛edy badanej architektury sprz˛etowej . . . 74
4.3. Porównanie wra˙zliwo´sci na bł˛edy ró˙znych architektur sprz˛etowych . . . 85
4.4. Porównanie wra˙zliwo´sci ró˙znych systemów operacyjnych . . . 90
4.5. Eksperymenty ukierunkowane na j ˛adro systemu operacyjnego . . . 95
4.5.1. Bł˛edy urz ˛adze´n wej´scia/wyj´scia . . . 96
4.5.2. Zaburzanie kodu, danych statycznych i danych tylko do odczytu systemu operacyjnego . . . 100
4.5.3. Zastosowanie profilowania do zaburzania kodu, stosu oraz danych alokowanych systemu operacyjnego . . . 104
4.6. Podsumowanie . . . 115
5. Mechanizmy wykrywania i obsługi bł˛edów . . . 117
5.1. Mechanizmy zwi˛ekszaj ˛ace niezawodno´s´c w systemie operacyjnym . . . 117
5.2. Ogólne zało˙zenia . . . 119
5.3. Identyfikacja krytycznych komponentów . . . 120
5.4. Zało˙zenia dotycz ˛ace projektowanych mechanizmów zwi˛ekszania niezawodno´sci . . . . 121
5.5. Zapewnienie spójno´sci kodu wykonywalnego . . . 122
5.6. Procedury naprawcze . . . 125
5.6.1. Metoda obsługi przerwa´n procesora dla kodu systemu operacyjnego . . . 125
5.6.2. Algorytm brudnych zasobów . . . 132
5.6.3. Ochrona stosu . . . 139
5.6.4. Mechanizmy ochrony danych . . . 141
5.7. Zastosowanie QEFI do optymalizacji niezawodno´sci . . . 143
5.8. Podsumowanie . . . 144
6. Podsumowanie . . . 147
6.1. Spostrze˙zenia i wnioski . . . 149
6.2. Zastosowania . . . 150
6.3. Kierunki dalszych bada´n . . . 151
Bibliografia . . . 153
A. Dodatek – specyfikacja opracowanego oprogramowania . . . 161
A.1. QEFI . . . 161
A.1.1. QEMU . . . 161
A.1.2. Nadzorca . . . 163
A.1.3. Ekstraktor . . . 165
A.1.4. Eksperyment . . . 165
A.1.5. Analizator . . . 165
A.2. Zmiany w j ˛adrze systemu GNU/Linux . . . 166
1. Wprowadzenie
Wraz z upowszechnieniem si˛e komputerów ro´snie znaczenie niezawodnego funkcjonowania urz ˛adze´n cyfrowych. Oczekiwania te zwi ˛azane s ˛a z coraz wy˙zszymi wymaganiami u˙zytkowników w stosunku do dost˛epno´sci i jako´sci usług, a tak˙ze z krytyczn ˛a natur ˛a zada´n powierzonych systemom komputerowym – np. sterowanie układami pojazdów, czy urz ˛adze´n medycznych. O wadze tego problemu ´swiadczy wiele faktów jak awaria chmury obliczeniowej Amazon EC2 w 2012 roku1 powoduj ˛aca straty finansowe wielu portali internetowych, czy opracowany w 2013 roku raport Ameryka´nskiej Agencji ds. ˙Zywno´sci i Leków (FDA), ujawniaj ˛acy w Stanach Zjednoczonych w latach 2006-2011 wzrost liczby incydentów zagra˙zaj ˛acych bezpiecze´nstwu pacjentów w zwi ˛azku z usterkami medycznego sprz˛etu komputerowego z 153 do 319 (patrz [6]).
Awarie te wyst ˛apiły pomimo nakładów pracy po´swi˛econych na zwi˛ekszanie niezawodno´sci tych produktów, natomiast wiele awarii komputerów pozostaje nieodnotowanych lub raporty s ˛a niewystarczaj ˛ace do prawidłowego okre´slenia przyczyny problemu (patrz [113]). Dotyczy to w szczególno´sci awarii konsumenckich stacji roboczych, telefonów komórkowych, czy terminali POS2. Ostatnie badania (patrz [84, 94]) potwierdzaj ˛a wag˛e problemu wyst˛epowania awarii zarówno w systemach serwerowych jak i konsumenckich stacjach roboczych. Rodzi to potrzeb˛e opracowywania nowych mechanizmów zwi˛ekszania niezawodno´sci, które mog ˛a by´c stosowane w systemach typu COTS3.
1.1. Motywacja do powstania pracy
Mechanizmy podnosz ˛ace niezawodno´s´c s ˛a wykorzystywane w specjalistycznych rozwi ˛azaniach, maj ˛acych na celu zwi˛ekszenie bezpiecze´nstwa ludzkiego ˙zycia lub minimalizacj˛e finansowych. W krytycznych zastosowaniach systemów komputerowych wi˛eksza niezawodno´s´c osi ˛agana jest poprzez ugruntowane metody realizowane sprz˛etowo lub programowo – np. redundancja, punkty kontrolne (checkpoint), czy n-version programming (patrz 2.3). Jednak wiele z tych technik nie jest wykorzystywanych w komponentach COTS ze wzgl˛edu na wi˛eksze koszty projektowania lub produkcji – przykładowo w komputerach przeznaczonych na rynek konsumencki standardowo nie s ˛a montowane dyski twarde
1 http://money.cnn.com/2011/04/21/technology/amazon_server_outage/index.htm
2 Ang. Point of Service.
3 Ang. Customer Of The Shelf.
wykorzystuj ˛ace technologi˛e RAID4, znacz ˛aco zmniejszaj ˛ace prawdopodobie´nstwo utraty danych, a przygotowywanie kilku wersji oprogramowania, ocenianych pó´zniej pod wzgl˛edem wra˙zliwo´sci na bł˛edy, jest wykorzystywane tylko w specjalistycznych dziedzinach. Wiele systemów komputerowych oferowanych konsumentom pozbawionych jest ochrony przed efektami awarii, a s ˛a tak˙ze zbudowane z ta´nszych komponentów bardziej podatnych na usterki (patrz [84]).
Sprz˛etowe metody zwi˛ekszania niezawodno´sci s ˛a rozwi ˛azaniami drogimi w produkcji ze wzgl˛edu na koszt dodatkowych układów montowanych w ka˙zdym z produkowanych urz ˛adze´n.
Z tego wzgl˛edu szczególnie interesuj ˛ace s ˛a programowe metody zwi˛ekszania niezawodno´sci, które mog ˛a by´c dodane do oprogramowania urz ˛adzenia bez dodatkowych kosztów i to nie tylko w fazie produkcji, ale równie˙z podczas eksploatacji urz ˛adzenia.
Technik ˛a wykorzystywan ˛a w obszarze bada´n nad niezawodno´sci ˛a oprogramowania jest SWIFI5 (patrz [8]). Polega ona na wprowadzaniu bł˛edów do systemu komputerowego metod ˛a programow ˛a w celu ewaluacji jego działania w obliczu zaburze´n. Instytut Informatyki Politechniki Warszawskiej posiada bogate do´swiadczenie z wykorzystaniem techniki SWIFI (m.in. [37, 38, 42, 96, 97] ). Badania prowadzone w Instytucie pozwoliły na opracowanie wielu narz˛edzi wstrzykiwania bł˛edów, ocen˛e podatno´sci na bł˛edy ró˙znych typów oprogramowania, zaproponowanie rozwi ˛aza´n programowych zwi˛ekszaj ˛acych niezawodno´s´c, a tak˙ze zaawansowan ˛a analiz˛e dzienników działania systemów komputerowych.
Według autora, na podstawie analizy prac prowadzonych w Instytucie Informatyki oraz literatury, istotn ˛a dziedzin ˛a wymagaj ˛ac ˛a bada´n jest niezawodno´s´c oprogramowania systemów operacyjnych. Twierdzenie to jest uzasadnione nast˛epuj ˛aco:
— Obserwowana jest ekspansja systemów operacyjnych znanych z zastosowa´n biurowych/serwerowych do nowych dziedzin [10, 114]. Przykładami takich scenariuszy jest wykorzystanie j ˛adra systemu operacyjnego GNU/Linux w robotyce, platformie Android, czy systemów z rodziny Windows NT w platformie Windows Phone. Oznacza to, ˙ze od tych systemów oczekiwane jest niezawodne funkcjonowanie zarówno w kontrolowanych warunkach farm serwerów jak i urz ˛adzeniach przeno´snych.
— Potwierdzone s ˛a przypadki wyst˛epowania przekłama´n powoduj ˛acych awari˛e systemów operacyjnych (patrz [84]) w konsumenckich stacjach roboczych.
— Wiele przedstawionych w literaturze mechanizmów zwi˛ekszania niezawodno´sci aplikacji wykorzystuje usługi dostarczane przez systemy operacyjne, jednak niewiele jest opisanych mechanizmów zwi˛ekszania niezawodno´sci samego oprogramowania systemów operacyjnych.
4 Ang. Redundant Array of Independent Disks.
5 Ang. Software Implemented Fault Injection
Zainteresowanie autora zagadnieniem niezawodno´sci systemów operacyjnych dodatkowo zostało wzmocnione udziałem w projekcie realizowanym dla Centrum Badawczo-Rozwojowego Samsung Electronics Polska w Warszawie przez Instytut Informatyki Politechniki Warszawskiej6.
W literaturze mo˙zna znale´z´c niewiele publikacji skupiaj ˛acych si˛e na badaniu niezawodno´sci systemu operacyjnego. Według autora fakt ten wynika z nast˛epuj ˛acych problemów technicznych:
— opracowywane narz˛edzia SWIFI dla oprogramowania aplikacji najcz˛e´sciej polegaj ˛a na usługach systemu operacyjnego, co uniemo˙zliwia ich zastosowanie w j ˛adrze systemu operacyjnego,
— opracowywane narz˛edzia symulacji bł˛edów w systemie operacyjnym wymagaj ˛a modyfikacji ´zródeł j ˛adra systemu operacyjnego – powoduje to de facto badanie niezawodno´sci innego oprogramowania, ni˙z oprogramowanie docelowe (pozbawionego kodu symuluj ˛acego bł˛edy),
— ograniczona skalowalno´s´c przedstawionych rozwi ˛aza´n – do przeprowadzania eksperymentów cz˛esto dedykowany jest osobny system komputerowy; ch˛e´c zwi˛ekszenia liczby przeprowadzanych testów wi ˛a˙ze si˛e z kosztem instalacji i konfiguracji dodatkowych dedykowanych systemów komputerowych.
Niemniej badanie niezawodno´sci j ˛adra systemu operacyjnego i projektowanie mechanizmów zwi˛ekszaj ˛acych niezawodno´s´c działaj ˛acych po stronie j ˛adra systemu operacyjnego wi ˛a˙ze si˛e z potencjalnymi korzy´sciami:
— systemy operacyjne s ˛a stosowane w wi˛ekszo´sci współczesnych urz ˛adze´n, co pozwala zwi˛ekszy´c ich niezawodno´s´c niezale˙znie od ich specyficznych zastosowa´n,
— mo˙zliwo´s´c informowania aplikacji o potencjalnych problemach wykrytych przez system operacyjny,
— zwi˛ekszenie dost˛epno´sci oraz mo˙zliwo´sci diagnostyki systemu komputerowego,
— opracowanie mechanizmów zwi˛ekszania niezawodno´sci, wykorzystuj ˛acych kooperacj˛e aplikacji i systemu operacyjnego; podej´scie takie jest alternatyw ˛a dla mechanizmów, gdzie zarówno program o zwi˛ekszonej niezawodno´sci, jak i program realizuj ˛acy usługi zwi˛ekszania niezawodno´sci (np. program dokonuj ˛acy operacji wznowienia działania po awarii na podstawie wcze´sniej zapisanych wyników cz˛e´sciowych) s ˛a aplikacjami u˙zytkownika działaj ˛acymi w systemie operacyjnym.
Motywacj ˛a do powstania rozprawy jest ulepszenie realizacji metod SWIFI do badania niezawodno´sci systemów operacyjnych, w zwi ˛azku z wymienionymi problemami
6 Projekt Adapting fault injection techniques to improve Samsung mobile products współfinansowany przez Polsk ˛a Agencj˛e Rozwoju Przedsi˛ebiorczo´sci w ramach działania 1.4 Wsparcie projektów celowych osi priorytetowej 1 Badania i rozwój nowoczesnych technologii oraz działania 4.1 Wsparcie wdro˙ze´n wyników prac B+R osi priorytetowej 4 Inwestycje w innowacyjne przedsi˛ewzi˛ecia.
technicznymi, wyst˛epuj ˛acymi w obecnych rozwi ˛azaniach oraz opracowywanie na tej podstawie nowych mechanizmów zwi˛ekszaj ˛acych niezawodno´s´c. W ten sposób autor pragnie wnie´s´c wkład w proces integracji mechanizmów niezawodno´sci w opracowywanie produktów wysokiej jako´sci.
1.2. Kierunek bada ´n
Rozwa˙zania opisane w rozprawie bazuj ˛a na koncepcji zastosowania emulatora systemu komputerowego do przeprowadzania eksperymentów badania niezawodno´sci. Zastosowanie takiego podej´scia pozwala rozwi ˛aza´c wymienione powy˙zej problemy techniczne oraz posiada dodatkowe atuty: mo˙zliwe jest zwi˛ekszenie spektrum modeli symulowanych bł˛edów wzgl˛edem rozwi ˛aza´n znanych z literatury (np. o modele bł˛edów konkretnych urz ˛adze´n), a tak˙ze porównywanie mi˛edzy sob ˛a ró˙znych architektur systemów komputerowych i ró˙znych implementacji systemów operacyjnych. Dzi˛eki temu mo˙zliwe jest uzupełnienie stanu wiedzy o nowe fakty nieopisane w literaturze. Opracowanie ´srodowiska symulacji bł˛edów, wykorzystuj ˛acego emulator, wymagało dogł˛ebnego poznania szczegółów implementacji zarówno ró˙znych technik emulacji, jak i systemów operacyjnych.
Badania przeprowadzone w przygotowanym przez autora ´srodowisku pozwoliły na szczegółow ˛a analiz˛e scenariuszy wyst ˛apienia bł˛edów w systemie operacyjnym. Na tej podstawie autor opracował metody zwi˛ekszania niezawodno´sci implementowane po stronie j ˛adra systemu operacyjnego, przy czym przyj˛ete zostało zało˙zenie integracji opracowywanych mechanizmów z istniej ˛acym oprogramowaniem. Opracowane mechanizmy bazuj ˛a na wzbogaceniu procedur obsługi przerwa´n zaimplementowanych w systemie operacyjnym o dodatkowe kroki umo˙zliwiaj ˛ace kontynuowanie pracy systemu.
1.3. Teza i cel rozprawy
Tez ˛a pracy jest stwierdzenie:
Integracja technik symulacji bł˛edów z emulacj ˛a systemu komputerowego umo˙zliwia dokładniejsz ˛a ocen˛e wra˙zliwo´sci na bł˛edy oprogramowania systemu operacyjnego oraz weryfikacj˛e skuteczno´sci mechanizmów zwi˛ekszania niezawodno´sci.
Celem rozprawy jest:
Opracowanie metodyki, algorytmów oraz narz˛edzi słu˙z ˛acych ocenie niezawodno´sci systemów komputerowych typu COTS oraz zaproponowanie nowych typów mechanizmów
zwi˛ekszania niezawodno´sci implementowanych po stronie j ˛adra systemu operacyjnego, wraz z ocen ˛a ich efektywno´sci.
Cel rozprawy osi ˛agni˛eto poprzez:
— opracowanie autorskich rozszerze´n oprogramowania emulatora o funkcje:
— symulacji bł˛edów,
— nieinwazyjnego ´sledzenia wykonania,
— zaproponowanie oryginalnej metodyki i scenariuszy przeprowadzania eksperymentów z wykorzystaniem emulatora oraz miar słu˙z ˛acych ocenie wra˙zliwo´sci systemu na bł˛edy,
— opracowanie algorytmów i oprogramowania QEFI realizuj ˛acego zaproponowan ˛a metodyk˛e,
— przeprowadzenie serii eksperymentów z wykorzystaniem opracowanych narz˛edzi:
— porównanie wra˙zliwo´sci na bł˛edy ró˙znych architektur sprz˛etowych,
— porównanie wra˙zliwo´sci na bł˛edy ró˙znych systemów operacyjnych,
— zbadanie efektów bł˛edów wyst˛epuj ˛acych w ró˙znych urz ˛adzeniach,
— zbadanie wra˙zliwo´sci na bł˛edy kodu, danych statycznych, danych tylko do odczytu, danych alokowanych oraz stosu systemu operacyjnego,
— zaproponowanie metody zwi˛ekszania niezawodno´sci w przypadku przekłama´n w kodzie systemu operacyjnego i jej weryfikacja z zastosowaniem opracowanej metodyki,
— opracowanie eksperymentalnej metody ochrony stosu, wykorzystuj ˛acej współprac˛e aplikacji oraz j ˛adra systemu operacyjnego.
Dodatkowo na podstawie obserwacji efektów bł˛edów w kodzie systemu operacyjnego zdefiniowany został problem odtwarzalno´sci oraz opracowano algorytm brudnych zasobów.
1.4. Układ pracy
Praca składa si˛e z sze´sciu rozdziałów, bibliografii oraz dodatku zawieraj ˛acego informacje o opracowanym oprogramowaniu. Rozdział pierwszy stanowi wprowadzenie do tematyki rozprawy oraz zdefiniowanie tezy i celu rozprawy.
Rozdział drugi przedstawia tło bada´n nad niezawodno´sci ˛a z wykorzystaniem SWIFI oraz znane z literatury mechanizmy zwi˛ekszania niezawodno´sci. Opisane s ˛a modele badanych bł˛edów oraz zdefiniowane s ˛a miary opisuj ˛ace wpływ symulowanych bł˛edów na system komputerowy, wykorzystane w dalszej cz˛e´sci rozprawy.
Rozdział trzeci zawiera opis opracowanej metodyki przeprowadzania eksperymentów symulacji bł˛edów z wykorzystaniem emulacji systemu komputerowego. W rozdziale opisane jest opracowane przez autora narz˛edzie QEFI, słu˙z ˛ace symulacji bł˛edów w emulowanym systemie komputerowym, profilowaniu działania systemu oraz analizie efektów
wprowadzanych bł˛edów. Przedstawiona jest architektura QEFI, uzasadnione s ˛a decyzje projektowe oraz opisane s ˛a algorytmy, słu˙z ˛ace realizacji opracowanej metodyki.
Rozdział czwarty przedstawia praktyczne wykorzystanie metodyki w serii eksperymentów opartych o opracowane przez autora scenariusze testów. Przedstawiono porównanie wra˙zliwo´sci na bł˛edy ró˙znych architektur ISA procesorów (patrz 4.3) oraz porównanie ró˙znych systemów operacyjnych (patrz 4.4). Opracowana została seria bada´n nad wra˙zliwo´sci ˛a na bł˛edy systemu operacyjnego GNU/Linux – zbadano efekty bł˛edów wyst˛epuj ˛acych w urz ˛adzeniach systemu komputerowego (patrz 4.5.1) oraz ró˙znych typach danych: kod, stos, dane alokowane, dane statyczne oraz dane tylko do odczytu (patrz 4.5.2, 4.5.3). W opisie eksperymentów wprowadzania bł˛edów w przestrze´n kodu, stosu oraz danych alokowanych, przedstawiono wykorzystanie mechanizmów profilowania zintegrowanych z QEFI.
W rozdziale pi ˛atym opisano opracowane mechanizmy zwi˛ekszania niezawodno´sci – metod˛e obsługi przerwa´n, algorytm brudnych zasobów oraz metod˛e ochrony stosu. Mechanizmy te pozwalaj ˛a unikn ˛a´c wyst ˛apienia sytuacji wyj ˛atkowej podczas wykonania oprogramowania i mog ˛a by´c łatwo zintegrowane z systemem operacyjnym GNU/Linux z u˙zyciem mechanizmu kprobes. Skuteczno´s´c metody obsługi przerwa´n została zweryfikowana z u˙zyciem QEFI.
Przy opracowaniu algorytmu brudnych zasobów zdefiniowany został problem odtwarzalno´sci – tzn. przywrócenia prawidłowego stanu wykonania programu po wykonaniu serii zaburzonych instrukcji. Skuteczno´s´c algorytmu brudnych zasobów została oszacowana poprzez symulacj˛e.
Natomiast metoda ochrony stosu prezentuje technik˛e kooperacji aplikacji oraz systemu operacyjnego przy zwi˛ekszaniu niezawodno´sci. Dodatkowo przeprowadzona została dyskusja nad mechanizmami ochrony danych w systemie operacyjnym
Rozdział szósty stanowi podsumowanie przeprowadzonych bada´n. Rozdział zawiera wnioski i spostrze˙zenia z przeprowadzonych bada´n. Przedstawione s ˛a zastosowania zaproponowanych rozwi ˛aza´n oraz dalsze kierunki bada´n.
Dodatek zawiera wykaz funkcji opracowanego oprogramowania QEFI wraz z informacj ˛a o zmianach w oprogramowaniu QEMU oraz j ˛adrze systemu GNU/Linux.
2. Analiza wpływu bł˛edów na działanie systemu komputerowego
Projektowanie mechanizmów zwi˛ekszania niezawodno´sci systemów komputerowych wymaga analizy problemów wyst˛epuj ˛acych podczas eksploatacji. Na podstawie tych danych tworzone s ˛a modele bł˛edów, które wykorzystywane s ˛a przy ewaluacji skuteczno´sci technik obsługi sytuacji wyj ˛atkowych.
W rozdziale przedstawiony jest model systemu komputerowego, stanowi ˛acy podstaw˛e dalszych rozwa˙za´n. Nast˛epnie scharakteryzowane s ˛a ´zródła bł˛edów eksploatacyjnych w systemach cyfrowych, podstawowe techniki badania i zwi˛ekszania niezawodno´sci oraz modele bł˛edów opisuj ˛ace efekty zaburze´n w warstwie logicznej. Ostatnia cz˛e´s´c rozdziału po´swi˛econa jest miarom niezawodno´sci – wprowadzone miary wykorzystane s ˛a do oceny kondycji systemu komputerowego w rozdziałach 4 oraz 5.
2.1. Model systemu komputerowego
Celem systemów komputerowych jest udost˛epnianie okre´slonych funkcji. Sposób ich realizacji zapisany jest w postaci oprogramowania. Oprogramowanie operuje na danych wej´sciowych i w wyniku wykonania zaimplementowanych algorytmów wytwarza dane wyj´sciowe. Za wykonanie oprogramowania oraz dostarczenie danych do i z systemu komputerowego odpowiedzialne s ˛a zasoby sprz˛etowe. Powy˙zsza charakterystyka pozwala na zdefiniowanie systemu komputerowego:
Definicja 2.1.1. System komputerowy jest to SK ≡ H × S × D, gdzie H – zasoby sprz˛etowe, S – oprogramowanie, D – dane.
Zasoby sprz˛etowe składaj ˛a si˛e z wielu urz ˛adze´n o skomplikowanej wewn˛etrznej strukturze.
Dzi˛eki sieci poł ˛acze´n oraz opracowanym interfejsom komunikacji mo˙zliwe jest współdziałanie urz ˛adze´n w celu realizacji okre´slonych zada´n. W sekcji 2.1.1 przedstawiony jest model tych urz ˛adze´n, opracowany na potrzeby niniejszej rozprawy.
Oprogramowanie systemu komputerowego jest niezmienne podczas eksploatacji systemu (z wył ˛aczeniem czynno´sci konfiguracyjnych), natomiast dane s ˛a zmienne i wykorzystywane na bie˙z ˛aco przy realizacji okre´slonych funkcji. Oprogramowanie mo˙zna podzieli´c według
miejsca wykonania (np. procesory ogólnego przeznaczenia1, procesory specjalistyczne2, układy wbudowane3) oraz poziomu abstrakcji – stos oprogramowania rozci ˛aga si˛e od oprogramowania bezpo´srednio obsługuj ˛acego urz ˛adzenia elektroniczne do aplikacji u˙zytkownika realizuj ˛acych okre´slone funkcje. W sekcji 2.1.2 szczegółowo przestawiono opracowany model oprogramowania.
2.1.1. Model zasobów sprz˛etowych
W systemach komputerowych podstawowymi komponentami s ˛a procesory, pami˛e´c oraz urz ˛adzenia wej´scia/wyj´scia. Urz ˛adzenia te współpracuj ˛a ze sob ˛a za po´srednictwem interfejsów umo˙zliwiaj ˛acych wymian˛e danych.
Procesor
Procesor jest to układ cyfrowy realizuj ˛acy sekwencyjne wykonanie instrukcji pobieranych z pami˛eci. Zbiór instrukcji procesora okre´slany jest jako ISA4. Operacje zakodowane przez instrukcje mo˙zna podzieli´c według nast˛epuj ˛acych kategorii: ładowanie danych do pami˛eci, manipulowanie danymi (wykonywanie oblicze´n), zapisywanie danych w pami˛eci, instrukcje steruj ˛ace (instrukcje skoku i warunkowe) oraz instrukcje specjalne (np. instrukcje opró˙znienia pami˛eci podr˛ecznej). Procesor dysponuje rejestrami – s ˛a to komórki pami˛eci wykorzystywane do przechowywania po´srednich wyników oblicze´n oraz stanu procesora. Mo˙zna wyró˙zni´c rejestry danych, adresowe, ogólnego przeznaczenia, zmiennoprzecinkowe, wektorowe oraz specjalne (patrz [56]). Procesor wyposa˙zony jest równie˙z w mechanizm obsługi przerwa´n, pozwalaj ˛acy na wstrzymanie aktualnie wykonywanego kodu i wykonanie przez procesor kodu procedury obsługi przerwania. Przerwania mog ˛a by´c zgłaszane przez: urz ˛adzenia zewn˛etrzne (np. sygnalizowane jest w ten sposób nadej´scie nowych danych), zegary (wykorzystywane przy implementacji systemów z podziałem czasu), procesor (s ˛a to wyj ˛atki procesora wywołane wykonaniem przez program niedozwolonej operacji) lub wykonanie specjalnej instrukcji przerwania programowego.
Przedstawiony model procesora jest modelem logicznym. Współczesne procesory w celu przy´spieszenia wykonania dysponuj ˛a dodatkowymi układami realizuj ˛acymi specjalizowane zadania: potok wykonania, układ przewidywania skoków, superskalarne jednostki wykonawcze oraz zwielokrotnienie rejestrów. Elementy te stanowi ˛a mikroarchitektur˛e procesora (patrz [51]) i słu˙z ˛a przy´spieszeniu jego pracy. Integraln ˛a cz˛e´s´c procesora stanowi równie˙z pami˛e´c podr˛eczna. Jest to mechanizm buforowania danych i instrukcji przechowywanych w pami˛eci operacyjnej w pami˛eci o krótszym czasie dost˛epu.
1 Współcze´snie konstruowane s ˛a systemy wieloprocesorowe, gdzie system komputerowy wyposa˙zony jest kilka fizycznych procesorów, a ka˙zdy z nich pełni funkcj˛e jednego lub wi˛ecej procesorów logicznych.
2 Np. Układy graficzne GPU (Ang. Graphics Processing Unit).
3 Np. kontrolery RAID.
4 Ang. Instruction Set Architecture.
Rozwi ˛azanie to zostało wprowadzone z uwagi na du˙zy koszt wytworzenia pojemnej pami˛eci o krótkim czasie dost˛epu. Wykorzystane zostało tu zjawisko czasowej i przestrzennej lokalno´sci odwoła´n. Pami˛eci podr˛eczne organizowane s ˛a w hierarchiczne struktury – najcz˛e´sciej wykorzystywane s ˛a dwa lub trzy poziomy pami˛eci podr˛ecznej, gdzie ka˙zdy kolejny poziom charakteryzuje si˛e wi˛eksz ˛a pojemno´sci ˛a oraz dłu˙zszym czasem dost˛epu. Dost˛ep do wymienionych układów procesora jest niemo˙zliwy z poziomu wykonywanych programów (wyj ˛atkiem jest specjalna instrukcja procesora wymuszaj ˛aca uniewa˙znienie zawarto´sci danych w pami˛eci podr˛ecznej).
Warto zaznaczy´c, ˙ze we współczesnych procesorach stosuje si˛e wi˛ecej, ni˙z jeden rdze´n wykonania, co pozwala na zwi˛ekszenie wydajno´sci systemu. Rdzenie te posiadaj ˛a wspóln ˛a pami˛e´c podr˛eczn ˛a i poł ˛aczone s ˛a jedn ˛a szyn ˛a danych do reszty systemu. Dodatkowo ka˙zdy z rdzeni mo˙ze by´c wyposa˙zony w technologi˛e hyper threading, która powoduje, ˙ze pojedynczy rdze´n jest widoczny dla systemu operacyjnego jako dwie wirtualne jednostki wykonawcze.
Technologia ta polega na zwielokrotnieniu niektórych zasobów procesora w taki sposób,
˙ze mo˙zliwe jest przechowywanie dwóch kontekstów wykonania. W przypadku, gdy jedna jednostka wykonania zostaje wstrzymana (np. podczas oczekiwania na dane pobierane z pami˛eci) rdze´n przeł ˛acza si˛e na kontekst drugiej jednostki wykonania, umo˙zliwiaj ˛ac w ten sposób realizacj˛e równolegle dwóch zada´n.
Pami˛e´c
Pami˛e´c realizuje funkcj˛e przechowywania danych. Mo˙zna wyró˙zni´c pami˛e´c ROM5oraz RAM6. Pami˛eci ROM słu˙z ˛a przechowywaniu danych tylko do odczytu – s ˛a to np. procedury startowe systemu komputerowego. Natomiast pami˛e´c RAM jest pami˛eci ˛a ogólnego przeznaczenia umo˙zliwiaj ˛ac ˛a zapis oraz odczyt danych. Pami˛e´c RAM s ˛a nazywane równie˙z pami˛eci ˛a operacyjn ˛a w odró˙znieniu od innych, specjalizowanych typów pami˛eci (np. pami˛e´c podr˛eczna procesora).
Istotnym układem wykorzystywanym w obsłudze pami˛eci jest MMU7 – jest to urz ˛adzenie odpowiedzialne za mechanizm pami˛eci wirtualnej, tworz ˛acy dla ka˙zdego z programów wykonywanych przez procesor osobn ˛a przestrze´n adresow ˛a. Obecnie układ MMU stanowi integraln ˛a cz˛e´s´c procesora. Urz ˛adzenie to w ´scisłej współpracy z systemem operacyjnym dzieli pami˛e´c na strony i zarz ˛adza ich stanem (m.in. wolna, załadowana, w pliku wymiany) oraz prawami dost˛epu (strona zawiera wykonywalny kod, dane, dane tylko do odczytu).
Urz ˛adzenia wej´scia/wyj´scia
Systemy komputerowe wyposa˙zane s ˛a w dodatkowe urz ˛adzenia realizuj ˛ace funkcje komunikacyjne, multimedialne, wskazuj ˛ace oraz pami˛eci masowej. Poszczególne urz ˛adzenia
5 Ang. Read Only Memory.
6 Ang. Random Access Memory.
7 Ang. Memory Management Unit.
systemu komputerowego wymieniaj ˛a dane z procesorem oraz pami˛eci ˛a z zastosowaniem magistral. Współpraca procesora oraz urz ˛adze´n wej´scia/wyj´scia realizowana jest przez przerwania oraz mechanizm Memory mapped I/O, czyli przypisanie cz˛e´sci przestrzeni adresowej dost˛epnej dla procesora bezpo´srednio do rejestrów urz ˛adze´n zamiast do pami˛eci operacyjnej.
2.1.2. Model oprogramowania
Oprogramowanie systemu komputerowego słu˙zy przetwarzaniu danych według okre´slonych przez twórców algorytmów. Jest ono zapisane w postaci zestawu instrukcji wykonywanych przez procesor – zbiór instrukcji nazywany jest równie˙z kodem programu. W celu realizacji swoich zada´n oprogramowanie wykorzystuje pami˛e´c. Mo˙zna wyró˙zni´c kilka typów pami˛eci ze wzgl˛edu na przechowywane dane: stos programowy, pami˛e´c statyczn ˛a, pami˛e´c tylko do odczytu oraz pami˛e´c alokowan ˛a.
Stos programowy słu˙zy jako pami˛e´c przechowuj ˛aca dane tymczasowe oblicze´n, gdy jest ich zbyt wiele, aby zostały zapisane w rejestrach procesora. Dodatkowo wykorzystywany jest on w programowaniu wysokopoziomowym, pozwalaj ˛ac na hierarchiczne wywołania procedur.
Pami˛e´c statyczna s ˛a to obszary pami˛eci stałego rozmiaru dost˛epne na ka˙zdym etapie oblicze´n pod tym samym adresem. W pami˛eci tego typu przechowywane s ˛a dane globalne – s ˛a to dane dost˛epne na ka˙zdym etapie wykonania programu.
Pami˛e´c tylko do odczytu zawiera niezmienne podczas oblicze´n dane. Mi˛edzy innymi jest to kod programu, zakodowane obrazy wy´swietlane u˙zytkownikowi na ekranie, czy stałe napisowe, b˛ed ˛ace szablonami komunikatów wypisywanych podczas interakcji z programem.
Pami˛e´c alokowana jest przydzielana w trakcie oblicze´n według potrzeb wykonywanego algorytmu. Charakteryzuje si˛e zmiennym rozmiarem oraz tym, ˙ze jest przyznawana przez mechanizmy alokacji pami˛eci systemu operacyjnego spo´sród dost˛epnej w danej chwili puli wolnej pami˛eci. Istnieje wiele algorytmów alokacji pami˛eci, które ró˙zni ˛a si˛e czasami alokacji oraz stopniem fragmentacji pami˛eci8. Opracowane s ˛a równie˙z zaawansowane techniki zarz ˛adzania pami˛eci ˛a, pozwalaj ˛ace na automatyczne zwalnianie niewykorzystywanej pami˛eci (garbage collection), jednak nie s ˛a one wykorzystywane w ka˙zdym rodzaju oprogramowania ze wzgl˛edu na niedeterministyczny charakter działania.
Dynamika alokacji oraz lokalno´s´c odwoła´n jest ´sci´sle zwi ˛azana z realizowanymi algorytmami oraz wykorzystywanymi strukturami danych. Przykładowo alokacja danych na potrzeby listowej struktury danych9 jest wykorzystana przy ka˙zdym dodawaniu nowego elementu, a tak˙ze przeszukiwanie kolejno w˛ezłów listy powoduje dost˛ep do wielu miejsc w pami˛eci (ka˙zdy
8 Fragmentacja powstaje w przypadku dzielenia przez algorytm alokacji pami˛eci na bloki o stałym rozmiarze.
Kiedy blok jest wykorzystywany na alokacj˛e pami˛eci o mniejszym rozmiarze, ni˙z rozmiar bloku – w ten sposób niewykorzystana cz˛e´s´c pami˛eci staje si˛e niedost˛epna.
9 Opis listowej struktury danych dla j˛ezyka C++: http://www.cplusplus.com/reference/list/list/
w˛ezeł jest alokowany osobno i miejsce jego poło˙zenia w pami˛eci jest zale˙zne od algorytmu alokacji). Natomiast zastosowanie wektorowej struktury danych10 pozwala na redukcj˛e liczby alokacji oraz przegl ˛ad kolejnych elementów struktury danych, charakteryzuje si˛e liniowym dost˛epem do kolejnych adresów pami˛eci (niemniej zysk ten obarczony jest wi˛eksz ˛a zło˙zono´sci ˛a obliczeniow ˛a przy usuwaniu elementów z wektora, w zwi ˛azku z konieczno´sci ˛a przeniesienia elementów znajduj ˛acych si˛e za usuwanym elementem w now ˛a lokalizacj˛e11).
Oprogramowanie systemu komputerowego mo˙zna podzieli´c na trzy rodzaje:
oprogramowanie wbudowane (firmware), system operacyjny oraz aplikacje u˙zytkownika.
Firmware jest oprogramowaniem dedykowanym dla poszczególnych urz ˛adze´n i jest wykonywany przez układy elektroniczne stanowi ˛ace integraln ˛a cz˛e´s´c tych urz ˛adze´n. Natomiast oprogramowanie systemu operacyjnego i aplikacji u˙zytkownika wykonywane jest przez procesor systemu komputerowego. Istniej ˛a tak˙ze metody pozwalaj ˛ace na wykonywanie specjalnie zaprojektowanych programów na procesorach specjalizowanych karty graficznej w celu osi ˛agni˛ecia wi˛ekszej wydajno´sci12, jednak oprogramowanie tego typu nie jest rozwa˙zane w niniejszej rozprawie. Poni˙zej przedstawiona jest charakterystyka wymienionych typów oprogramowania zawieraj ˛aca opis struktury, funkcji oraz wzajemnych interakcji pomi˛edzy modułami programowymi.
Oprogramowanie wbudowane
Oprogramowanie wbudowane w komputerach typu COTS wyst˛epuje w wielu urz ˛adzeniach – np. kartach graficznych, kontrolerach RAID, dyskach twardych, czy płytach głównych.
Oprogramowanie to charakteryzuje si˛e wysokim stopniem specjalizacji – jego głównym celem jest zapewnienie poprawnej pracy obsługiwanych urz ˛adze´n. Przykładowo zadaniem oprogramowania wbudowanego w dyski twarde jest realizacja strategii odczytu danych z wyprzedzeniem do pami˛eci podr˛ecznej oraz opó´znionego zapisu13.
Wspóln ˛a cech ˛a oprogramowania wbudowanego jest to, i˙z rzadko jest modyfikowane w produkcyjnym cyklu ˙zycia urz ˛adzenia. Je˙zeli aktualizacja jest konieczna, to operacja ta wymaga przeprowadzenia dedykowanej procedury dla ka˙zdego typu sprz˛etu.
Oprogramowanie wbudowane wykonywane jest niezale˙znie od głównego procesora systemu komputerowego przez układy elektroniczne poszczególnych urz ˛adze´n (np. dysku twardego, adaptera sieciowego). Komunikacja natomiast z zewn˛etrznymi układami odbywa si˛e
10 Opis wektorowej struktury danych dla j˛ezyka C++: http://www.cplusplus.com/reference/vector/vector/
11 Niemniej dzi˛eki lokalno´sci danych składowanych w wektorze czas usuni˛ecia losowo wybranego elementu z listy mo˙ze by´c mniejszy, ni˙z w przypadku listy:
http://www.baptiste-wicht.com/2012/12/cpp-benchmark-vector-list-deque/
12 Np. technologia CUDA umo˙zliwia wykonanie oprogramowania na procesorze GPU – http://www.nvidia.com/object/cuda_home_new.html.
13 Funkcja ta polega na grupowaniu i zmianie kolejno´sci ˙z ˛ada´n zapisania danych na dysk w celu optymalizacji operacji wykonywanych przez głowic˛e dysku twardego.
przez układy sprz˛etowe np. magistrale lub bezpo´srednie przył ˛aczenie do przestrzeni adresowej procesora (Memory mapped I/O).
System operacyjny
System operacyjny jest oprogramowaniem po´srednicz ˛acym mi˛edzy zasobami sprz˛etowymi oraz oprogramowaniem u˙zytkownika – posiada pełen dost˛ep do zasobów sprz˛etowych i udost˛epnia je aplikacjom u˙zytkownika za po´srednictwem ujednoliconych interfejsów programistycznych (patrz [103]). Poni˙zej jako system operacyjny rozwa˙zane jest przede wszystkim j ˛adro systemu operacyjnego. Aplikacje narz˛edziowe dostarczane wraz z systemem operacyjnym nie ró˙zni ˛a si˛e sposobem komunikacji z j ˛adrem od pozostałych aplikacji u˙zytkownika.
System operacyjny wyposa˙zony jest w szereg mechanizmów tworz ˛acych ´srodowisko wykonania aplikacji u˙zytkownika. Podstawowym mechanizmem zaimplementowanym we współczesnych systemach operacyjnych jest mechanizm procesów. Proces jest to instancja wykonania programu wraz z przypisanymi do niej zasobami. System operacyjny odpowiedzialny jest za załadowanie kodu programu dla ka˙zdego procesu, a nast˛epnie przydziela zasoby takie jak czas procesora, pami˛e´c, dost˛ep do pami˛eci masowej lub innych urz ˛adze´n.
Procesy s ˛a zorganizowane w struktur˛e drzewiast ˛a, gdzie ka˙zdy proces jest rodzicem dla uruchomionych przez siebie procesów (dzieci), a korzeniem drzewa jest specjalny proces uruchamiany przez system operacyjny. W ramach procesu mo˙ze by´c uruchomionych wiele w ˛atków – podstawowa jednostka wykonywania, dysponuj ˛aca własnym zestawem rejestrów oraz stosem programowym współdziel ˛aca pami˛e´c z pozostałymi w ˛atkami w ramach procesu. Zastosowanie w ˛atków oraz procesów pozwala na przetwarzanie równoległe, co dzi˛eki zastosowaniu procesorów wielordzeniowych pozwala na równoczesne wykonanie kilku programów, zwi˛ekszaj ˛ac w ten sposób wydajno´s´c systemu.
Pozostałe usługi realizowane przez system operacyjny to: zarz ˛adzanie procesami (np. wstrzymywanie/wznawianie wykonania), przydział czasu procesora poszczególnym procesom, synchronizacja i komunikacja mi˛edzyprocesowa, mechanizm sygnałów, zarz ˛adzanie pami˛eci ˛a, obsługa urz ˛adze´n peryferyjnych, realizacja poł ˛acze´n sieciowych, obsługa systemu plików. Cało´s´c usług dostarczanych przez system operacyjny stanowi ´srodowisko wykonania dla aplikacji u˙zytkownika.
Aplikacje u˙zytkownika komunikuj ˛a si˛e z systemem operacyjnym za po´srednictwem wywoła´n systemowych. Procedura obsługi ˙z ˛ada´n aplikacji u˙zytkownika składa si˛e z nast˛epuj ˛acych kroków (kursyw ˛a zapisane s ˛a kroki wykonywane przez oprogramowanie systemu operacyjnego):
1. odło˙zenie na stos programowy parametrów wywołania systemowego, 2. wykonanie dedykowanej instrukcji przerwania programowego,
3. procesor przechodzi z trybu u˙zytkownika do trybu systemu operacyjnego, 4. odczytanie parametrów wywołania systemowego,
5. obsługa wywołania,
6. zast ˛apienie parametrów wywołania systemowego wynikiem wywołania, 7. powrót do trybu u˙zytkownika i wznowienie wykonania.
Oprócz wspomnianych przerwa´n wywoła´n systemowych system operacyjny obsługuje równie˙z przerwania sprz˛etowe oraz przerwania wywołane sytuacjami wyj ˛atkowymi.
Przerwania sprz˛etowe słu˙z ˛a do obsługi sygnałów pochodz ˛acych z urz ˛adze´n zewn˛etrznych lub magistrali danych – np. klawiatura systemowa, kontroler DMA14. Obsługa przerwania sprz˛etowego najcz˛e´sciej oznacza odebranie danych z urz ˛adzenia zewn˛etrznego i przekazanie ich do oczekuj ˛acego na nie procesu. Sytuacje wyj ˛atkowe zgłaszane s ˛a przez procesor w przypadku naruszenia zasad bezpiecze´nstwa lub wykonania nieprawidłowych operacji. Cz˛e´s´c sytuacji wyj ˛atkowych jest krytyczna i nie pozwala na dalsze wykonanie kodu – np. wyj ˛atek dzielenia przez zero lub próba zapisu do pami˛eci tylko do odczytu. Przykłady przerwa´n, które system operacyjny mo˙ze obsłu˙zy´c, to pułapka debug (słu˙zy do wstrzymania wykonania procesu i przekazania sterowania do oprogramowania debuggera w celach diagnostycznych), czy bł ˛ad stronicowania15 (ang. page fault). Przy zarz ˛adzaniu pami˛eci ˛a procesor współpracuje z układem MMU opisanym w 2.1.1. W przypadku udanej obsługi sytuacji wyj ˛atkowej wykonywanie kodu jest wznawiane od instrukcji, która wywołała przerwanie. Je˙zeli obsługa nie jest mo˙zliwa, system operacyjny awaryjnie ko´nczy działanie bł˛ednego programu. Gdy ´zródłem bł˛edu jest kod systemu operacyjnego implementowane s ˛a ró˙zne strategie działania: np. systemy operacyjne z rodziny Windows wy´swietlaj ˛a niebieski ekran z informacjami diagnostycznymi bł˛edu i wymagany jest restart systemu komputerowego, natomiast systemy z rodziny Linux wypisuj ˛a informacje diagnostyczne na wszystkich dost˛epnych konsolach i ko´ncz ˛a działanie w ˛atku, na rzecz którego wykonywany był kod zgłaszaj ˛acy ˙z ˛adanie – restart systemu nie jest wymagany, jednak system komputerowy mo˙ze działa´c niestabilnie lub nie odpowiada´c na ˙z ˛adania. Procedura obsługi sytuacji wyj ˛atkowej w systemie operacyjnym, w przypadku niepowodzenia przy jej obsłudze, zbiera mo˙zliwie najwi˛ecej danych o kontek´scie wyst ˛apienia wyj ˛atku i wypisuje je na ekran. Dane te mog ˛a zawiera´c m.in. typ zgłoszonego wyj ˛atku, zawarto´s´c rejestrów procesora, załadowane moduły systemu operacyjnego, dane procesu, czy stos wywoła´n funkcji (ang. stack-trace).
System operacyjny mo˙ze by´c rozszerzany o dodatkowe funkcje poprzez ładowane w trakcie działania systemu moduły. Moduły mog ˛a by´c wykorzystane do rozszerzenia zbioru wywoła´n systemowych, implementacji nowych mechanizmów w j ˛adrze systemu operacyjnego (np. nowego system plików), jednak najcz˛estszym wykorzystaniem jest dostarczenie dla systemu operacyjnego sterowników – s ˛a to specjalne programy stanowi ˛ace
14 Ang. Direct Memory Access
15 Jest to cz˛e´s´c mechanizmu pami˛eci wirtualnej, sygnalizuj ˛aca dost˛ep do pami˛eci wirtualnej niedost˛epnej w danej chwili w pami˛eci fizycznej, a obsługa polega na załadowaniu przez system ˙z ˛adanej strony pami˛eci z pliku wymiany.
ł ˛acznik mi˛edzy systemem operacyjnym, a konkretnym urz ˛adzeniem. Zadaniem sterowników jest implementacja okre´slonego interfejsu zdefiniowanego w systemie operacyjnym dla danego typu urz ˛adzenia, jednocze´snie oprogramowuj ˛ac specyficzny dla danego typu urz ˛adzenia protokół wymiany danych, który mo˙ze by´c ró˙zny dla urz ˛adze´n dostarczanych przez ró˙znych producentów.
Istnieje kilka koncepcji konstrukcji systemu operacyjnego. Podstawowe z nich to architektura j ˛adra monolitycznego oraz mikroj ˛adra. W ramach architektury monolitycznej sterowniki oraz wszystkie usługi s ˛a integraln ˛a cz˛e´sci ˛a j ˛adra systemu operacyjnego. W przypadku mikroj ˛adra kod wykonywany w przestrzeni j ˛adra systemu operacyjnego jest ograniczony do minimum – sterowniki oraz inne usługi implementowane s ˛a jako aplikacje wykonywane w przestrzeni u˙zytkownika, komunikuj ˛ace si˛e z j ˛adrem z u˙zyciem komunikatów.
Istotnym zagadnieniem s ˛a mechanizmy alokowania pami˛eci w systemach operacyjnych.
Istnieje wiele mechanizmów wyspecjalizowanych do obsługi ró˙znych ˙z ˛ada´n. Mo˙zna wyró˙zni´c dwa główne mechanizmy alokowania pami˛eci – alokowanie na potrzeby współpracy ze sprz˛etem oraz alokowanie na potrzeby oblicze´n.
Mechanizm alokacji pami˛eci do wykorzystania ze sprz˛etem musi spełnia´c nast˛epuj ˛ace wymagania:
1. szybko´s´c – w ˛atek wywołuj ˛acy alokacj˛e nie mo˙ze by´c u´spiony w oczekiwaniu na alokacj˛e, 2. przydzielona pami˛e´c musi by´c ci ˛agła w sensie adresów fizycznych.
Wymaganie 1. jest zwi ˛azane z konieczno´sci ˛a sprawnej obsługi urz ˛adze´n – alokacje cz˛esto s ˛a wywoływane w procedurach obsługi przerwa´n generowanych przez urz ˛adzenia w celu przygotowania pami˛eci na dane przychodz ˛ace od urz ˛adze´n. Powolna alokacja w tym scenariuszu mo˙ze spowodowa´c problemy wydajno´sciowe. Natomiast wymaganie 2. wynika z zastosowania techniki DMA16, która pozwala na przesyłanie danych bezpo´srednio z urz ˛adzenia (np. dysku twardego) do pami˛eci RAM – wykorzystanie pojedynczego, ci ˛agłego bloku pami˛eci fizycznej pozwala na unikni˛ecie wielokrotnego programowania kontrolera DMA.
Implementacje tego mechanizmu alokacji zazwyczaj narzucaj ˛a alokowanie bloków pami˛eci o stałym rozmiarze, co mo˙ze powodowa´c fragmentacj˛e pami˛eci.
Alokacja na potrzeby oblicze´n nie podlega takim restrykcjom jak alokacja pami˛eci dla sprz˛etu. Mo˙ze wykorzystywa´c wolniejsze algorytmy alokacji, które gwarantuj ˛a mniejsz ˛a fragmentacj˛e. Ten mechanizm alokacji stosowany jest do przydzielania pami˛eci np. dla kodu, stosu i danych procesów u˙zytkownika.
Oprócz wymienionych głównych mechanizmów alokacji istniej ˛a równie˙z inne specjalistyczne mechanizmy. Przykładowo s ˛a to mechanizmy zoptymalizowane pod
16 Ang. Direct Memory Access.
k ˛atem przechowywania danych tymczasowych (cache), czy pozwalaj ˛ace na wykorzystanie rozszerzonych przestrzeni adresowych17.
Aplikacje u˙zytkownika
Aplikacje u˙zytkownika s ˛a to procesy uruchomione w systemie operacyjnym. Realizuj ˛a one główne zadania powierzone systemom komputerowym: np. ´srodowisko stacji roboczej, serwer WWW, czy serwer baz danych. Aplikacje te wykorzystuj ˛a do swojego działania
´srodowisko stworzone przez system operacyjny: systemy plików, mechanizmy alokacji pami˛eci, komunikacj˛e mi˛edzyprocesow ˛a, interfejsy do urz ˛adze´n sieciowych, mechanizm bibliotek współdzielonych.
Systemy plików pozwalaj ˛a na zapis oraz odczyt plików na urz ˛adzeniach takich jak dyski twarde, czy pami˛eci flash. Dzi˛eki abstrakcji systemu operacyjnego aplikacja u˙zytkownika wykorzystuje jeden interfejs programistyczny niezale˙znie od typu urz ˛adzenia przechowuj ˛acego dane.
Mechanizm alokacji pami˛eci pozwala na wykorzystanie przez procesor dowolnej ilo´sci pami˛eci z przestrzeni adresowej w celu realizacji swoich zada´n. System operacyjny udost˛epnia pami˛e´c z wykorzystaniem mechanizmu pami˛eci wirtualnej, co pozwala na wykorzystanie przez procesy wi˛ekszej ilo´sci pami˛eci, ni˙z jest dost˛epna w systemie komputerowym.
Komunikacja mi˛edzyprocesowa pozwala na wymian˛e danych mi˛edzy procesami (potoki, wiadomo´sci, pami˛e´c współdzielona), synchronizacj˛e (semafor, mutex) oraz przesyłanie sygnałów. Dzi˛eki tym mechanizmom mo˙zliwe jest koordynowanie pracy wielu procesów.
Interfejsy sieciowe pozwalaj ˛a na oprogramowanie komunikacji z innymi systemami komputerowymi. Słu˙z ˛a zarówno do udost˛epniania usług jak i korzystania z usług innych systemów komputerowych.
Ze wzgl˛edu na du˙zy stopie´n skomplikowania oprogramowania opracowana została mo˙zliwo´s´c modularyzacji kodu w postaci bibliotek. Biblioteki mog ˛a by´c powi ˛azane z programem statycznie lub dynamicznie. Statyczne biblioteki s ˛a podczas kompilacji doł ˛aczane do kompilowanego programu u˙zytkownika. Natomiast biblioteki dynamiczne pozwalaj ˛a na ładowanie bibliotek w trakcie działania programu – podczas kompilacji wykorzystywana jest jedynie informacja o interfejsie programistycznym biblioteki, na podstawie której w kodzie skompilowanego programu tworzone s ˛a niezwi ˛azane symbole stanowi ˛ace punkty wywoła´n biblioteki. Ładowanie bibliotek w trakcie działania programu wymaga wsparcia ze strony systemu operacyjnego. W systemach operacyjnych z rodziny Unix biblioteki dynamiczne nazywane s ˛a dynamic shared object, natomiast w systemach z rodziny Windows dynamic-link library. Zadaniem systemu jest odnalezienie ˙z ˛adanej biblioteki i załadowanie
17 Rozszerzona przestrze´n adresowa umo˙zliwia wykorzystanie wi˛ecej ni˙z 4GB pami˛eci na architekturach wykorzystuj ˛acych 32-bitowe słowo adresowe. Implementacja firmy Microsoft polega na udost˛epnienia przesuwnego okna dost˛epu do pami˛eci. Szczegóły mo˙zna znale´z´c na stronie http://msdn.microsoft.com/en-us/library/windows/desktop/aa366527(v=vs.85).aspx
kodu wykonywalnego do przestrzeni adresowej procesów18 i powi ˛azanie symboli z kodem załadowanej biblioteki. Kod biblioteki jest współdzielony – tzn. ładowany jest tylko raz w jedno miejsce pami˛eci i udost˛epniany klienckim procesom z zastosowaniem pami˛eci wirtualnej. Ka˙zdy z procesów posiada natomiast swoj ˛a instancj˛e danych wykorzystywanych przez bibliotek˛e.
Aplikacje te mog ˛a realizowa´c ró˙zne zadania, jednak wszystkie korzystaj ˛a z systemu operacyjnego, jako jedynej drogi komunikacji z urz ˛adzeniami oraz mi˛edzy sob ˛a.
2.2. Modele bł˛edów
Systemy komputerowe s ˛a oparte o układy cyfrowe, a ich działanie mo˙ze by´c zaburzone wskutek ró˙znorodnych procesów fizycznych. Powoduje to sytuacje, kiedy system przestaje prawidłowo wykonywa´c powierzone mu zadania. Efekty zaburze´n mog ˛a rozci ˛aga´c si˛e od trwałej niezdolno´sci systemu do pracy, poprzez tymczasowe generowanie nieprawidłowych wyników, do maskowania takich sytuacji. Podstawowym modelem nieprawidłowo´sci wyst˛epuj ˛acych w systemie jest bł ˛ad. W niniejszym podrozdziale scharakteryzowane s ˛a
´zródła bł˛edów, ich modele oraz wpływ na funkcjonowanie poszczególnych układów systemu komputerowego.
2.2.1. ´Zródła bł˛edów
Bł˛edy w systemach cyfrowych wynikaj ˛a z budowy nowoczesnych układów oraz warunków ich eksploatacji. Przeprowadzone niedawno badania firmy Google [94] wykazały, ˙ze w 32%
serwerów tej firmy w ci ˛agu roku wykryto co najmniej jeden bł ˛ad przekłamania pami˛eci.
W [16, 27, 28] przedstawiono prognoz˛e zwi˛ekszenia liczby tego typu bł˛edów wraz ze stopniem upakowania układów scalonych. Dodatkowo systemy cyfrowe s ˛a eksploatowane w wielu ró˙znych ´srodowiskach, które mog˛e mie´c niekorzystny wpływ na ich działanie – zaburzenia w działaniu mog ˛a by´c spowodowane przez promieniowanie kosmiczne, cz ˛astki alfa, impulsy elektromagnetyczne, temperatur˛e, czy degradacj˛e układów wynikaj ˛ac ˛a ze starzenia si˛e materiałów u˙zytych do ich wytworzenia.
W [59] przedstawiono wpływ wzrostu temperatury na cz˛estotliwo´s´c bł˛edów w prostych układach składaj ˛acych si˛e z przerzutników wykonanych w technologii 40 nm. Zbadano, ˙ze przy temperaturze 80 ◦C cz˛estotliwo´s´c wyst˛epowania bł˛edów mo˙ze wzrosn ˛a´c dwukrotnie, a przy temperaturze 120 ◦C trzykrotnie przy eksponowaniu układu na promieniowanie neutronowe. Dodatkowo w badaniach prowadzonych w Instytucie Telekomunikacji Politechniki Warszawskiej (patrz [68]) obserwowano znacz ˛acy wzrost przekłama´n w wynikach
18 Kod biblioteki jest specjalnie przygotowany pod k ˛atem mo˙zliwo´sci załadowania pod ró˙zne adresy pami˛eci – jest to tzw. kod relokowalny.
generowanych przez układ szyfruj ˛acy przy symulowaniu bł˛edów zegara nawet przy niewielkich zmianach temperatury pracy układu.
W [94] przedstawiono analiz˛e wykazuj ˛ac ˛a, ˙ze w modułach pami˛eci RAM po 24 miesi ˛acach u˙zytkowania cz˛estotliwo´s´c wyst˛epowania przekłama´n pami˛eci ro´snie od 1,7 do 3,5 raza w zale˙zno´sci od konkretnego produktu. Badania te równie˙z potwierdzaj ˛a korelacj˛e cz˛estotliwo´sci wyst˛epowania bł˛edów wraz ze wzrostem temperatury.
Przytoczone badania ´swiadcz ˛a o wadze problemu wyst˛epowania bł˛edów. Niemniej wiele konfiguracji systemów komputerowych nie jest badanych pod k ˛atem wyznaczenia charakterystyki wra˙zliwo´sci na bł˛edy w ró˙znych warunkach eksploatacji.
2.2.2. Charakterystyka modeli bł˛edów
Modele bł˛edów mog ˛a by´c rozwa˙zane na ró˙znych poziomach abstrakcji: fizycznym, logicznym oraz aplikacyjnym. Najni˙zszym poziomem jest fizyczny model układu.
Rozpatrywane s ˛a w nim elementy elektroniczne pod k ˛atem podatno´sci na wymienione w 2.2.1 niekorzystne oddziaływania. W szczególno´sci badany jest mechanizm przeło˙zenia si˛e tych oddziaływa´n na nieprawidłow ˛a prac˛e układu: np. fizyczne uszkodzenie układu elektronicznego, zwarcia lub rozwarcia ´scie˙zek, czy zwi˛ekszenie pr ˛adów upływowych.
Istotnym zagadnieniem jest wyznaczanie (najcz˛e´sciej eksperymentalne [8, 59]) propagacji nieprawidłowo´sci na poziomie fizycznym na modele bł˛edów logicznych. Bł˛edy logiczne rozumiane s ˛a jako nieprawidłowy stan rozpatrywanego układu. Przykładami takich modeli jest sklejenie z 0/1 (stuck-at-0/stuck-at-1), bł˛edy sprz˛e˙ze´n, czy bit-flip. Warto zaznaczy´c, ˙ze bł˛edy fizyczne mog ˛a nie by´c łatwo modelowane jako bł˛edy warstwy logicznej (np. przekształcenie układu kombinacyjnego w sekwencyjny).
Bł˛edy warstwy logicznej natomiast propaguj ˛a si˛e na bł˛edy aplikacyjne, czyli inny przebieg wykonania aplikacji w stosunku do przebiegu niezaburzonego. Przykładowo bł˛edy logiczne przekłama´n bitów w kodzie instrukcji procesora mog ˛a powodowa´c bł˛edy aplikacyjne zmian w argumentach instrukcji lub zamieni´c instrukcj˛e na inn ˛a – w przypadku architektur o zmiennej długo´sci instrukcji mo˙ze to spowodowa´c wr˛ecz lawinowe przekłamanie kolejnych instrukcji w zwi ˛azku z odczytywaniem instrukcji spod nieprawidłowych adresów. Natomiast bł˛edy w strukturach danych mog ˛a uszkodzi´c dane wła´sciwe lub dane adresowe – skutki takich bł˛edów s ˛a ´sci´sle zwi ˛azane z typem struktury danych oraz wła´sciwo´sciami przechowywanych danych.
Bł˛edy aplikacyjne objawiaj ˛a si˛e generowaniem nieprawidłowych wyników, niedost˛epno´sci ˛a usług, awariami (wykonanie przez program nieprawidłowej operacji ko´ncz ˛acej w trybie awaryjnym jego działanie) lub s ˛a one maskowane podczas wykonania oprogramowania. Warto zaznaczy´c, ˙ze niektóre typy danych s ˛a w naturalny sposób odporne na bł˛edy – np. bł ˛ad w pliku d´zwi˛ekowym mo˙ze spowodowa´c niesłyszalne dla słuchaczy przekłamania.
Bł˛edy mo˙zna scharakteryzowa´c równie˙z według czasu utrzymywania si˛e w systemie: bł˛edy trwałe, bł˛edy przemijaj ˛ace oraz bł˛edy migocz ˛ace (patrz [96]).
Bł˛edy trwałe s ˛a wynikiem uszkodze´n układów cyfrowych. Układy te działaj ˛a nieprawidłowo z powodu np. zwarcia lub przepalenia cz˛e´sci wewn˛etrznych poł ˛acze´n, wi˛ec ich naprawienie jest niemo˙zliwe. Jedn ˛a z metod redukcji efektów takich bł˛edów jest redundancja układowa, umo˙zliwiaj ˛aca przej˛ecie funkcji niedziałaj ˛acego układu przez zapasowe komponenty.
Bł˛edy przemijaj ˛ace powstaj ˛a w wyniku chwilowego zaburzenia pracy systemu – np. tymczasowe obce pola elektromagnetyczne, zakłócenia zasilania, promieniowanie kosmiczne. Charakteryzuj ˛a si˛e tym, ˙ze układ nie jest uszkodzony, a jedynie jednorazowo zmienia si˛e jego wewn˛etrzny stan. Ponowne uruchomienie systemu pozwala w tej sytuacji przywróci´c prawidłowe działanie.
Bł˛edy migocz ˛ace s ˛a to bł˛edy powoduj ˛ace tymczasowe nieprawidłowe działanie układu, tak jak w przypadku bł˛edów trwałych, niemniej mo˙zliwy jest powrót do prawidłowego działania układu po samoczynnym ust ˛apieniu bł˛edu migocz ˛acego. Detekcja bł˛edów tego typu jest mo˙zliwa wył ˛acznie w okresie aktywno´sci bł˛edu. Utrudnia to diagnostyk˛e układu z uwagi na konieczno´s´c okresowego przeprowadzania testów, aby mo˙zliwe było zaobserwowanie nieprawidłowego działania układu.
2.2.3. Bł˛edy jednostek przetwarzaj ˛acych
Nowoczesne procesory s ˛a układami cyfrowymi o du˙zym stopniu upakowania. W strukturach procesora znajduje si˛e wiele jednostek o dedykowanych funkcjach: dekoder instrukcji, potoki wykonania, układ przewidywania skoków, pami˛e´c podr˛eczna, jednostki arytmetyczne i zmiennoprzecinkowe. Wiele z tych jednostek jest niedost˛epnych w modelu programistycznym procesora. Opracowywanie modeli bł˛edów logicznych procesora jest zadaniem trudnym. Badania przeprowadzone w [43, 65] wykazuj ˛a, ˙ze bł˛edy przekłama´n bitów w ukrytych rejestrach (poziom architektury) mog ˛a powodowa´c bł˛edy innego typu na poziomie logicznym funkcjonowania procesora. Przykładowo uszkodzenie jednego z rejestrów mo˙ze objawi´c si˛e na poziomie logicznym uszkodzeniem kilku rejestrów ze wzgl˛edu na wykorzystanie registers renaming(patrz [51]). Niemniej mo˙zliwe jest rozpatrywanie cz˛e´sci układów procesora jako układów pami˛eci – w szczególno´sci dotyczy to rejestrów, pami˛eci podr˛ecznej, układu MMU oraz układu przewidywania skoków. Dzi˛eki temu mo˙zliwe jest zastosowanie modeli bł˛edów opisanych w 2.2.4.
Interesuj ˛acym zagadnieniem s ˛a przekłamania w pami˛eci podr˛ecznej stanowi ˛acej integraln ˛a cz˛e´s´c procesora ze wzgl˛edu na jej redundantny charakter wzgl˛edem pami˛eci operacyjnej.
Wyst ˛apienie bł˛edów zarówno po stronie pami˛eci operacyjnej i podr˛ecznej mo˙ze zosta´c w sposób naturalny zamaskowane:
— przekłamanie w pami˛eci podr˛ecznej jest zamaskowane, je˙zeli: dane te nie zostały odczytane i zostan ˛a usuni˛ete z pami˛eci podr˛ecznej bez zapisywania do pami˛eci głównej (dane te nie były oznaczone w pami˛eci cache jako dirty),
— przekłamanie w pami˛eci głównej jest zamaskowane, gdy prawidłowa kopia danych znajdowała si˛e w pami˛eci podr˛ecznej (kopia ta mo˙ze by´c wykorzystana przy obliczeniach) i została nadpisana now ˛a warto´sci ˛a, co oznacza nadpisanie zaburzonych danych w pami˛eci głównej.
2.2.4. Bł˛edy pami˛eci operacyjnej
Bł˛edy pami˛eci mog ˛a by´c spowodowane bł˛edami komórek pami˛eci lub układów adresuj ˛acych. Przykładowe bł˛edy jednostek adresuj ˛acych to: wybór bł˛ednej komórki pami˛eci, nieudany wybór zadanej komórki pami˛eci, wybór jednej z komórek pami˛eci przez wi˛ecej ni˙z jeden adres, jednoczesny wybór kilku komórek pami˛eci przez jeden adres, a wynik jest funkcj ˛a warto´sci wybranych komórek.
Natomiast podstawowe modele bł˛edów komórek pami˛eci to (na podstawie [96]): bł˛edy skleje´n z 0/1 – komórka pami˛eci zawsze ma t˛e sam ˛a warto´s´c; bł ˛ad typu bit-flip – negacja warto´sci przechowywanej w komórce pami˛eci; bł ˛ad ulotno´sci – zapami˛etana informacja w komórce jest tracona na skutek pr ˛adów upływowych; bł˛edy tranzycji – niemo˙zno´s´c zmiany stanu z 1 na 0 lub z 0 na 1; bł˛edy sprz˛e˙ze´n – warto´s´c przechowywana w komórce lub jej zdolno´s´c do zmiany warto´sci jest zale˙zna od przechowywanych w innych komórkach.
Osobn ˛a kategori ˛a bł˛edów s ˛a bł˛edy charakterystyczne dla poszczególnych technologii wytwarzania pami˛eci (patrz [57]): opó´znienie czasu dost˛epu; opó´znienie wzmacniacza odczytu – na wyj´sciu pojawia si˛e stan poprzednich bitów; opó´znienie zapisu – po dokonaniu zapisu kolejna operacja jest dokonywana na tej samej komórce pami˛eci pomimo zmiany adresu; bł ˛ad niezrównowa˙zenia – bł˛edna kwalifikacja warto´sci odczytywanej komórki, je˙zeli wi˛ekszo´s´c komórek na tej samej linii adresowej ma stan odmienny od odczytywanej komórki.
Popularn ˛a metod ˛a wykrywania i ewentualnego zapobiegania bł˛edom pami˛eci w cyklu
˙zycia systemu jest stosowanie kodów korekcyjnych – s ˛a to pami˛eci ECC19 RAM (patrz [64]). Technika ta polega na rozszerzeniu pami˛eci o dodatkowe komórki, w których s ˛a przechowywane dodatkowe dane kodu korekcyjnego, pozwalaj ˛ace na poprawienie i wykrywanie bł˛edów. Liczba wykrywanych i poprawianych bł˛edów pami˛eci ró˙zni si˛e w zale˙zno´sci od zastosowanego kodu. Weryfikacja i ewentualna korekta zawarto´sci komórek pami˛eci odbywa si˛e przy odczycie. Niektóre implementacje tej techniki periodycznie skanuj ˛a cał ˛a przestrze´n adresow ˛a pami˛eci w celu wyeliminowania efektu kumulacji bł˛edów (tzw. error scrubbing).
19 Ang. Error-correcting code.
Pami˛eci ECC pozwalaj ˛a skutecznie zwi˛ekszy´c niezawodno´s´c systemów komputerowych – pozwalaj ˛a na korekcj˛e bł˛edów przemijaj ˛acych oraz wykrycie bł˛edów trwałych. W [94] przedstawiono szczegółowe badanie nad cz˛estotliwo´sci ˛a zgłaszania pojedynczych bł˛edów pami˛eci maskowanych przez ECC oraz podwójnych bł˛edów pami˛eci w ´srodowisku produkcyjnym. Bł˛edy podwójne powodowały eliminacj˛e modułu pami˛eci z dalszych bada´n i zast ˛apienie go nowym modułem. W ci ˛agu roku w 32,2% maszyn obj˛etych badaniem zaobserwowano przynajmniej jeden bł ˛ad pojedynczy (8,2% obj˛etych badaniem modułów pami˛eci) oraz w 1,29% maszyn wykryto bł ˛ad podwójny (0,22% modułów pami˛eci). Przy du˙zej liczbie maszyn produkcyjnych koszt wymiany wadliwych modułów pami˛eci stanowi istotny koszt utrzymania.
2.2.5. Bł˛edy urz ˛adze ´n zewn˛etrznych
Modele bł˛edów urz ˛adze´n zewn˛etrznych stanowi ˛a szerok ˛a dziedzin˛e bada´n, które s ˛a systematycznie pogł˛ebiane. Ka˙zde z urz ˛adze´n dysponuje swoim odr˛ebnym profilem najcz˛e´sciej zgłaszanych bł˛edów. Bł˛edy urz ˛adze´n zewn˛etrznych mog ˛a by´c zwi ˛azane zarówno z przekłamaniami danych lub nieprawidłowym zachowaniem przy komunikacji z systemem operacyjnym. Warto zaznaczy´c, ˙ze bł˛edy mog ˛a wyst ˛api´c zarówno w urz ˛adzeniu zewn˛etrznym, jak i kontrolerze stanowi ˛acym integraln ˛a cz˛e´s´c systemu komputerowego.
Przykładami zaburzania danych mog ˛a by´c przekłamania jak w przypadku bł˛edów pami˛eci (typu bit-flip lub skleje´n z 0/1). Natomiast bł˛edy behawioralne mog ˛a by´c modelowane jako niezgłaszane/nadmiarowe przerwania, zachowanie niezgodne z protokołem współpracy z urz ˛adzeniem (np. brak odpowiedzi na wysyłane komendy).
Bł˛edy danych w szczególno´sci dotycz ˛a urz ˛adze´n przechowywania danych oraz urz ˛adze´n komunikacyjnych. Urz ˛adzenia przechowywania danych to dyski twarde, pami˛eci USB, czy pami˛eci Compact Flash. Przykładowo dyski twarde wykorzystuj ˛a talerze z no´snikiem magnetycznym, na którym zapisywane s ˛a informacje. Urz ˛adzenia te zapisuj ˛a dane na no´sniku z zastosowaniem kodów korekcyjnych, pomimo to bł˛edy nienaprawialne wyst˛epuj ˛a. W badaniu opisanym w [106] w przeci ˛agu 12 miesi˛ecy 0,04% spo´sród 387 840 głowic dysków twardych natrafiło na bł˛edy nienaprawialne. W krytycznych zastosowaniach wykorzystuje si˛e macierze dyskowe typu RAID.
Bł˛edy danych w urz ˛adzeniach komunikacyjnych najcz˛e´sciej zwi ˛azane s ˛a z bł˛edami kanału przesyłu informacji. W przypadku sieci komputerowych du˙z ˛a rol˛e odgrywa zastosowany protokół komunikacji – UDP20 lub TCP21. Protokół UDP nie zakłada ˙zadnej kontroli spójno´sci danych, natomiast TCP posiada takie mechanizmy wbudowane. W Instytucie Informatyki Politechniki Warszawskiej prowadzono badania nad tymi mechanizmami i w [38]
20 Ang. User Datagram Protocol.
21 Ang. Transmission Control Protocol.
przedstawiono zale˙zno´s´c opó´znienia transmisji TCP od liczby bł˛edów w kanale transmisyjnym.
Warto zaznaczy´c, ˙ze pomimo zastosowania kodów korekcyjnych w TCP wci ˛a˙z istnieje mo˙zliwo´s´c przekłamania danych i prowadzone s ˛a badania nad popraw ˛a tego mechanizmu (patrz [60]).
Oprócz bł˛edów danych przechowywanych lub przesyłanych przez urz ˛adzenie mog ˛a wyst ˛api´c tak˙ze bł˛edy protokołu współpracy urz ˛adzenia z systemem operacyjnym. Bł˛edy te mog ˛a by´c modelowane jako nadmiarowe przerwania (patrz [8]), bł˛edy danych protokołu (np. bł˛edy w ramkach protokołu SATA22) lub w przypadku urz ˛adze´n korzystaj ˛acych z DMA zapisywanie danych pod inny adres ni˙z przeznaczony do wykorzystania przez urz ˛adzenie.
2.3. Mechanizmy zwi˛ekszania niezawodno´sci
Mechanizmy zwi˛ekszania niezawodno´sci spełniaj ˛a nast˛epuj ˛ace funkcje: detekcja, maskowanie oraz tolerowanie bł˛edów. Detekcja jest to wykrycie istnienia bł˛edu w systemie. Maskowanie jest to zdolno´s´c do usuni˛ecia efektu bł˛edu zanim b˛edzie miał on wpływ na działanie systemu. Natomiast tolerowanie bł˛edów jest to mechanizm umo˙zliwiaj ˛acy prawidłow ˛a prac˛e systemu pomimo wyst˛epowania bł˛edów. Mo˙zna wyró˙zni´c kilka podstawowych technik zwi˛ekszania niezawodno´sci: redundancja masowa, redundancja cz˛e´sciowa, redundancja informacji, asercje, mechanizmy typu watchdog, izolacja oraz mechanizmy typu checkpoint. Wymienione techniki mog ˛a realizowa´c jedn ˛a lub wi˛ecej funkcji niezawodno´sci. Techniki zwi˛ekszania niezawodno´sci mog ˛a by´c implementowane jako mechanizmy sprz˛etowe, programowe lub programowo-sprz˛etowe.
Redundancja masowa jest to technika polegaj ˛aca na wykorzystaniu wielu modułów w celu realizacji tego samego zadania lub wielokrotnym wykonaniu zadania przez jeden moduł, w przypadku zało˙zenia wyst˛epowania bł˛edów przemijaj ˛acych. Wyniki działania wszystkich modułów mog ˛a bra´c udział w głosowaniu (redundancja bierna) – opracowanych jest wiele algorytmów przeprowadzania głosowania (patrz [96]). Alternatywnym rozwi ˛azaniem jest zastosowanie detektora bł˛edów, który testuje wyniki działania modułów i w przypadku wykrycia bł˛edu dokonuje rekonfiguracji układu np. poprzez wył ˛aczenie zasilania wadliwych modułów (redundancja aktywna). Przykładem redundancji masowej realizowanej w oprogramowaniu jest N-version programming (patrz [88]). Opis bada´n maj ˛acych na celu zastosowania tego typu rozwi ˛aza´n w systemach operacyjnych mo˙zna znale´z´c w [79, 111].
Istotn ˛a wad ˛a rozwi ˛aza´n tego typu jest du˙zy narzut na koszty tworzenia tego typu rozwi ˛aza´n.
Redundancja cz˛e´sciowa ró˙zni si˛e od redundancji masowej ograniczonym zakresem replikacji tylko do cz˛e´sci zasobów – przykładowo jest to zastosowanie w systemie komputerowym macierzy dyskowych RAID lub wyposa˙zenie dysków twardych w zapasowe
22 Ang. Serial Advanced Technology Attachment.
