Architektura i projektowanie

Z punktu widzenia ochrony, Architektura x86 opiera się na hierarchicznych pierścieniach, zgodnie z którymi cała przestrzeń wykonania dostarczana przez procesor jest podzielona na cztery hierarchiczne domeny ochrony , z których każda ma przypisany własny poziom uprawnień. Ten projekt zakłada, że większość kodu czasowego będzie wykonywana w najmniej uprzywilejowanej domenie, a czasami wymagane będą usługi z bardziej uprzywilejowanej domeny bezpieczeństwa i te usługi uprzedzą mniej uprzywilejowane działania na stosie, a następnie przywrócą je w taki sposób, że całe uprzedzenie będzie niewidoczne dla mniej uprzywilejowanego kodu.

Konstrukcja hierarchicznych domen ochrony stwierdza, że kontrola nie może być przekazywana dowolnie pomiędzy różnymi domenami bezpieczeństwa.

Brama jest cechą architektury x86 do przenoszenia sterowania z mniej uprzywilejowanych segmentów kodu do bardziej uprzywilejowanych, ale nie odwrotnie. Ponadto punkt w mniej uprzywilejowanym segmencie, z którego zostanie przekazana kontrola, może być dowolny, ale punkt w segmencie bardziej uprzywilejowanym do którego zostanie przekazana kontrola jest ściśle określony. Sterowanie wstecz przechodzenie do mniej uprzywilejowanego segmentu jest dozwolone tylko za pomocą instrukcji IRET. W odniesieniu do instrukcji programisty Intel twierdzi:

Moduły kodu w niższych segmentach uprawnień mogą uzyskać dostęp tylko do modułów działających w wyższych segmentach uprawnień za pomocą ściśle kontrolowany i chroniony interfejs zwany Bramą. Próby uzyskania dostępu do segmentów wyższych uprawnień bez przechodzenia przez bramę ochrony i bez posiadania wystarczających praw dostępu powodują wygenerowanie wyjątku ochrony ogólnej (#GP).

Innymi słowy, brama jest punktem wejścia w domenie uprzywilejowanej z wymaganymi prawami dostępu i adresem docelowym. W ten sposób wszystkie bramki są podobne i wykorzystywane do niemal tych samych celów, a wszystkie deskryptory bramek zawierają pole DPL, które jest używane przez procesor do kontroli praw dostępu. Ale zauważ, że procesor sprawdza DPL bramki tylko wtedy, gdy źródłem połączenia było oprogramowanie CALL, JMP, lub INT instrukcji i omija tę kontrolę, gdy źródłem wywołania jest sprzęt.

Rodzaje bram

Pomimo faktu, że wszystkie bramki są podobne, mają pewne różnice, ponieważ pierwotnie inżynierowie Intela myśleli, że różne bramki będą używane do różnych celów.

Task Gate

Zadanie Brama może być przechowywana tylko w IDT i GDT i wywoływana przez instrukcję INT. Jest to bardzo szczególny rodzaj bramy, która znacznie różni się od innych.

W rzeczywistości nikt nie używa go ani przełączania kontekstu sprzętowego. W praktyce funkcja ta nie jest optymalna z punktu widzenia wydajności i nie jest wygodny w użyciu. Na przykład, biorąc pod uwagę, że TSS może być przechowywany tylko w GDT i długość GDT nie może być większa niż 8192, nie możemy mieć więcej niż 8K zadań z punktu widzenia sprzętu.

Trap Gate

Brama pułapki może być przechowywana tylko w IDT i wywoływana przez instrukcję INT. Można go uznać za podstawowy typ bramy. Po prostu przekazuje kontrolę na konkretny adres podany w deskryptorze bramki trap w segmencie bardziej uprzywilejowanym i nic więcej. Bramy pułapkowe aktywnie wykorzystywane do różnych celów, które mogą obejmować:

W związku z tym, że system nie jest w pełni funkcjonalny, nie jest w pełni funkcjonalny, nie jest w pełni funkcjonalny.]}
• implementacja obsługi wyjątków(nie mamy powodu wyłączać przerwań w przypadku WYJĄTKÓW).
• obsługa przerwań na maszynach z APIC (możemy lepiej kontrolować stos jądra).

Interrupt Gate

Brama przerwania może być przechowywany tylko w IDT i wywoływany przez instrukcję INT. Jest to to samo co Brama pułapki, ale dodatkowo wywołanie bramy przerwania dodatkowo uniemożliwia akceptację przyszłych przerwań poprzez automatyczne wyczyszczenie flagi IF w rejestrze EFLAGS.

Bramki przerwań używane aktywnie do obsługi przerwań, szczególnie na maszynach opartych na PIC. Powodem jest wymóg kontrolowania głębokości stosu. PIC nie posiada funkcji priorytetów źródeł przerwań. Z tego powodu domyślnie wyłącza PIC tylko przerwanie, które już na obsłudze w procesorze. Ale kolejne przerwania nadal mogą pojawić się w środku i uprzedzić obsługę przerwań. Tak więc na stosie jądra może być 15 programów obsługi przerwań w tym samym momencie. W rezultacie deweloperzy kernela zmuszeni byli albo znacznie zwiększyć rozmiar stosu jądra, co prowadzi do kary za pamięć, albo byli gotowi stawić czoła sporadycznemu przepełnieniu stosu jądra. Brama przerwań może dać gwarancję, że na stosie jądra może znajdować się tylko jedna obsługa w o tej samej porze.

Call Gate

Brama wywołania może być przechowywana w GDL i LDT i wywoływana przez CALL i JMP Instrukcje. Podobny do trap gate, ale dodatkowo może przekazać wiele parametrów ze stosu zadań trybu użytkownika do stosu zadań trybu jądra. Ilość przekazywanych parametrów jest określona w deskryptorze bramki wywołania.

Bramy połączeń nigdy nie były popularne. Jest ku temu kilka powodów:

Można je zastąpić bramkami pułapek (brzytwą Occama).
• oni nie dużo przenośny. Inne procesory nie mają takich funkcji, co oznacza, że obsługa bramek wywołań systemowych jest obciążeniem przy przenoszeniu systemu operacyjnego, ponieważ te połączenia muszą zostać przepisane.
• nie są zbyt elastyczne, ponieważ ilość parametrów, które mogą być przekazywane między stosami, jest ograniczona.
Nie są optymalne z punktu widzenia wydajności.

Pod koniec lat 90. Intel i AMD wprowadziły dodatkowe instrukcje dla wywołań systemowych: SYSENTER/SYSEXIT (Intel) oraz SYSCALL/SYSRET (AMD). W przeciwieństwie do bramek połączeń, nowe instrukcje zapewniają korzyści wydajności i znalazły zastosowanie.

Podsumowanie

• Teoretycznie każdy typ bramy może służyć jako interfejs wskazujący na segment o dowolnym poziomie uprawnień. W praktyce, w nowoczesnym systemie operacyjnym w używaj tylko bramek przerwań i pułapek, które są używane w IDT do wywołań systemowych, przerwań i obsługi wyjątków i z tego powodu służą one jako punkt wejścia do jądra.

• Każdy typ bramki (w tym przerwanie, pułapka i zadanie) może być wywołany w oprogramowaniu za pomocą instrukcji INT. Jedyną funkcją, która może zabronić Użytkownikowi dostępu do danej bramki jest DPL. Na przykład, gdy system operacyjny buduje IDT, niezależnie od typów poszczególnych bramek, konfiguracja jądra DPL bramy, które będą używane do obsługi zdarzeń sprzętowych, zostaną ustawione na 0 i zgodnie z tym dostęp do tych bramek będzie dozwolony tylko z przestrzeni jądra (która działa co najwyżej w domenie uprzywilejowanej), ale kiedy ustawia bramę dla wywołania systemowego, ustawia DPL na 3, aby umożliwić dostęp do tej bramy z dowolnego kodu. W rezultacie, zadanie trybu użytkownika jest w stanie wykonać wywołanie systemowe przy użyciu bramki z DPL = 3, ale wyłapie ogólny błąd ochrony przy próbie wywołania funkcji obsługi przerwań klawiatury, na przykład.

• Dowolne typ bramy w IDT może być wywołany przez sprzęt. Ludzie używają bram przerwań do obsługi zdarzeń sprzętowych tylko w przypadkach, gdy chcą uzyskać pewną synchronizację. Na przykład, aby upewnić się, że przepełnienie stosu jądra jest niemożliwe. Na przykład, mam udane doświadczenie z wykorzystaniem bram pułapek do obsługi przerwań sprzętowych w systemie opartym na APIC.

• W podobny sposób Brama dowolnego typu w IDT może być wywoływana w oprogramowaniu. Powodem użycia bramek pułapkowych do wywołania systemowego a wyjątki są proste. Brak powodów do wyłączenia przerwań. Wyłączenie przerwania jest złe, ponieważ zwiększa obsługę opóźnień i zwiększa prawdopodobieństwo utraty przerwania. Dzięki temu nikt ich nie wyłączy bez żadnego poważnego powodu na rękach.

• Obsługa przerwań zazwyczaj pisana jest w ścisłym stylu reentrantowym. W ten sposób programy obsługi przerwań zwykle nie udostępniają żadnych danych i mogą w przejrzysty sposób wyprzedzać się nawzajem. Nawet wtedy, gdy musimy wzajemnie wykluczać współbieżny dostęp do danych w programie obsługi przerwań możemy chronić tylko dostęp do współdzielonych danych za pomocą instrukcji cli i STI. Nie ma powodu, by uważać cały program obsługi przerwań za sekcję krytyczną. Nie ma powodu, aby używać bram przerwań, z wyjątkiem chęci zapobieżenia ewentualnemu przepełnieniu stosu jądra w systemach opartych na PIC.

Bramki pułapek są domyślnym rozwiązaniem dla interfejsu jądra. Brama przerwań może być używana zamiast bramy pułapki, jeśli istnieje poważny powód za to.

Brama przerwań jest wyjątkowa, ponieważ flaga IF jest automatycznie czyszczona. Brama wywołania jest wyjątkowa, ponieważ nie jest aktywowana przez wektor przerwania. Brama zadań jest wyjątkowa, ponieważ automatycznie zapisuje stan procesora. Cztery różne zachowania, posiadanie czterech nazw dla nich jest wygodne.