0xcafebabe -- per aspera ad astra

Post przedstawia przykład, w jaki sposób działa prosty bootloader instalowany w sektorach MBR dysków – jakie ma zadanie, w jaki sposób przygotowuje procesor do rozmowy z kernelem (przełączanie w tryb chroniony) i dlaczego tak się dzieje.

Wybrana stara wersja bootloadera OpenBSD jest skutkiem trochę przypadku, być może trochę lenistwa, nie da się jednak zaprzeczyć, że plusem takiego rozwiązania jest mniej rzeczy, które trzeba na początku ogarnąć. Nowsze bootloadery korzystają z trochę innych metod adresowania danych na dysku, tj. linearnych adresów nazywanych LBA. Próbka bootloadera którą postaram się opisać używa starszej wersji: CHS, która do lokalizowania danych na dysku wykorzystuje takie parametry jak ścieżka, sektor i głowica. Swoją drogą był to standardowy mechanizm odczytu danych z dyskietki za pomocą int 13h, jeśli ktoś z czytających zajmował się kiedyś programowaniem w DOS'ie ;).

MBR jest skrótem od Master Boot Record i mieści się w pierwszym sektorze nośnika danych. W naszym przypadku nośnikiem danych jest dyskietka a.img dostępna na stronie emulatora Bochs. Jako, że jest to obraz dyskietki zapisany w pliku, nie można w 100% zachować zgodności wyglądu danych, z tego samego powodu dla którego na kartce papieru nie można narysować trójwymiarowej figury geometrycznej (i nie mam na myśli tutaj żadnego rodzaju rzutów prostokątnych). Dlatego też w późniejszej części posłużymy się prostym skryptem do tłumaczeń parametrów CHS na adres LBA, który pozwoli na odczytanie odpowiednich danych z odpowiednich miejsc obrazu dyskietki. Ale po kolei...

Na początku wiadomo już, że MBR to pierwsze 512 bajtów nośnika. Obraz pliku na dysku w tej kwestii wcale się nie różni, dlatego kod MBR można znaleźć pod offsetem 0.

Najłatwiej wyciągnąć kod z pliku za pomocą narzędzia dd, czyli należy odczytać 512 pierwszych bajtów nośnika i skierować dane do oddzielnego pliku:

Posiadając wyjęty plik można zacząć analizować co w nim się znajduje. Ale najpierw, trochę szybkiej teorii (dłuższa teoria będzie dostępna w formie dłuższego posta niebawem). BIOS po odczytaniu pierwszego sektora umieszcza go w pamięci fizycznej o adresie 07C0h:0000h (lub 0000h:7C00h – tak naprawdę zależy to od BIOSu jaki to jest adres, mimo tego, ze wskazuje na tą samą komórkę pamięci fizycznej, to stanowi to dość dużą różnicę, ponieważ tak naprawdę nie wiadomo jaka wartość znajduje się w rejestrze segmentowym CS, więc nie wiadomo z kolei czy np. będziemy w stanie wykonywać skoki bliskie, które mogą być wykonane jedynie w granicach tego samego segmentu). Kod wykonywalny działa w trybie rzeczywistym, więc domyślne operacje instrukcji będą używały trybu 16-bitowego, czy to podczas odwoływania się do pamięci, czy operacji na liczbach. Nie znaczy to, że w trybie rzeczywistym nie można korzystać z 32-bitowych rejestrów; wręcz przeciwnie – można to robić i ten bootloader w pewnym punkcie z nich skorzysta – jednak tryb rzeczywisty jest dość okrojonym trybem, w którym większość funkcji, z których korzystają dzisiejsze systemy operacyjne (GDT, uprzywilejowanie kodu, etc), jest wyłączona. Spowodowane jest to powodami historycznymi i polityką firmy Intel która nastawiona jest na zapewnienie kompatybilności wstecznej dla nowych procesorów. Nowe procesory zaczynają od starych funkcji, oferując możliwości zmiany trybów ze starszych na nowsze.

Adres linearny 07C0h:0000h (lub 0000h:7C00h) to inaczej adres fizyczny 0x7C00 i jest to czterysta dziewięćdziesiąty szósty kilobajt pamięci konwencjonalnej (posługując się nazewnictwem DOS). Dlaczego to jest akurat ten adres, nie inny, tego niestety nie wiem, ale decyzja zapadła w czasach procesorów typu Intel 8088 i maszyn IBM PC-1, które – z punktu widzenia dnia dzisiejszego – miały dość mocne ograniczenia, np. limitowanie pamięci do 544 kilobajtów. Jakkolwiek by nie było, musiał to być któryś adres ;), toteż zapewne padło na 0x7C00. Procesor uruchamiając kod MBR niektóre swoje mechanizmy ma już zainicjowane przez BIOS, aby program MBR nie był zdany tylko na siebie. Tak więc, przed uruchomieniem pierwszej instrukcji, MBR ma do dyspozycji tablicę wektorów przerwań (Interrupt Vector Table - IVT) trybu rzeczywistego (która różni się znacząco od tablicy przerwań trybu chronionego - IDT), funkcje BIOS (które potrafią rozmawiać ze sprzętem w taki sposób, jakby miały do niego „sterowniki” - oczywiście mam tutaj na myśli bardziej podstawowy sprzęt typu dysk twardy, a nie twój najnowszy tablet Wacom na USB ;>), oraz pewne ustandaryzowane (mniej więcej) struktury danych BIOS'u, o których należy pamiętać, choć głównie dlatego, aby ich nie nadpisać ;). Wszystko, co zrobimy w tym kodzie, musi być wykonalne przy użyciu 512 bajtów i ani jednego bajta więcej – w tą liczbę wchodzi zarówno kod jak i dane, więc wyświetlanie napisów łatwych do zrozumienia przez człowieka jest dość kosztowne (w miejsce, nie czas). Ciężko jest w 512 bajtach upchać kod, który odczyta z dysku o nieznanym systemie plików kernel, następnie zaopatrzy go w jego środowisko, być może również konfigurację i odda mu kontrolę, dlatego zdecydowana większość kodów MBR stosuje mechanizm „stage'owania”, czyli podziału kodu MBR na dwie części. Pierwsza znajduje się w pierwszym sektorze nośnika, a druga część w dalszej części nośnika. Druga część nie ma już ograniczenia 512 bajtów i dlatego generalnie pracą części pierwszej (nazywanej stage1) jest po prostu załadowanie części drugiej (stage2) przy użyciu funkcji dostępu do dysku, w które zaopatrzy BIOS.

Wracając do praktyki, sprawdźmy co znajduje się w pliku stage1. Sprawdźmy offset 0:

Znajduje się tutaj skok niżej, do offsetu 0x3E. Wstawiony jest po to, aby przestrzeń (oznaczona na powyższym listingu jako […]) mogła zawierać jakieś binarne dane, które po prostu wyglądają na dane binarne ;), a konkretnie są zgodne ze standardową notacją struktury BIOS Parameter Block (BPB). Nie są one wykorzystywane w stage1, prawdopodobnie kod stage2 z nich korzysta, być może korzystać z nich BIOS, więc zostaną one pominięte. Być może też niektóre wersje BIOSu sprawdzają występowanie tego skoku, więc dodany jest on tutaj zapewne w celu zwiększenia kompatybilności z tymi wersjami.

Offset 0x3E zawiera skok daleki. Można zauważyć tutaj różnicę w ilości bajtów wykorzystywanych przez daleki skok i skok bliski, spod offsetu zerowego. Skok daleki różni się od bliskiego ilością bajtów wykorzystanych do enkodowania instrukcji (skok bliski – 2 bajty, daleki – 7 bajtów), jak i też tym, że tylko skok daleki potrafi skoczyć poza granice aktualnego segmentu. Dodatkowo, tutaj instrukcja skoku zawiera też prefiks zmieniający rozmiar adresowania argumentu – prefix 0x66 – który w tym przypadku pozwala na skok do adresu 0x00000053 segmentu 0x07C0. Nie brzmi to logicznie ;), ponieważ przecież kod działa w trybie 16-bitowym, więc co najwyżej można skoczyć pod adres IP 0x0053. Tryb 16-bitowy nie uniemożliwia jednak korzystania z 32-bitowych rejestrów, więc ustalenie przy pomocy skoku rejestru EIP na wartość 0x00000053 jest całkowicie możliwe. Zapewne jednak nie chodzi tutaj o wyzerowanie górnej części rejestru EIP, ale o wymuszenie dłuższej notacji zapisu skoku, aby w pliku znajdowało się więcej bajtów, które w prostu sposób można spatchować przy użyciu programu instalującego MBR. Przy okazji daleki skok ustawia rejestr segmentowy kodu (CS) na 0x07C0, dzięki czemu adres bazowy kodu w pamięci będzie zgodny z adresem bazowym załadowanego przez nas pliku, który liczony jest od zera. Dzięki temu nie trzeba wykorzystywać relokacji podczas adresowania bezwzględnego, ponieważ dokładnie wiemy pod którym adresem będzie która wartość w pamięci. Skok taki jest też częścią konwencji „dobrego wychowania” kodu MBR, ponieważ teraz wiadomo, jaką wartość ma rejestr segmentowy CS. To, co znalazło się tam wcześniej (0x7C00? Czy może 0x0000?), wynikało z dobrej chęci BIOS'u, lecz to, co dobre dla jednego nie musi być dobre dla drugiego ;), dlatego więc zamiast ślepo wierzyć, że w CS znajduje się wartość taka jak w środowisku testowym twórcy MBR, należy się po prostu upewnić wrzucając tam swoją wartość, czyli 0x7C0.

Są dwie wersje interpretacji powyższego kawałka kodu. Pierwsza będzie taka, w jaki sposób myślał twórca, druga natomiast będzie krótkim wyjaśnieniem, dlaczego się mylił. ;)

CLI i STI to instrukcje odpowiedzialne za odpowiednio: wyłączanie i włączanie obsługi przerwań. Temat przerwań to swój własny temat i wychodzi nieco poza ramy tego posta, być może uda mi się go opisać nieco bliżej w przyszłości, choć na chwilę obecną wystarczy fakt, że włączone przerwania nie gwarantują ciągłości uruchomienia kodu. Ten brak gwarancji nie wpływa na gwarancję wykonania kodu (czyli wszystkie instrukcje na pewno zostaną uruchomione w podanej kolejności, oczywiście), ale przy włączonych przerwaniach kod może być wykonany nieco później niż natychmiast. Jedno z przerwań jest wywoływane wiele razy na sekundę i często przerywa działanie aktualnie wykonywanego kodu (stąd pochodzi nazwa przerwań). Struktury danych wskazujące na kod odpowiedzialny za jego obsługę został zainicjowany przez BIOS (pod adresem fizycznym 0 – czyli IVT) i po zakończeniu obsługi przerwania procesor wraca w miejsce, od którego został brutalnie odciągnięty. Problem w tym, że podczas rozpoczęcia mechanizmu oderwania się od pierwotnego kodu, gdy za chwilę ma rozpocząć się proces odczytu IVT i decyzji który adres ma zostać uruchomiony następnie aby móc obsłużyć przerwanie, procesor na aktualny stos wpycha aktualną wartość rejestru segmentowego CS i rejestru EIP. Można sobie wyobrazić więc, co się może stać gdy nadejdzie jakieś żądanie przerwania podczas gdy procesor właśnie skończy wykonywać instrukcję spod adresu 56 – żądanie przerwania zmusi go do odłożenia CS i EIP na stos, ale który stos? Rejestr SS został właśnie wyzerowany, więc para SS:SP wskazuje na błędny adres. Operacja umieszczania CS i EIP na stos nie powiedzie się więc i kolejny słodki kociak straci życie. :P

Para instrukcji CLI i STI rozwiązuje ten problem, ponieważ gwarantuje, że większość przerwań nie zostanie obsłużona przez procesor (zostaną zakolejkowane i obsłużone gdy już będzie można). Te, które zgłoszą żądanie obsługi nazywane są przerwaniami niemaskowalnymi, non-maskable interrupts (NMI) i po części nie trzeba się przejmować uszkodzonym stosem podczas gdy takie przerwanie nadejdzie, ponieważ prawdopodobnie procesor wykrył problem z hardware, więc problem ze stosem jest najmniejszym aktualnym problemem ;).

Tego, czego nie przewidział twórca (lub nie doczytał), to fakt, że inżynierowie w Intelu przewidzieli problem zmiany segmentu stosu i to, że zmiana ta wiąże się z koniecznością wykonania dwóch operacji w atomowy (nieprzerwany) sposób. Dlatego też procesor automatycznie wyłącza żądania przerwań po napotkaniu instrukcji MOV, gdy rejestrem docelowym jest SS. Zaraz potem, po wykonaniu kolejnej instrukcji, żądania przerwań włącza ponownie. Dlatego kod powyżej wygląda tak, gdyby miał dwie pary instrukcji CLI prawie zaraz po sobie (rozdzielone instrukcją xorw %ax,%ax), a niżej dwie pary instrukcji STI. Pomijam zupełnie fakt, że sam Intel do zmiany segmentu stosu przygotował instrukcję LSS, która w ogóle nie musi wyłączać żądań przerwań. Dobra strona jest tego taka, że dodatkowe pary CLI/STI nie szkodzą.

Pomijając powyższe wywody, ustawiany jest wskaźnik stosu na adres 0000h:FFFCh, który znajduje się w przedziale pamięci – zgodnie z organizacją mapy pamięci – gwarantowanej dla takich programów, jak kod MBR (lub DOS).

Kolejne instrukcje to ustalanie stałej wartości dla wszystkich rejestrów segmentowych (oprócz CS, który jest już ustawiony przez daleki skok pod offsetem 0x3E). Widać tutaj, że kod tego MBR kierowany jest do procesorów 386 lub wyższych, z uwagi na wykorzystanie rejestrów segmentowych FS i GS, których w oryginalnym trybie rzeczywistym 8086 nie ma. Tak czy inaczej, ustalenie rejestru DS na odpowiednią wartość będzie gwarantować poprawne działanie wszystkich operacji odczytu z pamięci, ponieważ będą odwoływały się do segmentu, w którym istnieje kod MBR.

Następuje tutaj ustawienie liczby 0x46 do rejestru ESI (swoją drogą, kolejny dowód na to, że kod jest kierowany pod 386. Takich przykładów będzie więcej) i wywołanie pewnej funkcji spod adresu 0x130.

W końcu jakiś kawałek kodu który posiada więcej niż kilka linijek :). Przede wszystkim, pushl %eax odkłada na stos rejestr EAX, który będzie przywrócony przy wyjściu. Dzieje się tak, by funkcja wróciła do poprzedniego miejsca oddając rejestr EAX w takim stanie, w jakim go dostała. Następnie instrukcja CLD zeruje flagę w procesorze o nazwie direction flag, która wpływa na działanie takich instrukcji jak LODSB poniżej. Przeciwieństwem instrukcji CLD jest STD, która ustawia tą flagę. LODSB do rejestru AL wczytuje bajt spod adresu pamięci, na który wskazuje rejestr SI z segmentu DS, a następnie zwiększa SI o jeden, gdy flaga direction flag jest wyzerowana, lub zmniejsza SI o jeden, gdy flaga direction flag jest ustawiona.

Offsety 0x134 i 0x136 sprawdzają, czy wczytany bajt jest równy zeru. Jeśli tak, zostaje wykonany skok pod adres 0x14A, który zdejmuje EAX ze stosu i wychodzi z funkcji.

Offset 0x138 to wywołanie kolejnej funkcji spod adresu 0x13D, a zaraz po tym wywołaniu następuje skok w górę (czyli jest to pętla), do adresu 0x133, który ponownie wczytuje kolejny bajt z pamięci wskazywanej przez DS:SI, który niedawno został zwiększony o 1.

Z tego wynika, że funkcja wyjdzie tylko wtedy, gdy w pamięci wskazywanej przez DS:SI znajdzie się w końcu 0. Dla każdej innej wartości wywoływana jest funkcja z adresu 0x13D, należałoby sprawdzić więc, co robi.

Na początku zachowywane są rejestry EAX i EBX, aby mogły być przywrócone pod koniec funkcji. Następnie, offsety 0x141, 0x143 i 0x145 ustawiają odpowiednio rejestr AH na 0x0E i BX na 1. Instrukcja spod adresu 0x146 wywoła przerwanie programowe o numerze 0x10. Aby dowiedzieć się, co robi to przerwanie, najlepiej zajrzeć do jakichś zasobów w internecie z listą przerwań i ich opisem. Najbardziej znana jest lista przerwań Ralpha Browna, która mówi o tym, że przerwanie software'owe 0x10 przy zawartości rejestru AH=0x0E oznacza wypisanie znaku na ekranie. Tym też zajmuje się ta funkcja, będąca usługą oferowaną przez BIOS – wyświetlaniem znaku z argumentu AL na ekran. Razem z poprzednią funkcją wypisuje na ekran ciąg bajtów zakończony zerem. Ciąg bajtów precyzowany jest przy pomocy rejestru ESI, który w momencie wywołania tej funkcji zawierał adres 0x46. Należałoby sprawdzić więc, co znajduje się pod tym adresem:

Chodzi więc o wyświetlenie napisu „reading boot” :). Wróćmy więc do adresu 0x70, a raczej do tego, co znajduje się za nim.

Te trzy instrukcje zajmują się inicjowaniem rejestrów do dalszych operacji. Rejestr segmentowy ES jest ustawiany na 0x4000, natomiast EBX jest całkowicie zerowany. W tej chwili operacje mogą sprawiać wrażenie mało ważnych, ale przyjmą na wartości w dalszej części kodu – ponieważ tutaj zaczyna się ładowanie kodu stage2 z innych sektorów na nośniku.

Pierwsza instrukcja do rejestru CL kopiuje wartość, która znajduje się w pamięci pod adresem 0x16E z segmentu wskazywanego przez rejestr DS (czyli ustawione wcześniej 0x7c0, pod offsetem 0x62). Znajduje się tam liczba 7. Liczba ta stanie się ilością powtórzeń pętli, do której zaraz wejdzie program, o czym zaraz będzie można się dowiedzieć. Ciekawe jest użycie tej instrukcji przy wykorzystaniu prefiksu 0x67, który działa podobnie jak prefix 0x66 przy instrukcji ljmpl pod offsetem 0x3E – wydłuża ilość bajtów wskazujących na adres, do którego instrukcja ma się odwoływać. Sugerowałoby to kolejne miejsce, które jest patchowane przez instalator kodu MBR, a więc zapewne owa liczba 7 jest pewnym parametrem charakterystycznym dla aktualnego nośnika. Następnie, MOVZBW zeruje górną część rejestru CX; w tym przypadku instrukcja jest równoznaczna z MOV CH, 0.

Do rejestru SI trafia liczba 0x16F.

Jak się okaże w późniejszej części, instrukcja odłożenia na stos CX rozpoczyna pętlę ładowania kolejnej części kodu MBR.

Znowu jest tutaj wywołanie funkcji spod adresu 0x13d, a wiadomo już, że ta funkcja wyświetla na ekranie znak z argumentu AL. W tym przypadku jest to kropka i zapewne jest ona wyświetlana na ekranie jako swojego rodzaju pasek postępu :).

Kolejny dłuższy wycinek kodu rozpoczyna zerowanie flagi direction flag. Za tym znajdują się trzy wywołania instrukcji lods – jedna z sufiksem w, dwie kolejne z sufiksami b. lodsw odczytuje dwa bajty pamięci z DS:SI, zwiększając SI o 2, wynik zapisując w AX. Innymi słowy, w pierwszej iteracji, do AX ładowana jest zawartość pamięci spod adresu 07C0h:016Fh – jest to liczba 0x209. Następne wywołanie lodsb będzie odczytywało pamięć spod adresu 07C0h:0171h i odczyta bajt do adresu AL – czyli zero, który zostanie przeniesiony do rejestru DH. Kolejne wywołanie lodsb odczyta bajt z adresu 07C0h:0172h i zapisze wynik (liczbę 10) do rejestru AL. Offset 0x96 to instrukcja zapisująca wartość 2 do rejestru AH, następnie następuje zachowanie AX na stosie i wykonanie programowego przerwania numer 0x13. Zgodnie z listą przerwań Ralpha Browna, przerwanie programowe 0x13 przy wartości rejestru AH=2 oznacza odczyt z nośnika, przy wykorzystaniu adresowania CHS.

Tutaj wchodzi do gry mój komentarz, o translacji CHS na LBA. Jako, że posiadamy jedynie obraz dyskietki, mamy dwie opcje, aby dowiedzieć się, jakie dane są odczytywane. Pierwsza opcja to nagranie obrazu na dyskietkę i posłużenie się tą samą funkcją BIOS, lub odpowiednimi narzędziami, do odczytania danych ze sprecyzowanego miejsca. Druga opcja to przekształcenie adresowania CHS na LBA i odczytanie danych bezpośrednio z pliku. Druga opcja wbrew pozorom jest zdecydowanie szybsza, dlatego poświęcę na nią kilka słów.

Adresowanie CHS polega na lokalizowaniu danych na urządzeniu przy pomocy kilku argumentów: ścieżki, sektora, głowicy i urządzenia. Każdy sektor ma 512 bajtów, każda ścieżka ma 18 sektorów, każdy sektor może mieć dwie głowice (lub dwie strony). Programowe przerwanie 0x13, czyli funkcja BIOS, gdzie AH=2, oczekuje konkretnych wartości w różnych rejestrach. I tak, np. przy pierwszej iteracji pętli stan rejestrów prezentuje się w taki sposób:

AH ← 2, AL ← 10, CH ← 2, CL ← 9, DH ← 0, DL ← 0

AL jest to ilość sektorów do przeczytania (10), AH to numer funkcji (2), CL to numer sektora (9), CH to numer ścieżki (2), DH to numer głowicy (0), DL to numer urządzenia (0), natomiast ES:BX wskazuje na miejsce w pamięci, która ma otrzymać odczytane dane. Dla przypomnienia, rejestr ES zawiera 0x4000, natomiast BX jest wyzerowany. Ilość danych do odczytania w bajtach to iloczyn ilości sektorów do przeczytania (czyli rejestr AL przed wywołaniem int 13h) i liczby 512, bo każdy sektor ma 512 bajtów.

Natomiast LBA jest to po prostu numer, tak jak adres w pliku, adres w pamięci, numer do danych które chcą być przeczytane. Zamiana CHS na LBA następuje przy pomocy wzoru:

LBA ← (ścieżka * ilość głowic + głowica) * ilość sektorów + sektor – 1

Niektóre dane to stałe, za które w naszym przypadku można wstawić liczby:

LBA ← (ścieżka * 2 + głowica) * 18 + sektor - 1

Pozostałe trzy zmienne posiadamy, więc konwersja na LBA ogranicza się do wykonania kilku mnożeń i sumowań. Wynikiem będzie liczba, będąca adresem LBA. Offset w pliku można uzyskać mnożąc LBA przez 512, ponieważ 1 LBA = 512 bajtów. Wyciąganiem pliku stage2 zajmiemy się potem, teraz wróćmy do poprzedniego kodu, do offsetu 0x9b. Instrukcja warunkowego skoku JAE zostanie wykonana, gdy flaga C będzie zgaszona. Funkcja int 13h AH=2 ustawia flagę C w przypadku, gdy napotka błąd (np. bad sector na nośniku), co spowoduje wykonanie kodu:

Napis pod adresem 0xA8 to napis „Read error.” - wyświetlany w przypadku napotkania błędu działania funkcji 13h AH=2. Po wyświetleniu napisu następuje skok do offsetu 0xE2, wyłączenie obsługi przerwań i wykonanie instrukcji HLT. Instrukcja ta zatrzymuje działanie procesora aż do momentu w którym nie wystąpi jakieś przerwanie. Poprzednia instrukcja wyłącza większość przerwań (z wyjątkiem niemaskowalnych, jak wspomniałem wyżej), dlatego też HLT nigdy nie będzie przerwane. Kombinacja instrukcji CLI/HLT skutecznie „zawiesza” komputer, bo w przypadku, gdy nie można załadować MBR stage2 nie ma sensu kontynuować działania, bo co wtedy robić? ;) Problem z kombinacją takich instrukcji jest taki, że nie będzie można zrestartować komputera za pomocą Ctrl+Alt+Del. Aby ominąć tą niedogodność, należałoby ustawić tablicę IVT aby móc pobierać przerwania klawiatury i odpowiednio zareagować. Wtedy działająca w pętli instrukcja HLT pełniłaby rolę blokady procesora w czasie, gdy nie ma żadnego przerwania.

W przypadku gdy błąd odczytu nie nastapi, zostanie wykonany ten kod.

Najpierw zostaje odzyskane AX, zachowane w offsecie 0x98, następnie cały rejestr EAX zostaje wyzerowany z wyjątkiem zawartości AL. W EAX zostaje więc sam rozmiar danych (czyli liczba 10), które ostatni int 13h AH=2 odczytał z nośnika. Instrukcja shlw spod offsetu 0xBC jest w tym przypadku równoznaczna z mnożeniem przez 512; w tym przypadku rozmiar danych jest mnożony przez 512 aby obliczyć rozmiar bajtowy dziesięciu sektorów. W końcu rejestr BX jest zwiększany o tą liczbę. Następuje odzysk CX (zachowany pod offsetem 0x88) i wykonuje się instrukcja LOOPW, która zmniejsza CX o 1 i w przypadku, gdy nie jest zerem, skacze do offsetu 0x88.

Kolejna iteracja pętli odczyta kolejne dane z pamięci wskazywanej przez rejestr SI; te dane są parametrami CHS do odczytania kolejnych partii kodu stage2 z nośnika startowego. Jest razem 7 partii, które odczytywane są w pamięci jeden za drugim (po odczytaniu danych rejestr BX zwiększa się o odczytane dane; po zwiększeniu BX wskazuje na koniec danych, które zostały przed chwilą przeczytane. Kolejny odczyt umieści dane w miejscu końca poprzednich danych, i tak 6 razy). Po wyjęciu danych z SI i zinterpretowaniu ich, widać dokładnie, że stage2 ładowany jest z tych miejsc w nośniku:

Dla ułatwienia sobie pracy z CHS postanowiłem napisać szybki skrypt w Ruby, który obliczy mi wszystkie dane potrzebne do wyjęcia z pliku a.img odpowiedniej porcji danych będących kodem stage2 przy pomocy programu dd. Oto kod skryptu (lub też link do pliku):

Oto z kolei wynik jego działania:

Przekonwertowane offsety wykazują charakterystykę ciągłą, co by sugerowało, że metoda konwersji jest poprawna ;). Ostatnia linijka, skip=80 count=96 to argumenty programu dd, które pomogą wyciągnąc stage2 z a.img:

Plik stage2 ma 49 kilobajtów. Mamy więc plik stage2, ale kod stage1 nie jest jeszcze zakończony, dlatego wróćmy do kodu. Po zakończonej pętli, działanie dochodzi do tego momentu:

Jest to wyświetlanie na ekranie pustej linii. Poprzednia pętla z każdą iteracją wyświetlała kropkę, która zapewne słuzyła w celach debugowych, gdyby stage1 napotkał błędny sektor podczas odczytu stage2. Ilość kropek na ekranie mówiłaby o tym, który sektor jest błędny. Stawiając znak końca linii po kropkach autorzy widocznie kierowali się estetyką ;).

Następuje zerowanie rejestru SI, zerowanie flagi direction flag (aby można było bez problemu używać instrukcji pokroju LODS) i nastepuje odczyt czterech bajtów z adresu ES:SI, czyli z początku danych stage2: najpierw dwóch do rejestru AX, potem znowu dwóch, znowu do rejestru AX. Skutek tego jest taki, że pierwsze dwa bajty zostają pominięte, a w rejestrze AX znajdują się kolejne dwa bajty, czyli trzeci i czwarty. Bajty te porównywane są z wartością 0x10B. Jeśi wartość ta jest inna, następuje przejście do offsetu 0xD9, gdzie znajduje się kod wyświetlający na ekranie „Bad magic.”, po czym kombinacja instrukcji CLI/HLT zawiesza komputer:

Jest to krótkie i prymitywne sprawdzanie integralności stage2, aby nie załadować nieznanych danych. Krótkie, bo złożone tylko z jednego sprawdzenia, i prymitywne, ponieważ nie ma gwarancji, że dalsza część danych jest równie poprawna co sam początek. Lepsze byłoby sprawdzenie sumy kontrolnej wszystkich odczytanych danych, ale z drugiej strony każdy kod ładujący MBR można napisać na milion różnych sposobów ;) (choć te cechy charakterystyczne dla danej architektury muszą oczywiście zostać te same).

Offset 0xF0 jest osiągany, gdy magiczna wartość 0x130 znajduje się na swoim miejscu. Można łatwo sprawdzić, czy posiadamy właściwy stage2:

Bajt trzeci i czwarty rzeczywiście buduje wartość 0x10b, więc wygląda na to, że plik jest prawidłowy. Wracając do instrukcji CLI – wyłącza ona obsługę przerwań. Jako, że za chwilę znajdą się instrukcje przełączające tryb na tryb chroniony, należy upewnić się, że proces nie zostanie przerwany w połowie i procesor nie znajdzie się w nieokreślonym stanie. Bez tej instrukcji prawdopodobnie proces bootowania byłby w pewnym sensie grą w rosyjską ruletkę, raz komputer wstanie, raz będzie trupem, aż do wykonania resetu oczywiście ;).

Wywoływana jest instrukcja LGDTL. Instrukcja ta zaopartuje wewnętrzny rejestr procesora GDTR w adres do struktury nazywanej GDT. Jest to struktura wykorzystywana w trybie chronionym, zawierająca definicje (adresy i ich rozmiary) regionów pamięci, które tworzą segmenty trybu chronionego. Te z kolei są nieco wyższą formą segmentacji pamięci niż segmenty trybu rzeczywistego, oferującymi lepsze metody izolacji pamięci i precyzowanie stopnia uprzywilejowania kodu wykonywanego w danym segmencie (czyli pojawia się tutaj podział na pierścienie; pierścień zerowy dla jądra, pierścień trzeci dla aplikacji). Opis jest dość krótki, na chwilę obecną, ponieważ temat GDT jest nieco szerszy, aby zmieścił się w ramach tego posta. Planuję opisać GDT jak i siostrzane struktury, LDT i IDT, kolejnym razem, aby nieco szerzej opisać sposób działania trybu chronionego. W chwili obecnej ciekawe jest wykorzystanie instrukcji charakterystycznej dla trybu chronionego, w trybie rzeczywistym. Okazuje się, że rejestr GDTR nie jest zablokowany przez procesor, gdy znajduje się w trybie rzeczywistym, tylko jest po prostu niewykorzystany, dlatego możliwe jest zapisanie do niego odpowiednich danych, przygotowując jego zawartość na przełączenie trybu.

Adres 0x168 wskazuje na strukturę, która jest złożeniem adresu bazowego konkretnej struktury GDT i jej rozmiaru (jest to struktura GDTR procesora w trybie IA-32; podczas trybu IA-32e, lub Long Mode w AMD, zmienna 'base' staje się zmienną 64-bitową, uint64_t):

Pytanie brzmi dlaczego wykorzystywana jest struktura trybu chronionego IA-32, skoro nie jesteśmy w tym trybie, zamiast tego jesteśmy w trybie rzeczywistym? Odpowiedzią jest prefiks 0x67, który pozwala na zwiększenie rozmiaru adresowania argumentu instrukcji do 32-bitów (poczas pracy w kodzie 16-bitowym; gdyby użyć tego prefiksu na instrukcji podczas pracy w kodzie 32-bitowym, prefiks zmniejszyłby tryb adresowania na 16-bitowy), jak też i prefiks 0x66, który zmienia „długość” instrukcji z 16-bitów na 32-bity.

Są to więc te dane 18 00 50 7d 00 00 spod offsetu 0x168:

Zgodnie z wyglądem struktury powyżej, pierwsze dwa bajty do wielkość tablicy GDT, kolejne 4 bajty to wskaźnik do struktury GDT. Zgodnie z notacją little-endian, bajty zostają zapisane do wartości w sposób odwrotny do tego, jak wyglądają w pamięci, dlatego też do rozmiaru wskakuje liczba 0x18, a do bazy adresu adrse 0000h:7D50h. Po konwersji tego adresu na coś bardziej kompatybilnego ze środowiskiem, z którego odczytujemy struktury danych (plik), czyli na segment 0x07C0, otrzymujemy adres 07C0h:0150h:

Pod tym offsetem w pliku znajduje się struktura tablicy GDT, którą możemy podejrzeć:

Mamy więc tutaj ustawione dwa segmenty (nie licząc segmentu o selektorze zerowym, który musi być wyzerowany i nie można się do niego odnieść): segment o selektorze 0x0008 i 0x0010. Ten pierwszy posiada charakterystykę trybu 32-bitowego kodu o DPL (descriptor privillege level) równym 0, co oznacza kod najbardziej uprzywilejowany – ring 0 – oraz prawa oznaczone flagami: do odczytu, zapisu i do wykonania. Jako, że istnieje flaga „do wykonania”, sugeruje to segment który będzie pozwalał na wykonywanie kodu, dlatego został przeze mnie oznaczony jako „segment kodu”. Kolejny segment posiada prawie identyczne wartości (nawet bazy adresowe), z wyjątkiem praw dostępu – tutaj nie ma już praw „do wykonania”, jedynie są „do odczytu” i „do zapisu”. To sugeruje segment danych, i tak też został przeze mnie oznaczony w komentarzu. Skoro wiadomo już jak wygląda tablica GDT, możemy wrócić do kodu MBR.

Ustawienie rejestru GDTR na wskaźnik do prawidłowej struktury GDT jest jedną z rzeczy, które należy zrobić, aby poprawnie przełączyć tryb działania procesora do trybu chronionego. Zwykle kod ładujący (typu właśnie kod MBR, stage którykolwiek), oddzielny moduł rozruchowy systemu operacyjnego, czy nawet sam kernel, mają w konwencji podczas swojego uruchamiania (lub działania) budować wiele tablic GDT, precyzując przy tym wiele różnych konfiguracji segmentów. Pierwsze struktury GDT nazywane są wtedy tymczasowymi strukturami, które ustępują w późniejszym czasie tym głównym, zbudowanym do pracy przy nastawieniu się na inny wymóg pracy kernela – z trybu ładującego na tryb użytkowy.

Powyższy kod ustawia bit 1 rejestru kontrolnego, CR0, na 1. Rejestry kontrolne to standardowy mechanizm kontroli wielu aspektów działania procesora w trybie chronionym i innych trybach (np. trybie długim, czyli 64bit). Bit pierwszy w rejestrze CR0 oznacza włączenie trybu chronionego. Długi skok zaraz po uaktualnieniu rejestru CR0 służy do trzech rzeczy: zmiany trybu adresowania (zamiast rejestru IP będzie wykorzystany już rejestr EIP), zaktualizowania rejestru CS zmieniając istniejący tam do tej pory segment 0x07C0 na selektor 0x0008, który od momentu skoku będzie indeksem do deskryptora w tablicy GDT, oraz do odświeżenia kolejki prefetch, do tej pory obładowanej instrukcjami real-mode. Nie można użyć tutaj drugiego selektora, 0x0010, ponieważ nie udostępnia on praw wykonywania kodu w swoim kontekście, z tego powodu wybrany jest selektor 0x0008.

Wykonując skok pod 0008h:00007D0Ch zostaniemy przełączeni w tryb 32-bitowego adresowania instrukcji. Wielkość adresu przestanie być reprezentowana przez 16-bitowe wartości segment:przemieszczenie, będzie za to adresowana jako 16-bitowy selektor i 32-bitowy adres. Tryb instrukcji również uległ zmianie – poprzednio każda instrukcja była wywoływana w kontekście 16-bitowym, a teraz – zgodnie z odpowiednią flagą „32bit” w charakterystyce selektora 0x0008, będzie to w końcu kod 32-bitowy. Zmienią się więc też funkcjonalności prefiksów 0x66 i 0x67, których kod MBR wykorzystuje kilka razy w swojej logice, tzn. wcześniej zamieniały one adresowanie 16-bit na 32-bit, a teraz – jeśli będą użyte – zmienią adresowanie 32-bit na 16-bit. Można więc wrócić do kodu, jednak trzeba uruchomić nową deasemblację (lub utworzyć nowy 32-bitowy segment, jeśli korzysta się z programu IDA), która będzie deasemblowała kod w trybie 32-bit, nie 16-bit, jak do tej pory.

Skok następuje do adresu 0x7D0C. Aby zamienić ten offset na offset w pliku, należy wyobrazić sobie, że plik załadowany jest pod offset 0x7C00. Wtedy wystarczy prosta operacja odejmowania, by przekonać się o tym, że offset w pliku odpowiadający offsetowi 0x7D0C to 0x10C.

Powyższy kod ustawia selektor 0x0010 do wszystkich rejestrów segmentowych (z wyjątkiem CS, który ma już 0x0008): DS, SS, ES, FS i GS. Rejestr segmentowy SS może być aktualizowany bez obaw o występujące przerwanie zaraz po jego modyfikacji, a przed modyfikacją ESP, ponieważ offset 0xF0 nieco wcześniej ułatwia nam zadanie wyłączając obsługę przerwań.

Ustalenie adresu stosu, przeniesienie wartości rejestru DL do EAX (rejestr DL przez cały ten czas zawiera informacje o aktualnym napędzie, z którego został uruchomiony kod MBR), ułożenie na stosie rejestrów EAX i wartości 0xC001D00D :), która zapewne pełni rolę jakiejś magicznej wartości sprawdzanej przez stage2, być może po to, by upewnić się, że załadował ją dokładnie ten kod MBR, a nie jakiś generyczny. Następnie zostaje wykonany skok do adresu 0x40020 selektora 0x0008 (czyli nadal kontekst kodu wykonywalnego 32bit, ring 0), czyli do załadowanego wcześniej stage2. Wcześniej ładowanie odbywało się do pamięci o adresie trybu rzeczywistego 4000h:0000h, co można przetłumaczyć na adres liniowy pamięci płaskiej 0x40000 (segment << 4 + offset → 4000h << 4 + 0000h = 40000h), co by znaczyło, że kod zostaje przeniesiony pod offset 0x20 do stage2.

Ile tekstu można napisać na temat mniej niż 512 bajtów? :) Zapewniam, że nie ma tu wszystkich informacji, które można znaleźć jedynie wtedy, gdy się tego bardzo chce, czyli np. czytając manuale Intela lub AMD, których linki podane są na samym końcu posta (czyli za chwilę). Kod stage2 ma prawie 50 kilobajtów, więc można sobie wyobrazić, by opisać go na takim samym poziomie szczegółów co kod stage1, trzeba by napisać dość grubą książkę, na co niestety nie mam aż tyle czasu ;). Zerknijmy jednak na sam początek kodu stage2, pod adres 0x40020 (czyli w pliku 0x20):

Jako pierwsza rzecz, zostaje wykonana funkcja 0x5C10. Sprawdźmy więc, co robi:

Wynika z tego, że ustawia nowy GDT za pomocą lgdtl, wykonuje daleki skok, który trzeba wykonać po ustawieniu nowego GDT (by wyczyścić cache dotyczącego różnych aspektów różnych prac procesora – ten skok skacze do adresu 0x5C1E, czyli do następnej instrukcji), ustawia selektor 0x10 do rejestrów segmentowych oprócz CS (ponieważ CS ustawiony jest przy skoku z offsetu 0x5C17) i używa instrukcji lidtl, aby załadować do rejestru IDTR adres, który wskazuje na tablicę IDT. Tablica IDT jest dość podobna do GDT, jej funkcja jest jednak zupełnie inna – jest to tablica służąca do tego samego co IVT w trybie rzeczywistym, jednak działa ona w trybie chronionym. Zajmuje się więc zapisywaniem informacji o funkcjach, które będą reagować na przerwania.

Znajdujemy się teraz w kodzie, który może nie mieć ustawionej tablicy przerwań, ponieważ instrukcja CLI spod offsetu 0xF0 ze stage1 zaopatrzyła początek kodu stage2 w luksus wyłączonej obsługi przerwań. Niebawem zapewne przerwania zostaną włączone ponownie, skoro stan trybu chronionego jest w większości już zainicjowany poprawnie. Brakuje tylko ustawienia aktualnego Task'a i inicjacji rejestru TR (Task Register), i włączenia stronicowania w kodzie, który znajduje się gdzieś w głębinach kodu stage2 ;).

Z ciekawości co robi liczba 0xCOO1D00D dołączam też ten kod tutaj, który – jak się okazuje – nic nie robi ;), ponieważ sprawdza występowanie tego argumentu, a zaraz potem wykonuje skok do następnej instrukcji. Stąd prosty wniosek jest taki, że wartość ta prawdopodobnie znaczy coś w kompilacjach debug kodu stage2, który być może uaktywnia pewne powolne, ale przydatne dla debugowania podsystemy, lub wypisuje na ekranie jakieś informacje. Jako, że kod który analizuję teraz jest skompilowany w postaci RELEASE, nie DEBUG (ponieważ jest to normalny kod normalnej dystrybucji, faktem jest że starej, ale nawet w 1998 roku wiedzieli na czym polega różnica pomiędzy RELEASE a DEBUG :>), kod prawdopodobnie nie został wkompilowany, więc trzeba obejść się bez zjedzenia tej intelektualnej czekolady :P.

Kolejne instrukcje już pominę, aby nie wgłębiać się zbytnio w ten kod. Procesor działa już w trybie chronionym, a to, co zostało do zrobienia opiszę w kolejnym poście na podobny temat za jakiś czas. Nie jest to krytyczna funkcjonalność, ponieważ zawsze zostanie coś do zrobienia póki kernel nie zostanie całkowicie uruchomiony, co może czasem zając tysiące linii kodu ;), więc wystarczy napisać, że podstawę przełączania trybu chronionego mamy już za sobą. Teraz należałoby włączyć obsługę Tasków, stronicowania i być może zacząć inicjowanie kolejnych core'ów w procesorze, by mieć potem podstawę do rozpoczęcia inicjacji schedulera procesów, wykonywania context switchów, etc. ;)

Polecane materiały: AMD64 Architecture Programmer's Manual Volume 2: System Programming, Intel® 64 and IA-32 Architectures Software Developer's Manual Volume 3A: System Programming Guide, Part 1 & Part 2, OSDEV wiki, źródła bootloaderów, np. GRUB, lub innych (nawet tego który masz aktualnie zainstalowany w sektorze 0), Ralph Brown Interrupt List, i Google lub Bing ;)