Minix 3 - Minix 3

Minix 3
Rocky Raccoon maskotka MINIX 3.jpg
Minix 3.png
Minix 3 z systemem X11 z twm jako menedżerem okien
Deweloper Andrew S. Tanenbaum i in.
Napisane w C , język asemblera
Rodzina systemów operacyjnych Uniksopodobny
Stan pracy Opuszczony
Model źródłowy Otwarte źródło
Pierwsze wydanie 24 października 2005 r .; 15 lat temu ( 2005-10-24 )
Magazyn
Cel marketingowy Systemy wbudowane , edukacja
Dostępne w język angielski
Platformy IA-32 , RAMIĘ
Typ jądra Mikrojądro
Kraina użytkownika MINIX, NetBSD
Domyślny
interfejs użytkownika
popiół
Licencja 2005: BSD-3-klauzula
Oryginał: BSD-3-klauzula
Poprzedzony Minix 1.0, 1.5 i 2.0
Oficjalna strona internetowa www .minix3 .org

Minix 3 to projekt mający na celu stworzenie małego, wysokiej dostępności , wysoce funkcjonalnego systemu operacyjnego podobnego do Uniksa . Jest opublikowany na licencji BSD-3-Clause i jest następcą wcześniejszych wersji, Minix 1 i 2.

Głównym celem projektu jest zapewnienie odporności systemu na awarie dzięki wykrywaniu i naprawianiu własnych usterek w locie, bez interwencji użytkownika. Przewiduje się, że głównymi zastosowaniami systemu będą systemy wbudowane i edukacja.

Od 2017 r. MINIX 3 obsługuje procesory architektury IA-32 i ARM . Może również działać na emulatorach lub maszynach wirtualnych , takich jak Bochs , VMware Workstation , Microsoft Virtual PC , Oracle VirtualBox i QEMU . Trwa opracowywanie portu na architekturę PowerPC .

Dystrybucja jest dostępna na żywej płycie CD i można ją pobrać jako obraz z pamięci USB na żywo . Najnowsza wersja to „minix_R3.4.0rc6-d5e4fc0.iso.bz2” (9 maja 2017 r.).

Uważa się, że MINIX 3 jest używany w Intel Management Engine (ME) znajdującym się w Intel Platform Controller Hub, począwszy od wprowadzenia ME 11, który jest używany z procesorami Skylake i Kaby Lake .

Jego zastosowanie w Intel ME może sprawić, że będzie to najczęściej używany system operacyjny na procesorach x86 / AMD64 począwszy od 2015 roku, z większą liczbą instalacji niż Microsoft Windows, Linux lub macOS.

Cele projektu

Struktura odpowiednio monolitycznego jądra i mikrojądra systemów operacyjnych

Zastanawiając się nad naturą systemów opartych na monolitycznym jądrze , w których sterownik (który, według Tanenbauma , twórcy MINIX-a , zawiera około 3–7 razy więcej błędów niż zwykły program) może zniszczyć cały system, MINIX 3 ma na celu stworzenie działającego system, który jest "niezawodnym, samonaprawiającym się, wieloserwerowym klonem Uniksa".

Aby to osiągnąć, kod uruchomiony w jądrze musi być minimalny, z serwerem plików, serwerem procesów i każdym sterownikiem urządzenia działającymi jako oddzielne procesy trybu użytkownika. Każdy sterownik jest dokładnie monitorowany przez część systemu o nazwie serwer reinkarnacji . Jeśli sterownik nie odpowie na pingi z tego serwera, zostanie on zamknięty i zastąpiony nową kopią sterownika.

W systemie monolitycznym błąd w sterowniku może łatwo spowodować awarię całego jądra. Jest to znacznie mniej prawdopodobne w MINIX 3.

Historia

MINIX 3 wersje
Wersja Data wydania Opis
3.1.0
( OSDI3 )
2005-10-18
3.1.1
(SOSP)
2005-10-24
3.1.2 2006-04-18
3.1.2a 2006-05-29
  • Nowy menedżer pakietów Packman.
  • Naprawiono problem z instalacją związany z automatycznym partycjonowaniem dysków.
3.1.3 2007-04-13
3.1.3a 2007-06-08
  • Poprawki błędów.
3.1.4 2009-06-09
3.1.5 2009-11-05
  • Poprawa wydajności
  • Pamięć współdzielona
  • funkcja settimer
  • System plików ISO 9660
  • Otwarty system dźwiękowy
  • Pułapka ma teraz dostęp do NULL, dla wygody użytkownika
  • Ulepszona obsługa sygnału
  • Lepsze wsparcie dla debuggerów ( ulepszenia ptrace itp.)
  • Automatyczne wykrywanie karty sieciowej (dla obsługiwanych kart PCI ), ulepszona konfiguracja sieci
3.1.6 2010-02-08
3.1.7 2010-06-16
  • Planowanie w przestrzeni użytkownika i serwer planowania
  • Właściwa obsługa wielu kart Ethernet tego samego typu
  • Monitor rozruchowy umożliwia ładowanie obrazów > 16 MB
  • Wsparcie Buildsystem do budowania MINIX z GCC
  • Wsparcie dla Windows-1251 i KOI8-U charsets
3.1.8 2010-10-04
3.2.0 2012-02-29
3.2.1 2013-02-21
3.3.0 2014-09-15
  • obsługa architektury ARM; kompilacja krzyżowa
  • Wsparcie dla mmap()mechanizmu I/O; pozwala na współdzielone biblioteki dynamiczne i mniejsze zapotrzebowanie na pamięć
  • Nowa infrastruktura wejściowa: serwer wejściowy i sterownik klawiatury oddzielone od TTY
  • VND: sterownik bloku dysku (pętla zwrotna) vnode
  • Kompilacja kodu bitowego LLVM systemu
  • Import LLVM i klangu w źródłach
  • Ujednolicona pamięć podręczna bloków współdzielona przez FS i VM
  • Poprawiona kompatybilność NetBSD: narzędzia, wywołania, typy (wiele 64-bitów), toolchain, codebase i pakiety
  • Typ C dla wiadomości: czystszy, większy
  • Poprawiona modułowość sterownika: UDS oddzielone od PFS, PTY od TTY, jeden kontroler na instancję at_wini, LOG usunięty z obrazu rozruchowego
  • Pakiety są teraz dynamicznie połączone
3.4.0 rc6 2017-05-09 ?
  •   Wydanie książki
  •   Stare wydanie
  •   Aktualna stabilna wersja
  •   Aktualna wersja rozwojowa

MINIX 3 został publicznie ogłoszony 24 października 2005 r. przez Andrew Tanenbauma podczas jego przemówienia na szczycie konferencji Association for Computing Machinery (ACM) Operating Systems Principles. Chociaż nadal służy jako przykład dla nowej edycji podręcznika Tanenbauma i Woodhulla, został gruntownie przeprojektowany, aby „nadał się do użytku jako poważny system na komputerach o ograniczonych zasobach i wbudowanych oraz do zastosowań wymagających wysokiej niezawodności”.

Początkowo wydany na tej samej licencji BSD-3-Clause, na której MINIX był licencjonowany od 2000 roku. Pod koniec 2005 roku zmieniono właściciela praw autorskich i dodano czwartą klauzulę.

Polityka niezawodności

Jednym z głównych celów MINIX 3 jest niezawodność. Poniżej omówiono niektóre z ważniejszych zasad, które zwiększają jego niezawodność.

Zmniejsz rozmiar jądra

Monolityczne systemy operacyjne, takie jak Linux i FreeBSD oraz hybrydy, takie jak Windows, mają miliony wierszy kodu jądra . W przeciwieństwie do tego, MINIX 3 ma około 6000 wierszy kodu wykonywalnego jądra, co może ułatwić znalezienie problemów w kodzie.

Klatkaj robaki

W jądrach monolitycznych sterowniki urządzeń znajdują się w jądrze. Tak więc, gdy instalowane jest nowe urządzenie peryferyjne, do jądra wstawiany jest nieznany, niezaufany kod. Jeden zły wiersz kodu w sterowniku może spowodować awarię systemu.

Zamiast tego w MINIX 3 każdy sterownik urządzenia jest oddzielnym procesem w trybie użytkownika. Sterowniki nie mogą wykonywać instrukcji uprzywilejowanych, zmieniać tabel stron , wykonywać arbitralnych operacji wejścia/wyjścia (I/O) ani zapisywać w pamięci bezwzględnej. Muszą wykonywać wywołania jądra dla tych usług, a jądro sprawdza każde wywołanie pod kątem uprawnień.

Ogranicz dostęp do pamięci sterowników

W jądrach monolitycznych sterownik może zapisywać w dowolnym słowie pamięci, a tym samym przypadkowo uszkadzać programy użytkownika.

W MINIX 3, gdy użytkownik oczekuje danych na przykład z systemu plików, buduje deskryptor informujący, kto ma dostęp i pod jakimi adresami. Następnie przekazuje indeks do tego deskryptora do systemu plików, który może przekazać go do sterownika. System plików lub sterownik prosi następnie jądro o zapis poprzez deskryptor, uniemożliwiając im zapis do adresów spoza bufora.

Przetrwaj złe wskaźniki

Wyłuskanie błędnego wskaźnika w sterowniku spowoduje awarię procesu sterownika, ale nie będzie miało wpływu na system jako całość. Serwer reinkarnacji automatycznie zrestartuje uszkodzony sterownik. Użytkownicy nie zauważą odzyskiwania niektórych sterowników (np. dysku i sieci), ale dla innych (np. audio i drukarki) mogą. W jądrach monolitycznych wyłuskanie błędnego wskaźnika w sterowniku zwykle prowadzi do awarii systemu.

Oswajaj nieskończone pętle

Jeśli kierowca wpadnie w nieskończoną pętlę , planista będzie stopniowo obniżał swój priorytet, aż stanie się bezczynny. W końcu serwer reinkarnacji zobaczy, że nie odpowiada na żądania statusu, więc zabije i zrestartuje zapętlony sterownik. W jądrze monolitycznym zapętlony sterownik może zawiesić system.

Ogranicz obrażenia od przepełnienia bufora

MINIX 3 wykorzystuje wiadomości o stałej długości do komunikacji wewnętrznej, co eliminuje pewne przepełnienia buforów i problemy z zarządzaniem buforami. Ponadto wiele exploitów działa poprzez przepełnienie bufora, aby skłonić program do powrotu z wywołania funkcji przy użyciu nadpisanego adresu zwrotnego stosu wskazującego na pamięć kontrolowaną przez atakującego, zwykle bufor przepełnienia. W MINIX 3 ten atak jest łagodzony, ponieważ przestrzeń instrukcji i danych jest rozdzielona i tylko kod w przestrzeni instrukcji (tylko do odczytu) może być wykonywany, co określa się mianem ochrony wykonywalnej przestrzeni . Jednak ataki, które polegają na uruchamianiu legalnie wykonywalnej pamięci w złośliwy sposób ( return-to-libc , programowanie zorientowane na powrót ) nie są powstrzymywane przez to ograniczenie.

Ogranicz dostęp do funkcji jądra

Sterowniki urządzeń uzyskują usługi jądra (takie jak kopiowanie danych do przestrzeni adresowych użytkowników), wykonując wywołania jądra. Jądro MINIX 3 ma mapę bitową dla każdego sterownika, określającą, do których wywołań jest upoważniony. W jądrach monolitycznych każdy sterownik może wywołać każdą funkcję jądra, autoryzowaną lub nie.

Ogranicz dostęp do portów I/O

Jądro utrzymuje również tabelę informującą, do których portów I/O może mieć dostęp każdy sterownik. W ten sposób sterownik może dotykać tylko własnych portów I/O. W jądrach monolitycznych błędny sterownik może uzyskać dostęp do portów we/wy należących do innego urządzenia.

Ogranicz komunikację z komponentami systemu operacyjnego

Nie każdy sterownik i serwer musi komunikować się z każdym innym sterownikiem i serwerem. Odpowiednio, mapa bitowa na proces określa, do których miejsc docelowych każdy proces może wysłać.

Reinkarnować martwych lub chorych kierowców

Specjalny proces, zwany serwerem reinkarnacji, okresowo pinguje każdy sterownik urządzenia. Jeśli sterownik umrze lub nie zareaguje poprawnie na pingi, serwer reinkarnacji automatycznie zastąpi go nową kopią. Wykrywanie i zastępowanie niedziałających sterowników odbywa się automatycznie, bez konieczności podejmowania działań przez użytkownika. Ta funkcja nie działa obecnie w przypadku sterowników dysków, ale w następnej wersji system będzie w stanie odzyskać nawet sterowniki dysków, które będą ukryte w pamięci o dostępie swobodnym (RAM). Odzyskiwanie sterowników nie wpływa na uruchomione procesy.

Zintegruj przerwania i wiadomości

Gdy wystąpi przerwanie , jest ono konwertowane na niskim poziomie do powiadomienia wysyłanego do odpowiedniego sterownika. Jeśli sterownik czeka na wiadomość, natychmiast otrzymuje przerwanie; w przeciwnym razie otrzyma powiadomienie następnym razem, gdy RECEIVEotrzyma wiadomość. Ten schemat eliminuje zagnieżdżone przerwania i ułatwia programowanie sterowników.

Architektura

Architektura MINIX 3

Jak widać, na najniższym poziomie znajduje się mikrojądro , które zawiera około 4000 linii kodu (głównie w C , plus niewielka ilość języka asemblera ). Obsługuje przerwania , planowanie i przekazywanie komunikatów. Obsługuje również interfejs programowania aplikacji (API) około 30 wywołań jądra, które mogą wykonywać autoryzowane serwery i sterowniki. Programy użytkownika nie mogą wykonywać tych połączeń. Zamiast tego mogą wydawać wywołania systemowe POSIX , które wysyłają komunikaty do serwerów. Wywołania jądra wykonują takie funkcje, jak ustawianie przerwań i kopiowanie danych między przestrzeniami adresowymi.

Na wyższym poziomie znajdują się sterowniki urządzeń , z których każdy działa jako osobny proces w przestrzeni użytkownika . Każdy z nich steruje jakimś urządzeniem we/wy, takim jak dysk lub drukarka. Sterowniki nie mają dostępu do przestrzeni portów I/O i nie mogą bezpośrednio wydawać instrukcji I/O. Zamiast tego muszą wykonać wywołania jądra, podając listę portów I/O do zapisu i wartości do zapisania. Chociaż wiąże się to z niewielkim narzutem (zwykle 500 ns), ten schemat umożliwia jądru sprawdzenie autoryzacji, tak że na przykład sterownik audio nie może zapisywać na dysku.

Na kolejnym poziomie znajdują się serwery . To tutaj znajduje się prawie cała funkcjonalność systemu operacyjnego. Procesy użytkownika uzyskują usługę plików, na przykład przez wysyłanie komunikatów do serwera plików w celu otwierania, zamykania, odczytywania i zapisywania plików. Z kolei serwer plików wykonuje operacje wejścia/wyjścia dysku, wysyłając komunikaty do sterownika dysku, który kontroluje dysk.

Jednym z kluczowych serwerów jest serwer reinkarnacji. Jego zadaniem jest odpytywanie wszystkich innych serwerów i sterowników w celu okresowego sprawdzania ich kondycji. Jeśli składnik nie odpowiada poprawnie, kończy działanie lub wchodzi w nieskończoną pętlę , serwer reinkarnacji (który jest procesem nadrzędnym sterowników i serwerów) zabija wadliwy składnik i zastępuje go świeżą kopią. W ten sposób system jest automatycznie naprawiany bez ingerencji w uruchomione programy.

Obecnie serwer reinkarnacji, serwer procesów i mikrojądro są częścią zaufanej bazy obliczeniowej . Jeśli któryś z nich zawiedzie, system ulegnie awarii. Niemniej jednak zmniejszenie zaufanej bazy obliczeniowej z 3-5 milionów wierszy kodu, jak w systemach Linux i Windows, do około 20 000 wierszy, znacznie zwiększa niezawodność systemu.

Różnice między MINIX 3 a wcześniejszymi wersjami

Schemat relacji między kilkoma systemami uniksopodobnymi

MINIX 1.0, 1.5 i 2.0 zostały opracowane jako narzędzia ułatwiające ludziom poznanie projektowania systemów operacyjnych.

MINIX 1.0, wydany w 1987 roku, zawierał 12 000 linii C i trochę języka asemblera x86 . Kod źródłowy jądra, menedżera pamięci i systemu plików MINIX 1.0 są wydrukowane w książce. Tanenbaum pierwotnie opracował MINIX dla kompatybilności z dostępnymi w tamtym czasie mikrokomputerami IBM PC i IBM PC/AT .

MINIX 1.5, wydany w 1991 roku, zawierał obsługę systemów MicroChannel IBM PS/2 , a także został przeniesiony na architektury Motorola 68000 i SPARC , obsługując platformy komputerowe Atari ST , Commodore Amiga , Apple Macintosh i Sun Microsystems SPARCstation . Dostępna była również wersja MINIX działająca jako proces użytkownika pod SunOS .

MINIX 2.0, wydany w 1997 roku, był dostępny tylko dla architektur SPARC hostowanych przez x86 i Solaris . Minix-vmd został stworzony przez dwóch badaczy z Vrije Universiteit i dodał pamięć wirtualną oraz obsługę systemu X Window .

MINIX 3 robi to samo i zapewnia nowoczesny system operacyjny z wieloma nowszymi narzędziami i wieloma aplikacjami uniksowymi . Prof. Tanenbaum powiedział kiedyś:

Należy pamiętać, że MINIX 3 nie jest MINIXem twojego dziadka... MINIX 1 został napisany jako narzędzie edukacyjne... MINIX 3 jest to plus początek budowania wysoce niezawodnego, samonaprawiającego się, wolnego od wzdęć systemu operacyjnego... MINIX 1 i MINIX 3 są powiązane w taki sam sposób, jak Windows 3.1 i Windows XP są: to samo imię.

Od czasu wydania MINIX 2 wprowadzono również wiele ulepszeń w strukturze jądra, dzięki czemu system jest bardziej niezawodny. MINIX wersja 3.1.5 została wydana 5 lis 2009. Zawiera on X11 , Emacs , vi , cc, GCC , Perl , Python , Almquist shell , Bash , skorupa Z , klient FTP , SSH , Telnet klient, Sosna , a ponad 400 innych popularne programy użytkowe systemu Unix. Wraz z dodaniem X11, ta wersja oznacza odejście od systemu tekstowego. Inną cechą tej wersji, która zostanie ulepszona w przyszłych, jest zdolność systemu do wytrzymania awarii sterowników urządzeń, aw wielu przypadkach ich automatycznej wymiany bez wpływu na działające procesy. W ten sposób MINIX naprawia się samoczynnie i może być używany w aplikacjach wymagających wysokiej niezawodności.

MINIX 3.2.0 został wydany w lutym 2012. Ta wersja ma wiele nowych funkcji, w tym kompilator Clang , eksperymentalną obsługę symetrycznego przetwarzania wieloprocesowego, obsługę systemów plików procfs i ext2fs oraz GNU Debugger (GDB). Kilka części NetBSD jest również zintegrowanych z wydaniem, w tym bootloader, libc oraz różne narzędzia i inne biblioteki .

MINIX 3.3.0 został wydany we wrześniu 2014. To wydanie jest pierwszą wersją obsługującą architekturę ARM oprócz x86. Obsługuje również przestrzeń użytkownika NetBSD , z tysiącami pakietów NetBSD uruchomionych od razu po wyjęciu z pudełka.

Maskotka

Rocky Raccoon, maskotka MINIX 3.

Rocky Raccoon to maskotka MINIX 3.

MINIXCon

MINIXCon to konferencja poświęcona dzieleniu się rozmowami, wysiłkami i badaniami związanymi z MINIX.

Odbyło się raz w 2016 roku. MINIXCon2017 został odwołany z powodu braku zgłoszonych rozmów.

Zobacz też

Uwagi

Bibliografia

Dalsza lektura

Zewnętrzne linki