Ćwiczenie 2 3. Tryb chroniony

Transkrypt

1 Tryb chroniony Cel: Zapoznanie się z organizacją funkcjonowania systemu komputerowego w trybie chronionym procesora, a takŝe z zasadami programowania 32-bitowego. Zadanie: Napisać program, który będzie przełączać procesor w tryb chroniony, następnie wyświetlać na ekranie napis poprzez bezpośredni zapis do segmentu obejmującego pamięć obrazu i powracać do trybu rzeczywistego. W trybie chronionym program ma korzystać z 32-bitowych segmentów. 1. Tryb rzeczywisty a tryb chroniony Procesory 8086 i 8088 firmy Intel, od których to rozpoczęła się era dynamicznego rozwoju komputerów osobistych, zostały zaprojektowane i skonstruowane w ten sposób, iŝ realizacja podejmowanych przez nie operacji odbywała się w tzw. trybie adresowania rzeczywistego (ang. Real Address Mode), nazywanym równieŝ skrótowo trybem rzeczywistym (ang. Real Mode). Tryb ten zapewniał podstawowe mechanizmy komunikowania się z pamięcią operacyjną i układami wejścia-wyjścia, umoŝliwiając wykonywanie programu uŝytkownika pod kontrolą systemu operacyjnego. Niestety, nie przewidywał on Ŝadnej wspomaganej sprzętowo moŝliwości ochrony zasobów, nie dawał teŝ Ŝadnego sprzętowego wsparcia pozwalającego na równoczesne działanie wielu programów. Intensywny rozrost obszaru zastosowań komputerów osobistych oraz wykorzystanie ich potencjału w coraz to nowych dziedzinach wkrótce unaoczniły, jak powaŝny charakter miały oba te ograniczenia. Po pierwsze, moŝliwość wykonywania naraz tylko jednego programu okazała się zdecydowanie niewystarczająca. Wobec tego podjęto próby programowego ominięcia tego ograniczenia. I tak dla przykładu, w systemie operacyjnym MS-DOS, który funkcjonował w oparciu o tryb rzeczywisty, powstała koncepcja tzw. programów rezydentnych. Cechowały się one tym, iŝ zwykle po uruchomieniu przechodziły w stan uśpienia, ale w pewnych określonych warunkach ich wykonywanie mogło znów zostać podjęte, i to niezaleŝnie od tego, czy w tym czasie pracował juŝ inny uruchomiony program, czy nie. JednakŜe programy takie charakteryzowały się licznymi wadami wypływającymi z samej ich idei, wymagały nie tylko stosowania specyficznej konstrukcji spełniającej szereg dodatkowych ograniczeń, ale równieŝ napisania sporo dodatkowego kodu w celu zabezpieczenia przed załamaniem, co w efekcie sprawiało, Ŝe były one bardzo niewygodne do tworzenia. Po drugie, w rezultacie braku jakichkolwiek sprzętowych mechanizmów ochrony zasobów dowolny działający program miał dostęp do wszystkich tych zasobów, mógł więc sprawować całkowity nadzór nad systemem komputerowym, nawet jeśli nie posiadał do tego naleŝytych uprawnień. Wykorzystując zatem brak zabezpieczeń, mógł dla przykładu bez ograniczeń ingerować w dane systemu operacyjnego lub uśpionych programów rezydentnych, a w krańcowej sytuacji doprowadzić nawet do załamania się całego systemu. Rosnąca powszechność stosowania komputerów osobistych wymusiła wprowadzenie koniecznych zmian. Dzięki temu współczesne, nowoczesne systemy operacyjne charakteryzują się zarówno wielodostępnością, czyli umoŝliwiają pracę wielu uŝytkownikom Instytut Informatyki, PŁ str. 1

2 jednocześnie, jak i wielozadaniowością, a więc pozwalają na jednoczesne bezpieczne wykonywanie się wielu programów. Wymaga to jednak zastosowania odpowiedniego podejścia w zakresie zarządzania jednocześnie działającymi programami, jak i zapewnienia odpowiedniego poziomu ochrony zasobów, tak aby Ŝaden z programów nie mógł zakłócać pracy innego, czy nawet samego systemu operacyjnego, a takŝe by niemoŝliwe było doprowadzenie przezeń do załamania systemu. W efekcie wymusiło to wprowadzenie po pierwsze mechanizmów gwarantujących istnienie naleŝytej kontroli działania poszczególnych programów, a po drugie większego odseparowania wszystkich uruchomionych programów od siebie. Do zrealizowania tego celu konieczne okazało się zdefiniowanie nowego pojęcia zadania. Zadanie, zwane takŝe procesem, jest to odrębny program będący w trakcie wykonywania, który korzysta ze wspólnych z innymi działającymi programami zasobów systemu, lecz wykonywany jest od tych programów zupełnie niezaleŝnie, lub teŝ jego powiązania z tymi programami są ściśle kontrolowane. Układy sprzętowe wspomagające realizację wielozadaniowości oraz ochrony zasobów pojawiły się w następcy procesorów 8086 i 8088, a mianowicie w procesorze 80286, oznaczanym skrótowo symbolem 286. Procesor ten mógł działać w dwóch róŝnych trybach: znanym ze swoich poprzedników trybie adresowania rzeczywistego, oraz w drugim, nowym tzw. trybie adresowania wirtualnego z ochroną (ang. Protected Virtual Address Mode), zwanym takŝe w skrócie trybem chronionym (ang. Protected Mode). Pierwszy z nich był w pełni zgodny z pierwotnym trybem pracy procesorów 8086 i 8088, i stanowił jedynie jego niewielkie rozszerzenie. Zastosowanie zmodyfikowanej architektury wewnątrzprocesorowej oraz lepszych technologii wytwarzania sprawiło, iŝ jednostki 286 działały w nim jako szybsze wersje swoich poprzedników. Drugi z tych trybów stanowił jakościowo zupełnie inne rozwiązanie. Wprowadzał on sprzętowe mechanizmy ochrony zasobów, jak równieŝ sprzętowe wsparcie dla wielozadaniowości, a takŝe pamięć wirtualną opartą o segmentację. W następcy procesora 286, mianowicie procesorze 80386, oznaczanym skrótowo symbolem 386, dokonano w porównaniu z poprzednikiem wielu zmian, zarówno w zakresie architektury samej jednostki, jak i jej moŝliwości. Modyfikacje te objęły takŝe tryb chroniony, którego sprzętowe mechanizmy uległy dalszej znaczącej rozbudowie, a ponadto wzbogacone zostały jego moŝliwości w zakresie zarządzania pamięcią. Wprowadzono mechanizm stronicowania, o który oparte zostało działanie pamięci wirtualnej, jak i sprzęg z bardzo szybkimi układami pamięci podręcznej, montowanej poza procesorem. Procesor 386 został wyposaŝony w 32-bitowe rejestry oraz 32-bitowe magistrale stając się pierwszym przedstawicielem rodziny 32-bitowych procesorów firmy Intel. Rodzina ta, określana wspólną nazwą IA-32 (ang. Intel Architecture-32), obejmuje, obok owego procesora 386, takŝe późniejsze jednostki 486 oraz kolejne wersje procesorów Pentium. Zastosowana w nich architektura pozwala na programowanie 32-bitowe, a wiec operowanie 32-bitowymi danymi i 32-bitowymi przesunięciami. Od czasów procesora 386 modyfikacje w zakresie zasad funkcjonowania trybu chronionego jak i układów sprzętowych stanowiących jego podstawę, a takŝe w zakresie programowania 32-bitowego, w kolejnych procesorach z rodziny IA-32 są nieznaczne. 2. Budowa procesora Procesor 386 zawiera następujące rejestry dostępne dla programisty, pogrupowane na poniŝsze kategorie: 1. Rejestry uŝytkowe (ang. User Registers), które obejmują: 8 rejestrów ogólnego przeznaczenia (ang. General-Purpose Registers), 6 rejestrów segmentowych (ang. Segment Registers), Instytut Informatyki, PŁ str. 2

3 2 rejestry stanu (ang. Status Registers). 2. Rejestry systemowe (ang. System Registers), które obejmują: 3 rejestry sterujące (ang. Control Registers), 6 rejestrów uruchomieniowych (ang. Debug Registers), 2 rejestry testowe (ang. Test Registers), 4 rejestry trybu chronionego (ang. Protected Mode Registers). REJESTRY OGÓLNEGO PRZEZNACZENIA Procesor 386 posiada osiem 32-bitowych rejestrów ogólnego przeznaczenia. Są to rejestry: EAX, EBX, ECX, EDX, ESI, EDI, EBP, ESP. KaŜdy z nich ma wyodrębnioną młodszą 16-bitową część, do której moŝna się odwoływać, uŝywając nazwy odpowiedniego 16-bitowego rejestru występującego we wcześniejszych procesorach, np. rejestr EAX zawiera na swoich 16 najmłodszych bitach rejestr AX, EBX BX itd. Z kolei owa młodsza 16-bitowa część dzieli się dalej na dwa 8-bitowe rejestry, starszy i młodszy, które równieŝ posiadają swoje nazwy, np. w rejestrze AX są to odpowiednio AH i AL, w rejestrze BX BH i BL itd. Przeznaczenie poszczególnych rejestrów 32-bitowych jest zasadniczo takie same jak ich 16-bitowych odpowiedników z wcześniejszych procesorów. REJESTRY SEGMENTOWE Procesor 386 posiada sześć 16-bitowych rejestrów segmentowych. Pierwszy z nich, rejestr CS, słuŝy do wskazywania na aktualnie przetwarzany segment kodu. Rejestry DS, ES, FS i GS słuŝą do wskazywania na segmenty danych. Spośród nich rejestr DS stosowany jest przez większość instrukcji dostępu do danych jako rejestr domyślny, toteŝ uŝycie w konkretnym rozkazie innego wymaga jego jawnego określenia, tzw. prefiksowania. Odwoływanie się do pamięci przy wykorzystaniu innego rejestru segmentowego niŝ domyślny pociąga za sobą wydłuŝenie czasu obliczenia adresu, wobec tego rejestr DS powinien wskazywać na ten segment danych, do którego występuje najwięcej odwołań. Ostatni z rejestrów segmentowych, rejestr SS, słuŝy do wskazywania na segment stosu. REJESTRY STANU Do rejestrów stanu zaliczane są: wskaźnik instrukcji oraz rejestr znaczników. Wskaźnik instrukcji EIP jest rejestrem 32-bitowym, a jego młodsza 16-bitowa część to rejestr IP. Podobnie rejestr znaczników EFLAGS jest 32-bitowy, a na swoich najmłodszych 16 bitach zawiera rejestr FLAGS. REJESTRY STERUJĄCE Procesor 386 posiada trzy 32-bitowe rejestry sterujące, oznaczane jako CR0, CR2, CR3. SłuŜą one do sterowania trybem pracy procesora i trybem pracy bloku stronicowania. REJESTRY URUCHOMIENIOWE Procesor 386 posiada sześć 32-bitowych rejestrów uruchomieniowych, o symbolach DR0, DR1, DR2, DR3, DR6, DR7. Pozwalają one na sterowanie pułapkami sprzętowymi i pracą krokową, co umoŝliwia śledzenie wykonywania się programów w trybie chronionym. Tryb ten wymaga bowiem stosowania specjalnych debuggerów, a rejestry te stanowią sprzętowe wsparcie dla ich funkcjonowania, bez którego nie mogłyby one działać. REJESTRY TESTOWE Procesor 386 posiada dwa 32-bitowe rejestry testowe, oznaczane TR6 i TR7. UŜywa ich mechanizm sterujący funkcjonowaniem stronicowania, a takŝe wykorzystywane są w czasie autotestowania procesora. REJESTRY TRYBU CHRONIONEGO Procesor 386 posiada cztery rejestry trybu chronionego. Dwa z nich, GDTR i IDTR, są 32-bitowe, podczas gdy pozostałe dwa LDTR i TR 16-bitowe. Rejestry te pełnią zasadniczą rolę w funkcjonowaniu mechanizmów ochronnych trybu chronionego. Instytut Informatyki, PŁ str. 3

4 3. Organizacja pamięci operacyjnej Odwołując się do pamięci, procesor umieszcza na swoich wyprowadzeniach adresowych, połączonych z zewnętrzną szyną adresową, adres odpowiedniej komórki. Jest to tzw. adres fizyczny, jako Ŝe określa on faktyczne połoŝenie tej komórki w pamięci. Zewnętrzna szyna adresowa w procesorze 8086 zawierała 20 linii, dzięki czemu był on zdolny do zaadresowania 1 MB pamięci. Zewnętrzna szyna adresowa procesora 286 zawierała juŝ 24 linie, zaś procesora linie. Wynika zatem z tego, iŝ procesory 286 były w stanie zaadresować 16 MB pamięci, natomiast procesory 386 aŝ 4 GB. Niestety, w trybie rzeczywistym, ani w pierwszym, ani w drugim przypadku niemoŝliwe jest wykorzystanie całego tego potencjalnie dostępnego obszaru. W tym trybie bowiem mechanizm adresowania musi pozostać zgodny ze swoim odpowiednikiem z procesora 8086, a zatem ogranicza się jedynie do 1 MB pamięci. Z kolei tryb chroniony nie podlega juŝ takim ograniczeniom i cała dostępna pamięć moŝe być bez przeszkód wykorzystywana. Zastosowana w procesorze 8086 i wszystkich jego następcach organizacja pamięci logicznej nazywana jest segmentacją. Oznacza to, Ŝe dostęp do konkretnej komórki w pamięci odbywa się poprzez odwołanie do odpowiedniego segmentu, stanowiącego pewien wyodrębniony i skończony obszar pamięci, i podanie przesunięcia w tym segmencie, a więc odległości tejŝe komórki pamięci od początku segmentu. Tak wyspecyfikowany adres logiczny zostaje następnie przetłumaczony przez procesor w procesie zwanym translacją na adres fizyczny. W trybie rzeczywistym segment charakteryzowany jest przez dwie wielkości: adres swojego początku oraz swój rozmiar, czyli długość. Jeśli chodzi o pierwszą z tych cech, musi ona spełniać jedną podstawową regułę, a mianowicie początek segmentu nie moŝe znajdować się w dowolnym miejscu pamięci, lecz musi leŝeć na granicy tzw. paragrafu, którego odpowiadający mu 16-bitowy numer paragrafu jest zapamiętywany w rejestrze segmentowym. Z kolei długość segmentu, a więc druga cecha go opisująca, moŝe stanowić wartość nie przekraczającą Wynika z tego, Ŝe maksymalne przemieszczenie w obrębie segmentu o największym dostępnym rozmiarze równieŝ moŝe zostać zapisane jako liczba 16-bitowa. Adres fizyczny uzyskuje się mnoŝąc numer paragrafu znajdujący się w rejestrze segmentowym przez 16 (efektywnie: przesuwając go o 4 miejsca w lewo) i dodając do otrzymanego iloczynu przesunięcie. NaleŜy przy tym podkreślić, Ŝe tryb rzeczywisty nie zapewnia Ŝadnej ochrony pamięci, toteŝ nie przeprowadza się jakiejkolwiek kontroli uzyskanej w wyniku translacji wartości. Jeśli długość segmentu jest krótsza niŝ podane przesunięcie, adres fizyczny, mimo Ŝe w istocie leŝący juŝ poza danym segmentem, zostanie zgodnie z powyŝszą procedurą wyznaczony, a dostęp do pamięci zrealizowany. W trybie chronionym równieŝ obowiązuje segmentacja, toteŝ aby odwołać się do określonej komórki w pamięci, trzeba znać, analogicznie jak w trybie rzeczywistym, adres początku segmentu, w którym się ona mieści, oraz przemieszczenie w obrębie tegoŝ segmentu, pod którym faktycznie się ona znajduje. Wprowadzenie po raz pierwszy w procesorze 386 mechanizmu stronicowania sprawiło, Ŝe adres powstający w wyniku złoŝenia adresu segmentu i przemieszczenia niekoniecznie musi stanowić adres fizyczny. Wobec tego, dla odróŝnienia, został on nazwany adresem liniowym. Z kolei adres fizyczny moŝe zostać wyznaczony dopiero po określeniu owego adresu liniowego. Ten etap translacji dokonywany jest przez specjalne mechanizmy sprzętowe odpowiedzialne za realizację stronicowania. W przypadku jednak, gdy mechanizm stronicowania jest wyłączony, adres fizyczny jest taki sam jak liniowy i Ŝadna dodatkowa konwersja nie zachodzi. NaleŜy przy tym zaznaczyć, Ŝe w procesorze 386, jako Ŝe dysponuje on 32 liniami adresowymi, oba adresy liniowy i fizyczny są 32-bitowe. Instytut Informatyki, PŁ str. 4

5 4. Mechanizmy ochrony zasobów w systemach wielozadaniowych W systemach wielozadaniowych w celu ochrony zasobów powszechnie wykorzystywane są dwa podstawowe mechanizmy: separacja zadań, poziomy uprzywilejowania. SEPARACJA ZADAŃ Zanim jakikolwiek program zacznie się wykonywać, musi najpierw zostać umieszczony w pamięci. Zasadniczą kwestią staje się zatem separacja przydzielonych obszarów pamięci poszczególnym zadaniom tak, aby nie mogły one nawzajem zakłócać swojej pracy. Separacja taka jest łatwa do zrealizowania za pomocą tzw. koncepcji rejestru bazowego i granicznego. Rejestr bazowy zawiera najniŝszy adres obszaru pamięci dostępnego dla danego zadania, zaś rejestr graniczny adres najwyŝszy. Zadanie ma prawo odwoływać się jedynie do owego przydzielonego mu obszaru pamięci, a więc o adresach z przedziału pomiędzy wartościami umieszczonymi w obu tych rejestrach. W momencie, gdy wymagany jest dostęp do konkretnej komórki pamięci, jej adres podlega najpierw sprzętowej kontroli, polegającej na porównaniu go z wartościami z owych rejestrów. JeŜeli adres ten jest mniejszy od adresu znajdującego się w rejestrze bazowym bądź większy od tego z rejestru granicznego, dostęp nie jest realizowany, a w zamian zgłaszany jest wyjątek informujący o próbie niedozwolonego dostępu do pamięci. Pewną odmianą przy tej koncepcji jest sytuacja, w której w rejestrze granicznym przechowuje się nie tyle najwyŝszy adres dostępny dla zadania, ale maksymalne przesunięcie względem adresu najmniejszego przechowywanego w rejestrze bazowym. W przypadku korzystania z segmentacji koncepcję rejestru bazowego i granicznego stosuje się nie tyle do całych programów naraz, ale osobno do poszczególnych ich segmentów. KaŜdy segment znajdujący się w programie posiada więc adres swojego początku, czyli adres bazowy, a takŝe swój rozmiar, określany przez programistę, który stanowi podstawę do wyznaczenia granicy segmentu. Opisy wszystkich segmentów uŝywanych przez program trzymane są razem w specjalnej tablicy zwanej tablicą deskryptorów segmentów. POZIOMY UPRZYWILEJOWANIA Drugi mechanizm ochrony, stosowany równolegle obok separacji obszarów pamięci przydzielonych poszczególnym zadaniom, wiąŝe się z tym, iŝ wykonywanie niektórych operacji zarezerwowane jest wyłącznie dla systemu operacyjnego, zaś zwykłe programy uŝytkowników nie powinny mieć moŝliwości ich zrealizowania. Pociąga to za sobą konieczność rozróŝnienia przynajmniej dwóch oddzielnych trybów wykonywania rozkazów: trybu uprzywilejowanego, nazywanego takŝe trybem systemu, w którym pracuje jedynie system operacyjny, mający uprawnienia do wykonania dowolnej instrukcji, oraz trybu uŝytkownika, gdzie wykonanie pewnych instrukcji, zwanych instrukcjami uprzywilejowanymi, pozostaje niedostępne. Do instrukcji uprzywilejowanych naleŝą rozkazy zmieniające zawartość niektórych rejestrów procesora stanowiących podstawę mechanizmu ochrony, jak równieŝ zmieniające poziom ochrony bądź dokonujących pewnych operacji wejścia-wyjścia. Wykrycie przez procesor próby zrealizowania przez program uŝytkownika instrukcji uprzywilejowanej powoduje, analogicznie jak poprzednio, natychmiastowe zgłoszenie odpowiedniego wyjątku. 5. Deskryptory segmentów W przeciwieństwie do trybu rzeczywistego, gdzie segment charakteryzowany był jedynie poprzez adres swojego początku oraz swój rozmiar, który to jednak na etapie wykonywania programu nie był w ogóle brany pod uwagę, w trybie chronionym charakterystyka segmentu jest znacznie szersza i obejmuje, oprócz dwóch powyŝszych, szereg dodatkowych istotnych właściwości. Dopiero wszystkie te informacje wspólnie tworzą Instytut Informatyki, PŁ str. 5

6 kompletny opis segmentu. Opis ten przechowywany jest w specjalnej strukturze zwanej deskryptorem segmentu, która to struktura zawiera następujące dane: adres bazowy segmentu, rozmiar segmentu, atrybuty określające szereg istotnych cech segmentu, w tym między innymi prawa dostępu do segmentu, takie jak na przykład moŝliwość zapisu lub odczytu komórek pamięci w jego obrębie. RozróŜnia się następujące rodzaje deskryptorów segmentów: deskryptory segmentów pamięci, deskryptory systemowe. DESKRYPTORY SEGMENTÓW PAMIĘCI Deskryptory te opisują segmenty znajdujące się w programach uŝytkownika. WyróŜnione zostały dwa typy takich deskryptorów: 1. deskryptor segmentu danych, 2. deskryptor segmentu kodu. Segment stosu stanowi specyficzny segment danych, zatem deskryptor go opisujący naleŝy do kategorii deskryptorów segmentów danych. DESKRYPTORY SYSTEMOWE Deskryptory te mają szczególne zastosowanie z punktu widzenia systemu. WyróŜnione zostały ich następujące typy: 1. deskryptor segmentu zajmowanego przez lokalną tablicę deskryptorów, 2. deskryptor segmentu stanu zadania, 3. deskryptor furtki wywołania, 4. deskryptor furtki przerwania, 5. deskryptor furtki potrzasku, 6. deskryptor furtki zadania. Deskryptory te nie będą omawiane. Schemat deskryptora segmentu pamięci dla procesora 386 zawiera ryc Adres bazowy G D/B 0 AVL Wielkość P DPL S Typ A Adres bazowy Adres bazowy Wielkość Ryc. 1. Format deskryptora segmentu dla procesora 386. Znaczenie poszczególnych pól zawartych w deskryptorze segmentu jest następujące: ADRES BAZOWY (ANG. BASE ADDRESS) Adres bazowy segmentu stanowi 32-bitową wartość określającą adres początku segmentu. PoniewaŜ wartość ta zapisywana jest na 32 bitach, oznacza to, iŝ adres początku segmentu musi on być pamiętany inaczej niŝ w trybie rzeczywistym. I tak jest w istocie, jako Ŝe o ile w trybie rzeczywistym przechowywany był on w postaci 16-bitowego numeru paragrafu, od którego rozpoczynał się dany segment, o tyle tu, w trybie chronionym, przyjmuje formę pełnego 32-bitowego adresu liniowego. Niesie to dwie powaŝne konsekwencje. Po pierwsze, początek segmentu nie musi juŝ leŝeć dokładnie na granicy paragrafu, lecz moŝe znajdować się w dowolnym miejscu w pamięci. Po drugie zaś, wyznaczenie adresu fizycznego konkretnej komórki pamięci, do której nastąpiło odwołanie, odbywa się nieco inaczej. W przypadku procesora 386, o ile wyłączony został mechanizm stronicowania, dokonuje się tego jedynie poprzez dodanie Ŝądanego przemieszczenia do owego adresu bazowego pamiętanego w sposób bezpośredni, zatem juŝ bez wymnaŝania czegokolwiek przez 16. Zanim jednak do tego dojdzie, najpierw przeprowadzone zostaje sprawdzenie, Instytut Informatyki, PŁ str. 6

7 czy owe przemieszczenie nie wykracza poza dopuszczalną wielkość segmentu. JeŜeli okazałoby się, Ŝe tak wówczas realizacja dostępu nie nastąpi, natomiast procesor generuje wyjątek GP (ang. General Protection Fault ogólne naruszenie mechanizmu ochrony). ZAKRES (ANG. LIMIT) Zakres jest jednym z dwóch pól, które determinują rozmiar segmentu. Przechowuje on 20-bitową wartość określającą górną granicę wielkości przesunięcia w ramach segmentu. ZIARNISTOŚĆ (ANG. GRANULARITY) G Ziarnistość jest drugim z pól, które determinują rozmiar segmentu, pozwala ona bowiem na poprawną interpretację zapamiętanej jako zakres wielkości. Jej zadaniem jest przekazanie informacji, w jakich jednostkach wyraŝona jest ta wielkość. Wartość 0 oznacza, iŝ jednostką długości jest 1 bajt. Maksymalny rozmiar segmentu w takim przypadku wynosić moŝe 1 MB. Wartość 1 oznacza, iŝ jednostką długości są 4 KB. Maksymalny rozmiar segmentu jest wówczas równy 4 GB. Wyznaczenie rzeczywistego rozmiaru segmentu musi zatem odbywać się w oparciu zarówno o zakres, jak i o ziarnistość. Przykładowo, jeŝeli w polu zakres zapisana zostanie wartość 1023, rozmiar segmentu wynosi 1 KB, jeŝeli G=0, albo 4 MB, jeŝeli G=1. NaleŜy przy tym zauwaŝyć, Ŝe skoro pole zakres wyraŝa nie tyle rozmiar segmentu, ile górną granicę wielkości przesunięcia w jego obrębie, więc dla zakresu równego 0 i G=0 rozmiar segmentu wynosi nie 0, lecz 1 bajt (górna granica 0, ilość danych, jaką moŝna tam przechować 1 bajt, stąd maksymalne przesunięcie 0h i rozmiar segmentu 1 bajt), natomiast dla G=1 rozmiar ten wynosi 4096 bajtów (górna granica 0, ilość danych, jaką moŝna tam przechować 4 KB, stąd maksymalne przesunięcie 0FFFh i rozmiar segmentu 4096 bajtów). DŁUGOŚĆ SŁOWA (ANG. DEFAULT OPERATION SIZE) D/B Pole D/B określa, czy segment ma charakter 16-bitowy czy teŝ 32-bitowy. Wartość 0 oznacza segment 16-bitowy, a wartość 1 segment 32-bitowy. Przekłada się to bezpośrednio na interpretowanie przesunięć przy odwoływaniu się do tego segmentu: w pierwszym przypadku przesunięcia są wartościami 16-bitowymi, zaś w drugim 32-bitowymi. RODZAJ DESKRYPTORA (ANG. DESCRIPTOR TYPE) S Rodzaj deskryptora stwierdza, czy jest to deskryptor pamięci, czy systemowy. Wartość 0 oznacza segment systemowy, a wartość 1 segment pamięci. TYP (ANG. TYPE) W przypadku deskryptora segmentu pamięci, opisywany przezeń segment, jak zostało to juŝ wcześniej wspomniane, moŝe być albo segmentem kodu, albo segmentem danych. Pole typ słuŝy do wyznaczenia, który z powyŝszych wariantów zachodzi, jak i równieŝ do określenia pewnych praw związanych z dostępem do segmentu. Wartości tego pola przedstawione zostały w poniŝszej tabeli: Wartość Znaczenie 0 segment danych, tylko odczytywanie 1 segment danych, odczytywanie i zapisywanie 2 segment danych rozszerzalny w dół, tylko odczytywanie 3 segment danych rozszerzalny w dół, odczytywanie i zapisywanie 4 segment kodu, tylko wykonywanie 5 segment kodu, wykonywanie i odczytywanie 6 zgodny segment kodu, tylko wykonywanie 7 zgodny segment kodu, wykonywanie i odczytywanie Segmenty kodu przechowują instrukcje realizowane przez program, muszą zatem mieć nadane prawo pozwalające na ich wykonywanie. JeŜeli z segmentów tych mają być oprócz Instytut Informatyki, PŁ str. 7

8 tego odczytywane umieszczone tam dodatkowo dane, musi ponadto zostać nadane zezwolenie na odczyt. Nie ma jednak typu, który pozwalałby na przyznanie prawa zapisu do takich segmentów, a więc dane takie nie mogą być modyfikowane w trakcie pracy programu. Segmenty danych mogą być albo zwykłe, albo rozszerzalne w dół. RozróŜnienie to ma istotne znaczenie, gdy zachodzi konieczność powiększenia takiego segmentu. Przy zwykłym segmencie danych w takiej sytuacji wystarczy odpowiednio zwiększyć wartość pola zakres. Inaczej jednak sprawa wygląda w przypadku stosów programów, równieŝ będących segmentami danych, tyle Ŝe dosyć specyficznymi. OtóŜ dane umieszczane są w takim segmencie w miejscu wskazywanym przez wierzchołek stosu, a wartość tego wierzchołka po kaŝdym zapisie nowej danej ulega dekrementacji. MoŜna zatem powiedzieć, Ŝe stos rośnie w kierunku malejących adresów. Powiększając segment stosu naleŝałoby zatem nie tyle przydzielić mu dodatkową przestrzeń za jego końcem, ale raczej przed jego początkiem. Wymagałoby to jednak zmiany dwóch właściwości segmentu, mianowicie zakresu oraz adresu bazowego, a takŝe jednoczesnego zmodyfikowania wartości wierzchołka stosu. Aby tego uniknąć, wprowadzony został specjalny typ segmentu danych, jakim jest właśnie segment rozszerzalny w dół. Typ ten charakteryzuje się odwrotną interpretacją pola zakres. OtóŜ w zwykłym segmencie wartość tego pola oznacza górną granicę wielkości przesunięcia w ramach segmentu, natomiast w odniesieniu do segmentu rozszerzalnego w dół granicę dolną. W tym ostatnim przypadku wszystkie przemieszczenia mniejsze lub równe wyznaczonemu na podstawie tejŝe granicy przemieszczeniu traktowane są jako spoza segmentu, natomiast większe jako leŝące w jego obrębie. W tej sytuacji rozszerzenie takiego segmentu sprowadza się jedynie do zmniejszenia wartości pola zakres. Zgodne segmenty kodu wiąŝą się z poziomami ochrony i zostaną omówione w dalszej części. POZIOM OCHRONY (ANG. DESCRIPTOR PRIVILEGE LEVEL) DPL Poziom ochrony segmentu wiąŝe się z poziomami ochrony i zostanie omówiony w dalszej części. SEGMENT OBECNY (ANG. PRESENT) P Pole to wykorzystywane jest przez mechanizm pamięci wirtualnej i nie będzie omawiane. SEGMENT UśYTY (ANG. ACCESSED) A Pole to wykorzystywane przez mechanizm pamięci wirtualnej i nie będzie omawiane. POLE DOSTĘPNE DLA PROGRAMU (ANG. AVAILABLE TO SOFTWARE) AVL Pole to nie jest uŝywane przez procesor. Zostało utworzone z myślą o wykorzystaniu przez system operacyjny. W celu zobrazowania postaci konkretnego deskryptora, posłuŝyć się moŝna następującym przykładem: Descriptor DW 0F9Fh, 8000h, 920Bh, 0000h Deskryptor ten opisuje segment, który obejmuje swym obszarem całą pamięć obrazu w trybie 03h karty grafiki, a więc w trybie tekstowym o 80 kolumnach i 25 wierszach. Wyświetlany obraz zapisywany jest w tej pamięci w ten sposób, iŝ następującym po sobie pozycjom na ekranie, zaczynając od lewego górnego naroŝnika i przebiegając kolejno wzdłuŝ wszystkich wierszy, przyporządkowane są dwa bajty: pierwszy przechowuje kod ASCII wyświetlanego w danym miejscu znaku, a drugi jego atrybuty, takie jak kolor czcionki czy tła. Pamięć ta ma zatem charakter dwuwymiarowej tablicy, a jej rozmiar określić moŝna wymnaŝając 80 kolumn przez 25 wierszy i przez 2 bajty, co daje razem 4000 bajtów. Dodatkowo, początek tej pamięci umiejscowiony jest pod ściśle określonym adresem, a mianowicie rozpoczyna się ona od paragrafu o numerze 0B800h. Instytut Informatyki, PŁ str. 8

9 W przedstawionym powyŝej deskryptorze adres bazowy segmentu (zapisany na bitach i 56 63) po scaleniu do właściwej postaci 32-bitowej przyjmuje wartość 000B8000h, która to dokładnie odpowiada początkowi wspomnianego paragrafu. Ziarnistość ustawiona na 0 (bit 55 G=0) oznacza, Ŝe zakres wyraŝony jest w bajtach, natomiast sam zakres (bity 0 15 oraz 48 51) zapisany jako liczba 20-bitowa wynosi 00F9Fh. Po przeliczeniu daje to więc maksymalne przesunięcie w ramach segmentu wynoszące 0F9Fh i rozmiar segmentu równy dokładnie 4000 bajtów. Rozpisanie wartości 92h (bity 40 47) dostarcza informacji o tym, Ŝe segment jest obecny w pamięci (bit 47 P=1), ma najwyŝszy poziom ochrony (bity 45 i 46 DPL=0), stanowi segment pamięci (bit 44 S=1) oraz przechowuje dane, które moŝna zarówno odczytywać, jak i zapisywać (bity Typ=1). Wiadomo ponadto, iŝ segment ten jest 16-bitowy (bit 54 D/B=0). Pola A (bit 40) i AVL (bit 52) pozostają wyzerowane. 6. Rodzaje tablic deskryptorów Deskryptory segmentów przechowywane są razem w tzw. tablicy deskryptorów. Istnieją trzy rodzaje takich tablic: Globalna tablica deskryptorów (ang. Global Descriptor Table), oznaczana w skrócie GDT zawiera deskryptory segmentów, w których mieszczą się głównie dane i kod systemu operacyjnego, ale takŝe pewne ogólnie dostępne zasoby, jak na przykład pamięć obrazu. Lokalna tablica deskryptorów (ang. Local Descriptor Table), oznaczana w skrócie LDT zawiera deskryptory segmentów naleŝących do określonego zadania. KaŜdy z programów posiada zatem swoją własną lokalną tablicę deskryptorów, opisującą segmenty, z których się składa. Tablica deskryptorów przerwań (ang. Interrupt Descriptor Table), oznaczana w skrócie IDT zawiera deskryptory furtek przechowujących odwołania do tych wszystkich segmentów, gdzie umieszczone są procedury obsługi przerwań. Program uŝytkownika moŝe korzystać zarówno z segmentów opisanych w swojej LDT, jak i w GDT. 7. Selektory Komunikowanie się z pamięcią wymaga kaŝdorazowego wyspecyfikowania fizycznego adresu konkretnej jej komórki, do której ma być zrealizowany dostęp. Adres ten wyznaczany jest na podstawie adresu początku segmentu oraz przemieszczenia. O ile jednak w trybie rzeczywistym adres początku segmentu, w postaci numeru paragrafu, przechowywany jest w odpowiednim rejestrze segmentowym, o tyle w trybie chronionym wygląda to juŝ inaczej, jako Ŝe rejestr taki pełni w nim odmienną rolę. Zamiast numeru paragrafu znajduje się tam tzw. selektor segmentu. Selektor ten stanowi odwołanie do odpowiedniego deskryptora segmentu w wybranej tablicy deskryptorów, który to dopiero deskryptor zawiera wszystkie niezbędne informacje na temat lokalizacji tegoŝ segmentu. Schemat selektora segmentu zawiera ryc Numer deskryptora TI RPL 0 Ryc. 2. Format selektora segmentu. Znaczenie poszczególnych pól selektora segmentu jest następujące: NUMER DESKRYPTORA (ANG. INDEX) Numer deskryptora zawiera indeks deskryptora w wybranej tablicy, przy czym dozwolone jest odwoływanie się tylko do tablicy GDT albo LDT. W kaŝdej z nich deskryptory ponumerowane są zgodnie z kolejnością, w jakiej występują. Tablice te zawierać mogą Instytut Informatyki, PŁ str. 9

10 maksymalnie po 8192 deskryptory, które indeksowane są od 0 do Numer deskryptora odpowiada więc indeksowi tablicy, pod którym mieści się Ŝądany deskryptor. WYRÓśNIK TABLICY (ANG. TABLE INDICATOR) TI Pole TI mówi, w jakiej tablicy poszukiwać naleŝy Ŝądanego deskryptora: wartość 0 w tym miejscu oznacza, Ŝe deskryptor znajduje się w GDT, zaś wartość 1 wskazuje na LDT. POZIOM OCHRONY ZADANIA (KODU) śądającego DOSTĘPU (ANG. REQUESTOR S PRIVILEGE LEVEL) RPL Pole to wiąŝe się z poziomami ochrony, jednak jego wykorzystanie jest specyficzne i nie będzie omawiane. Przykładowo, selektor moŝe przyjmować następującą postać: Selector DW 08h PowyŜszy selektor odwołuje się do tablicy GDT (bit 2 TI=0), w której odpowiadający mu deskryptor znajduje się pod indeksem 1 (bity 3 15), czyli tak naprawdę jest drugim deskryptorem w tej tablicy, poniewaŝ pierwszy ma przyporządkowany indeks 0. Ponadto selektor ten dostarcza informacji, iŝ program Ŝądający dostępu do wskazywanego segmentu działa na najwyŝszym poziomie uprzywilejowania (bity 0 1 RPL=0). Selektor, w którym numer deskryptora jest równy 0 oraz TI=0, ma znaczenie specjalne. Jest to tzw. selektor zerowy. Powinien być on umieszczany w tych rejestrach segmentowych, których zawartość jest nieistotna, czyli które aktualnie nie odwołują się do Ŝadnego konkretnego deskryptora. Dokładnie rzecz ujmując, selektorowi temu odpowiada deskryptor znajdujący się w tablicy GDT pod indeksem 0, jednakŝe deskryptor ten nigdy nie jest uŝywany. Próba dostępu do pamięci przy uŝyciu rejestru segmentowego załadowanego takim selektorem spowoduje wygenerowanie przez procesor wspomnianego juŝ wcześniej wyjątku GP. Jedyny rejestr segmentowy, w którym selektor zerowy nie moŝe zostać umieszczony, to rejestr SS. Procesor nie zezwoli na taka operację, równieŝ zgłaszając wyjątek GP. Jakakolwiek odwołanie się do zawartości dowolnego segmentu, zanim zostanie zrealizowane, wymusza najpierw na sprzętowych mechanizmach ochrony przeprowadzenie kompletnej kontroli jego legalności, a więc sprawdzenie, czy na przykład mieści się ono w obrębie wskazanego segmentu, czy nie narusza praw dostępu do niego, choćby chcąc dokonać zapisu w segmencie przeznaczonym tylko do odczytu itp. Aby za kaŝdym razem nie trzeba było odczytywać deskryptora owego segmentu z pamięci, co niepotrzebnie wydłuŝałoby czas dostępu, procesor zaopatrzony został w specjalne rejestry deskryptorów stowarzyszone z odpowiednimi rejestrami segmentowymi. Załadowanie selektora do rejestru segmentowego powoduje automatyczne załadowanie wskazywanego przezeń deskryptora do właściwego rejestru deskryptora. Owe rejestry deskryptorów mają jednak ukryty charakter, a więc są niewidoczne i niedostępne dla programisty. Schemat powiązania rejestrów segmentowych i skojarzonych z nimi ukrytych rejestrów deskryptorów zawiera ryc. 3. Rejestry segmentowe (widoczne) Rejestry deskryptorów (ukryte) CS Adres bazowy Zakres Atrybuty DS Adres bazowy Zakres Atrybuty ES Adres bazowy Zakres Atrybuty FS Adres bazowy Zakres Atrybuty GS Adres bazowy Zakres Atrybuty SS Adres bazowy Zakres Atrybuty Ryc. 3. Powiązanie rejestrów segmentowych z odpowiadającymi im ukrytymi rejestrami deskryptorów. Zanim dany selektor zostanie faktycznie umieszczony w rejestrze segmentowym, wpierw poddawany jest on niezbędnym testom, których zadaniem jest wykrycie jakiejkolwiek próby naruszenia zasad ochrony. Warunków do spełnienia jest tu kilka. Przede wszystkim wartość selektora musi być wartością poprawną, ma więc wskazywać na rzeczywiście istniejący deskryptor segmentu, bądź stanowić selektor zerowy. Samo zadanie z kolei musi Instytut Informatyki, PŁ str. 10

11 znajdować się na odpowiednim poziomie uprzywilejowania, tak aby nie naruszyć poziomu ochrony tego segmentu, który to poziom zapisany jest w jego deskryptorze. Ponadto zawarte tamŝe atrybuty owego segmentu spełniać muszą pewne załoŝenia. Mianowicie dla rejestrów segmentowych danych (DS, CS, ES, FS i GS) segment musi mieć zezwolenie do odczytu. Dla rejestru segmentowego stosu (SS) musi mieć on zezwolenie zarówno do odczytu jak i do zapisu, przy czym moŝe, choć nie musi, być segmentem rozszerzalnym w dół. Dla rejestru segmentowego kodu (CS) musi mieć atrybut wykonywalności. Dopiero przejście całej tej procedury i stwierdzenie, Ŝe Ŝaden z tych warunków nie uległ naruszeniu, pozwala na wpisanie selektora do rejestru segmentowego i automatycznie powoduje takŝe umieszczenie odpowiadającego mu deskryptora w stowarzyszonym rejestrze ukrytym. Jakiekolwiek naruszenie zasad ochrony z kolei doprowadzi do wygenerowania przez procesor wyjątku GP. W razie potrzeby, by uchronić się przed zajściem tej ostatniej sytuacji, moŝna samodzielnie zweryfikować poprawność selektora i nadane mu prawa. SłuŜą do tego trzy instrukcje. Pierwsza z nich, instrukcja LAR, sprawdza poprawność podanego selektora i, jeŝeli jest prawidłowy, zwraca atrybuty wskazywanego przezeń segmentu. Druga, rozkaz VERW, kontroluje, czy selektor jest poprawny i czy odpowiadający mu segment ma prawo do zapisu, natomiast trzecia, VERR, na podobnej zasadzie weryfikuje, czy segment ma prawo do odczytu. Po umieszczeniu selektora w rejestrze segmentowym moŝna juŝ odwołać się do konkretnej komórki pamięci w danym segmencie. I tu równieŝ przed przeprowadzeniem kaŝdej tego typu operacji włączają się mechanizmy ochrony, które sprawdzają legalność podjętego działania, zaś w przypadku stwierdzenia nieprawidłowości spowodują wygenerowanie wyjątku GP. Pojawi się on na przykład przy próbie zapisu do segmentu, który nie ma nadanego prawa do zapisu, albo przy próbie odczytu bądź zapisu danych poza granicą segmentu. Tej ostatniej sytuacji moŝna zapobiec, uprzednio sprawdzając długość segmentu za pomocą rozkazu LSL. 8. Poziomy ochrony Zapewnienie bezpiecznego funkcjonowania systemu komputerowego wymaga, oprócz zastosowania odpowiedniej separacji zadań za pomocą ochrony zajmowanej przez nie pamięci, takŝe uniemoŝliwienia wykonywania pewnych newralgicznych z punktu widzenia owego bezpieczeństwa operacji przez programy do tego nieuprawnione. Pociąga to za sobą konieczność wyodrębnienia róŝnych poziomów uprzywilejowania, które determinować będą dostępność realizacji tego typu operacji. W trybie chronionym istnieją cztery takie poziomy. Trzy najbardziej uprzywilejowane z reguły przeznaczone są dla systemu operacyjnego, zaś dopiero na czwartym, najniŝszym, działają programy uŝytkownika. Ale takŝe w ramach poziomów przypisanych systemowi operacyjnemu obowiązuje ściśle określona hierarchia. Poziom najwyŝszy przeznaczony jest dla jądra systemu operacyjnego, poziomy drugi i trzeci wykorzystywane są zaś przez usługi systemowe, sterowniki urządzeń itp. Poziom trzeci moŝe równieŝ zostać udostępniony dla programów uŝytkowych wymagających szczególnej ochrony, takich jak na przykład systemy zarządzania bazami danych. Zastosowanie róŝnych poziomów uprzywilejowania wymaga, aby w kaŝdym programie wszystkie segmenty, bez względu na to, czy zawierają kod, dane, czy teŝ są segmentami stosu, miały określony właściwy sobie poziom ochrony. Informacja ta jest zapisywana w polu DPL deskryptora segmentu. NajwyŜszemu, czyli najbardziej uprzywilejowanemu poziomowi, odpowiada wartość 0 tego pola, zaś poziomowi najniŝszemu, a więc najmniej uprzywilejowanemu wartość 3. W systemie kaŝdy z programów wykonuje się na ściśle wyznaczonym poziomie ochrony. PoniewaŜ jednak naraz moŝe być uruchomionych wiele zadań, konieczne staje się zdefiniowanie tzw. bieŝącego poziomu ochrony. OtóŜ bieŝący poziom ochrony (ang. Current Instytut Informatyki, PŁ str. 11

12 Privilege Level), oznaczany w skrócie CPL, jest to ten poziom uprzywilejowania, jaki ma zadanie, któremu aktualnie przydzielony został czas procesora, a precyzyjniej aktualnie przetwarzany segment kodu tego zadania. CPL pamiętany jest na dwóch najmłodszych bitach rejestru CS, czyli w polu RPL znajdującego się tam selektora. Poziom ochrony zadania determinuje moŝliwości wykonania przez to zadanie instrukcji uprzywilejowanych, które niewłaściwie uŝyte mogą wszak zagrozić bezpiecznemu funkcjonowaniu systemu. NaleŜą do nich między innymi rozkazy modyfikujące pewne kluczowe struktury systemowe, na przykład tablice deskryptorów. Tylko zadania na najwyŝszym poziomie uprzywilejowania mają prawo wykonywać takie instrukcje. Poziom ochrony zadania wyznacza takŝe moŝliwości dostępu przez to zadanie do innych segmentów, tak kodu jak i danych. Oba te przypadki rządzą się jednak odmiennymi prawami. Przy dostępie do danych dopuszczalne jest odwołanie się do segmentu będącego na tym samym lub niŝszym poziomie ochrony w stosunku do CPL. Wynika to z przyjętej zasady, Ŝe nie moŝna zezwolić zadaniu działającemu na określonym poziomie uprzywilejowania na odczytywanie bądź modyfikowanie danych bardziej chronionych. JeŜeli stwierdzona zostanie próba naruszenia tej reguły, procesor wygeneruje wyjątek GP. Z drugiej strony, dostęp do danych będących na takim samym poziomie ochrony lub chronionych słabiej odbywać się moŝe bez przeszkód. Z kolei w przypadku, gdy dostęp ma mieć miejsce do innego segmentu kodu, co moŝe zostać zrealizowane poprzez wykonanie skoku do tego segmentu lub przez wywołanie procedury tam się znajdującej, operacja taka dozwolona jest wtedy, gdy poziom ochrony segmentu docelowego jest równy CPL. W przeciwnym razie nastąpi wygenerowanie wyjątku GP. Istnieje jednak odstępstwo od tej reguły. W określonych sytuacjach moŝliwa jest realizacja dostępu do segmentu kodu takŝe wówczas, kiedy segment ten ma wyŝszy niŝ CPL poziom ochrony. Ma to miejsce na przykład wtedy, gdy program wywołuje którąś z funkcji udostępnianych aplikacjom przez system operacyjny. A zatem, moŝna uznać, iŝ program ma prawo odwołać się do segmentu kodu znajdującego się na tym samym poziomie ochrony bądź jeśli spełnione są określone warunki na poziomie wyŝszym. Nie ma jednak prawa odwoływać się do segmentu znajdującego się na poziomie niŝszym. Uzasadnione jest to faktem, Ŝe realizacja zadania działającego na określonym poziomie uprzywilejowania nie moŝe opierać się na wykorzystaniu procedur niejako mniej godnych zaufania. Dostęp do segmentu kodu na wyŝszym poziomie ochrony jest moŝliwy tylko w dwóch sytuacjach. Pierwsza z nich zachodzi wówczas, gdy segment docelowy jest segmentem wykonywalnym o typie zgodnym. W przeciwieństwie do tych segmentów, które nie są oznaczone jako zgodne, segment zgodny umoŝliwia wejście doń nie tylko z segmentu o takim samym poziomie ochrony, ale takŝe o poziomie niŝszym. Tylko w przypadku próby dostępu z segmentu znajdującego się na wyŝszym poziomie uprzywilejowania nastąpi wówczas wygenerowanie wyjątku GP. Co więcej, przejście do owego segmentu o wyŝszym poziomie ochrony nie powoduje zmiany CPL. MoŜna więc powiedzieć, Ŝe segment zgodny ma taki sam bieŝący poziom ochrony, który miał podprogram wywołujący. Drugi przypadek natomiast wymaga zastosowania specjalnego mechanizmu, jakim jest skorzystanie z tzw. furtki wywołania, który to mechanizm jednak nie będzie omawiany. 9. Budowa tablic deskryptorów Jak zostało to juŝ wspomniane wcześniej, deskryptory segmentów trzymane są razem w specjalnych tablicach, zwanych tablicami deskryptorów. WyróŜnia się trzy rodzaje takich tablic: globalną tablicę deskryptorów (GDT), lokalną tablicę deskryptorów (LDT) oraz tablicę deskryptorów przerwań (IDT). O ile jednak w systemie istnieje tylko jedna tablica GDT i jedna tablica IDT, o tyle kaŝde zadanie dysponuje własną tablicą LDT. Instytut Informatyki, PŁ str. 12

13 PoniewaŜ wszystkie te tablice znajdują się w pamięci operacyjnej, siłą rzeczy muszą one równieŝ zostać umieszczone w pewnych segmentach, a te z kolei muszą posiadać odpowiednie opisy. W zaleŝności od rodzaju tablicy opisy te wyglądają nieco inaczej i przechowywane są w innych miejscach. TABLICA GDT Tablica GDT moŝe zawierać do 8192 deskryptorów. Jako Ŝe pojedynczy deskryptor zapisywany jest na 8 bajtach, oznacza to, Ŝe jej długość nie moŝe przekraczać 64 KB. Segment, w którym się ona znajduje, opisywany jest za pomocą tzw. pseudodeskryptora segmentu, tym róŝniącego się od pełnego deskryptora, Ŝe nie zawiera on Ŝadnych informacji na temat atrybutów, lecz jedynie 32-bitowy adres bazowy i 16-bitowy zakres, wyraŝający rozmiar tego segmentu w bajtach. Aby umoŝliwić efektywne odwoływanie się do tej tablicy, pseudodeskryptor ów trzymany jest w specjalnym rejestrze procesora GDTR (ang. Global Descriptor Table Register). Cechą charakterystyczną tablicy GDT jest to, Ŝe jej pierwszy deskryptor, znajdujący się pod indeksem 0, nie jest nigdy przez system uŝywany. TABLICA LDT Tablica LDT podlega takiemu samemu ograniczeniu jak tablica GDT: moŝe ona zawierać do 8192 deskryptorów, numerowanych od indeksu 0, a zatem jej rozmiar takŝe nie moŝe przekraczać 64 KB. Tablica ta umieszczana jest w odrębnym segmencie, który jednakowoŝ musi posiadać swój pełny deskryptor, do tego znajdujący się obowiązkowo w GDT. Deskryptor ten ma specjalne znaczenie, toteŝ naleŝy do grupy deskryptorów systemowych. Aby jednak przy kaŝdym odwołaniu do tablicy LDT nie zachodziła konieczność odczytywania go z pamięci w celu zlokalizowania tejŝe tablicy, procesor wyposaŝony został w specjalny rejestr LDTR (ang. Local Descriptor Table Register), funkcjonujący na podobnej zasadzie jak rejestry segmentowe, a więc posiadający stowarzyszony ukryty rejestr deskryptora. W samym rejestrze LDTR przechowany jest jedynie selektor, który wskazuje na ten deskryptor w tablicy GDT, który z kolei opisuje segment, gdzie znajduje się tablica LDT. Załadowanie rejestru LDTR tym selektorem powoduje automatyczne umieszczenie wskazywanego przezeń deskryptora w owym ukrytym rejestrze. KaŜde z zadań posiada swoją własną LDT, co oznacza, Ŝe w momencie przełączania zadania wartość rejestru LDTR musi ulec odpowiedniej zmianie. TABLICA IDT Tablica IDT, w przeciwieństwie do dwóch poprzednich, wykorzystywana jest przez procesor 386 zarówno w trybie chronionym, jak i rzeczywistym. W trybie rzeczywistym, wbrew nazwie, przechowuje ona nie deskryptory, lecz wektory, zawierające dalekie adresy procedur obsługi przerwań, stanowiąc tym samym tablicę wektorów przerwań. W tym przypadku tablica ta moŝe mieć maksymalny rozmiar równy 1 KB. W trybie chronionym umieszczone są w niej deskryptory furtek, zaś maksymalny rozmiar moŝe wynosić 2 KB. W obu trybach tablica ta znajduje się w osobnym segmencie, który moŝe być zlokalizowany w dowolnym miejscu pamięci. Segment ten, podobnie jak to miało miejsce przy tablicy GDT, opisywany jest za pomocą pseudodeskryptora, zawierającego 32-bitowy adres bazowy oraz 16-bitowy zakres wyraŝony w bajtach, aczkolwiek sens ma tylko umieszczenie tam wartości nie przekraczającej 11 bitów, jako Ŝe zgodnie z tym, co zostało powiedziane wyŝej tablica ta nie moŝe być dłuŝsza niŝ 2 KB. W przeciwieństwie jednak do tablicy GDT, jej pierwszy element, znajdujący się pod indeksem 0, moŝe stanowić normalnie uŝywany deskryptor. Analogicznie jak poprzednio, w celu przyspieszenia odwoływania się do tej tablicy, jej pseudodeskryptor przechowywany jest w specjalnym rejestrze procesora IDTR (ang. Interrupt Descriptor Table Register). Instytut Informatyki, PŁ str. 13

14 Aby zapewnić zgodność z procesorami 8086, w trybie rzeczywistym rejestr IDTR zawiera normalnie adres bazowy równy 0, zaś zakres przyjmuje wartość 3FFh. W tej sytuacji tablica wektorów przerwań mieści się na początku przestrzeni adresowej i ma długość 1 KB, czyli wygląda dokładnie tak, jak ma to miejsce w przypadku procesora 8086, który rejestru IDTR wszak nie posiada. Co prawda w procesorze 386 podczas pracy w trybie rzeczywistym dozwolone jest, poprzez odpowiednią modyfikację zawartości rejestru IDTR, przemieszenie tej tablicy w inne miejsce pamięci bądź zmienienie jej długości, lecz ze wspomnianego wyŝej względu się tego nie praktykuje. Pobieranie informacji na temat połoŝenia wszystkich trzech rodzajów tablic, jak i zmiana tego połoŝenia, moŝliwa jest przy uŝyciu specjalnych instrukcji, które jednakŝe w trybie chronionym naleŝą do instrukcji uprzywilejowanych, a zatem mogą być wykonane jedynie przez programy operujące na najwyŝszym poziomie uprzywilejowania. Do pobrania danych opisujących tablicę GDT, a więc jej adresu bazowego i długości, słuŝy rozkaz SGDT. Z kolei zmiana połoŝenia bądź rozmiaru tej tablicy musi zostać niezwłocznie zgłoszona procesorowi, czego dokonuje się za pomocą rozkazu LGTD. Obie instrukcje mają ten sam argument, a mianowicie wskaźnik na 6-bajtowy obszar pamięci, którego pierwsze dwa bajty zawierają długość tablicy, a pozostałe cztery jej adres bazowy, przy czym w pierwszym przypadku instrukcja umieszcza tam odpowiednie dane, zaś w drugim stamtąd pobiera. Analogicznie realizowane jest pobieranie bądź modyfikowanie informacji o połoŝeniu i wielkości tablicy IDT. SłuŜą do tego odpowiednio rozkazy SIDT i LIDT, o takim samym jak powyŝej argumencie. Ustalenie i zapisanie połoŝenia bieŝącej tablicy LDT odbywa się za pomocą instrukcji SLDT i LLDT. Argumentem obu z nich jest selektor odpowiedniego deskryptora znajdującego się w tablicy GDT. Wszystkie powyŝsze rozkazy mogą równieŝ zostać uŝyte w trybie rzeczywistym. Dzięki temu moŝliwe jest na przykład wcześniejsze uprzednie przygotowanie tablic GDT oraz IDT przed dokonaniem przełączenia do trybu chronionego. 10. Przejście do trybu chronionego Podanie sygnału na wejście RESET procesora 386 powoduje jego wyzerowanie i inicjalizację, która to wprowadza go w tryb adresowania rzeczywistego. W jej trakcie do rejestru IDTR załadowany zostaje pseudodeskryptor o adresie bazowym mającym wartość 0 oraz o zakresie równym 3FFh. Dzięki temu następuje takie ustalenie lokalizacji i rozmiaru tablicy wektorów przerwań, aby zachodziła pełna zgodność z procesorem Tablica wektorów przerwań mieści się zatem na początku pamięci operacyjnej i zawiera miejsce na 256 wektorów. MoŜna więc w pewnym sensie powiedzieć, Ŝe po inicjalizacji procesor 386 działa jako szybszy odpowiednik jednostki Po zakończeniu tego etapu następuje skok do programu znajdującego się w pamięci EPROM, który zawiera kod inicjalizacji systemu komputerowego. Program ten, po wykonaniu odpowiednich testów, przystępuje do wczytania z dysku systemu operacyjnego. Przejście do trybu chronionego wiąŝe się ze zmianą odpowiedniego bitu w jednym z rejestrów sterujących procesora. Aby przejść do trybu chronionego, naleŝy ustawić flagę PE (ang. Protected Mode Enable), czyli najmniej znaczący bit rejestru CR0. PoniewaŜ nie istnieje instrukcja procesora bezpośrednio zmieniająca wartość tego bitu, operację tę trzeba wykonać trzyetapowo: najpierw naleŝy pobrać zawartość całego rejestru CR0 do jakiegoś 32-bitowego rejestru ogólnego przeznaczenia (np. EAX) za pomocą rozkazu MOV, następnie ustawić ten bit uŝywając instrukcji OR i na koniec tę zmodyfikowaną wartość zapisać ponownie rozkazem MOV do rejestru CR0. Instytut Informatyki, PŁ str. 14

15 Zachowanie zgodności z procesorem 286 przy przechodzeniu między trybami rzeczywistym a chronionym i z powrotem pociągnęło za sobą pewne istotne konsekwencje. OtóŜ o ile procesor 386 pozwala w sposób programowy wrócić do trybu rzeczywistego, o tyle w jego poprzedniku włączenie trybu chronionego uniemoŝliwiało powrót do trybu rzeczywistego inaczej niŝ przez podanie procesorowi sygnału na wejście RESET. Ponadto, w procesorze 286 nie istniał 32-bitowy rejestr CR0 w zamian znajdował się tam 16-bitowy rejestr MSW (ang. Machine Status Word), w którym to umieszczona była flaga PE. Do operowania na rejestrze MSW uŝywało się rozkazu SMSW w celu pobrania jego zawartości do jakiegoś 16-bitowego rejestru ogólnego przeznaczenia, oraz LMSW do przepisania jej z owego 16-bitowego rejestru do rejestru MSW. A zatem, o ile moŝna było rozkazem LMSW wpisać do tego rejestru nową wartość z ustawionym bitem PE, by przejść z trybu rzeczywistego do chronionego, o tyle nie moŝna było tym rozkazem w trybie chronionym załadować wartości przywracającej tryb rzeczywisty. W procesorze 386 rejestr MSW został włączony do rejestru CR0 jako jego mniej znacząca połowa. Wobec tego tu równieŝ wolno korzystać z rozkazów SMSW i LMSW. JednakŜe wspomniana zgodność z procesorem 286 utrzymuje powyŝsze ograniczenie w mocy: za pomocą rozkazu LMSW moŝna wprowadzić do rejestru MSW wartość włączającą tryb chroniony, natomiast nie moŝna odtworzyć trybu rzeczywistego, mimo iŝ procesor 386 na to pozwala. W tej sytuacji w przypadku tego procesora zamiast korzystać z rozkazów SMSW i LMSW operujących na rejestrze MSW, naleŝy uŝyć rozkazów MOV do operowania na całym rejestrze CR0, co umoŝliwi zarówno ustawienie jak i skasowanie flagi PE. Zanim jednak ustawi się tę flagę wprowadzając tym samym procesor w tryb chroniony, naleŝy wcześniej, jeszcze w trybie rzeczywistym, odpowiednio zainicjować tablice GDT i IDT oraz załadować rejestry GDTR i IDTR. Dopiero potem moŝna zmienić wartość bitu PE. NaleŜy jednak zwrócić uwagę, Ŝe zmiana tej wartości i załadowanie rejestru IDTR są to dwie róŝne instrukcje, które nie mogą być wszakŝe wykonane jednocześnie. Oznacza to, iŝ po wpisaniu do rejestru IDTR pseudoeskryptora tablicy przerwań trybu chronionego system jeszcze przez chwilę pozostanie w trybie rzeczywistym. Pojawienie się w tym momencie przerwania spowoduje błąd, gdyŝ procesor nie będzie miał juŝ dostępu do tablicy wektorów przerwań trybu rzeczywistego, jako Ŝe jak zostało to wspomniane wcześniej do lokalizacji tej tablicy takŝe i w tym trybie wykorzystywany jest rejestr IDTR, teraz załadowany wszak wartościami przystosowanymi do trybu chronionego. Dlatego zmianę zawartości rejestru IDTR oraz przełączenie trybu naleŝy dokonywać obowiązkowo przy zablokowanych przerwaniach. Ten fragment kodu musi być ponadto napisany wyjątkowo starannie, aby nie doszło takŝe do wygenerowania Ŝadnego wyjątku. Samo ustawienie flagi PE nie oznacza jeszcze końca inicjalizacji trybu chronionego. W trybie tym bowiem rejestry segmentowe zawierają selektory odpowiednich segmentów, podczas gdy bezpośrednio po przełączeniu jest w nich nadal to, co znajdowało się tam w trybie rzeczywistym, czyli numery początkowych paragrafów tychŝe segmentów. Wobec tego w pierwszej kolejności po zmianie bitu PE naleŝy zaktualizować zawartości rejestrów segmentowych. W przypadku rejestru CS ma to takŝe dodatkowe znaczenie. OtóŜ procesor wykonując program wczytuje na zapas rozkazy i je wstępnie dekoduje umieszczając w specjalnej kolejce, a dopiero z tej kolejki pobiera do realizacji. Przed włączeniem trybu chronionego część instrukcji która tak naprawdę miała się wykonać juŝ w tym trybie została wczytana i zinterpretowana jeszcze w trybie rzeczywistym. Instrukcje te naleŝy więc wczytać ponownie i zdekodować zgodnie z nowym obowiązującym trybem, co ma szczególne znaczenie przy włączonym stronicowaniu, gdzie adresy liniowe i fizyczne nie muszą być zgodne. Wyczyszczenie kolejki rozkazów i załadowanie rejestru CS odpowiednim selektorem moŝna wykonać naraz za pomocą rozkazu dalekiego skoku do następnej instrukcji. Niestety, niektóre asemblery (np. Turbo Assembler) przy natrafieniu na tego typu Instytut Informatyki, PŁ str. 15