KIV/OS Flashcards

Question 1

Q

80186 a 80286

Answer

A

Oba - 1982
Oba - Instrukční sada x86-16 (16 bitový procesor)

80186 - sice se už nevyrábí, ale zato dodnes existují RISCové procesory, které mají x86-16 instrukční sadu

80286 - měl protected mode, procesor po zapnutí však startuje real-mode kvůli zpětné kompatibilitě (to ostatně dělají i dnešní x86-64)

Question 2

Q

80286 – vybrané registry (5x)

Answer

A

1) AX, BX, CX a DX – obecné 16-bitové registry, které se dále dělí na dvojice 8-bitových registrů
2) CS, DS, SS, ES – segmentové registry pro kód, data, zásobník a extra segmentový registr
3) SI, DI, BP, SP – indexové registry; source, destination, base, stack
4) Flags – stavový registr, výsledky operací
5) MSW (386+: CR0-4, atd.) – stav CPU (machine status word)

Question 3

Q

80286 – adresace

Answer

A

Adresa v paměti ji dána dvojicí registrů segment:index (např CS:IP)

Adresa má 20 bitů

segment i index 16 bitů
adresa = segment posunutý o 4 bity dolevo, bitové or s indexem

Question 4

Q

MS-DOS

význam
co poskytuje
druhy

Answer

A

Disk Operating System
Jeden z nejvýznamnějších (tj. ne nutně nejlepších) operačních systémů
Poskytuje konzoli a souborový systém
(konzole se myslí klávesnice pro standard input)
Existovalo mnoho DOSů
◦ MS-DOS, PC-DOS, DR-DOS, QDOS…
◦ MSDOS.SYS, IO.SYS a COMMAND.COM se pak jmenují jinak
◦ A dodnes aktivní FreeDOS

Question 5

Q

80286 – MS-DOS Bootstrap - od začátku až do nalezení MBR (tj. kroky 1 - 4)

Answer

A

1) Po zapnutí/hw resetu (tj. hot reset počítače) se procesor uvede do aktivního stavu a do režimu real-mode, tzn. má přístup pouze k 1MB paměti a kód může číst a zapisovat na libovolné místo v paměti

2) Registry CS:IP se nastaví na hodnoty F000:FFF0 a CPU začne vykonávat instrukce od této adresy
◦ Tj. skočí na první instrukci ROM-BIOSu, čímž spustí jeho kód – proto se této adrese říká reset vector
◦ Cold reset počítače: předání se řízení na adresu určenou reset vectorem; od 386 je to fyz. lineární adr. 0xFFFFFFF0

3) Podle nakonfigurovaného pořadí BIOS hledá disky

4) Při nalezení prvního disku BIOS načte do paměti, adresa 0x7c00, jeho první sektor, tj. prvních 512 bytů, předá řízení CPU na tuto adresu – tj. nastaví CS:IP
◦ První sektor se nazývá Master Boot Record (MBR)

Question 6

Q

80286 – MS-DOS Bootstrap - od nalezení MBR až po převzetí řízení IO.SYS (tj. kroky 4-7)

Answer

A

4) Při nalezení prvního disku BIOS načte do paměti, adresa 0x7c00, jeho první sektor, tj. prvních 512 bytů, předá řízení CPU na tuto adresu – tj. nastaví CS:IP
◦ První sektor se nazývá Master Boot Record (MBR)

5) Kód načtený z MBR má za úkol načíst zbytek zavaděče ze správného/aktivního/vybraného oddílu disku
◦ Může být zavaděč přímo operačního systému
◦ Anebo manažer, který dá vybrat, který OS se má zavést, je-li jich nainstalováno více
◦ Anebo to také může být vir, který infikuje počítač ještě před načtením OS
◦ MS-DOS startuje z FAT, active&bootable&primary oddílu

6) Poté, co kód z MBR identifikoval použitelný diskový oddíl, pokračuje s načítáním OS do paměti
◦ Jedná se o soubory IO.SYS a MSDOS.SYS, které musí být uloženy kontinuálně na začátku oddílu

7) Jakmile jsou sobory načteny, řízení převezme IO.SYS
◦ Rozhraní mezi DOSem a I/O subsystémem, které zpřístupní základní periferie

Question 7

Q

80286 – MS-DOS Bootstrap - od převzetí řízení IO.SYS až do konce (tj. kroky 7 - 12)

Answer

A

7) Jakmile jsou sobory načteny, řízení převezme IO.SYS
◦ Rozhraní mezi DOSem a I/O subsystémem, které zpřístupní základní periferie

8) IO.SYS předá řízení MSDOS.SYS
◦ Jádro OS, které poskytuje abstrakci od HW pomocí poskytovaných služeb

9) Pokud existuje, MSDOS.SYS načte a zparsuje CONFIG.SYS
◦ Zavede ovladače paměti (XMS, EMS), periferií (CDROM, Myš, zvuková karta, atd.)…

10) MS-DOS.SYS načte a spustí, tj. předá řízení, COMMAND.COM (interpret příkazů, aneb shell)

11) Pokud existuje, spustí se AUTOEXEC.BAT
◦ Dávkový soubor s příkazy pro COMMAND.COM

12) C:\ aneb Hotovo

Question 8

Q

Windows - 9X Bootstrap

Answer

A

16 bitové Windows se spouštěly příkazem win.com
◦ Zavaděč Windows/386 přepnul procesor do tzv. protected-mode
Windows 9x se zaváděly tak, že IO.SYS provedl konfiguraci počítače v real-mode a pak spustil win.com po dokončení AUTOEXEC.BAT

◦ Komplikované zavedení ovladačů, některá zařízení mají ovladače jen pro real-mode, zatímco Windows běží v protected-mode => potřeba virtualizace –V86 mode

Pozn:
O trochu komplikovanější
Méně pádů
Pády kvůli driverům

Question 9

Q

Problém jádra většího než 1MB

Answer

A

CPU startuje v real-mode pouze s 20-bitovou adresou (2^20 = 10^6)

Jak zavést tak velké jádro?

1) 386+ procesory lze přepnout do tzv. unreal-mode, který zpřístupní dostupnou paměť jako 4GB flat address space
- > A pak lze načíst a spustit jádro větší než 1MB

2) Anebo máme UEFI – což nikdy nebyl případ MS-DOSu
- > Ale stále existuje např. FreeDOS

Question 10

Q

Unreal mode

Answer

A

Není to oficiálně garantovaná vlastnost, ale existuje protože ji potřebuje System Management Mode
Aby mohly programy běžet v protected-mode (32-bitová adresa, segmentace, stránkování, izolace procesů), je třeba vytvořit GDT a LDT
Globální a lokální tabulky deskriptorů segmentů – organizace paměti
Segmentům se nastaví maximální velikost (limity) a procesor se přepne zpět do real-mode
◦ Respektive do unreal-mode protože limity zůstanou zachovány

Question 11

Q

Problém příliš velkého programu (DOS)

Answer

A

 Co když máme program pro real-mode, který ale
vyžaduje více paměti, než kolik jí je volné?
◦ XMS, EMS – paměťové manažery, které přepnuly procesor do protected mode a na rozdíl od unreal mode v něm zůstaly
◦ Real-mode programům, pak umožnily využít větší paměť po max 64kB velkých oknech, které kopírovaly mezi adresami nad a pod 1MB
 Programy pak dynamicky překrývaly blok paměti různými částmi, moduly, svého kódu => tzv. overlays

Question 12

Q

Overlays

Answer

A

Technika, která umožňuje spustit program, který je větší než velikost dostupné paměti
◦ Předchůdce virtuální paměti (příští přednáška)
◦ Stále se používá u vestavěných zařízení, kde virtuální paměť není k dispozici
Program se rozdělí do funkčních modulů, overlays, které mají stromovou strukturu
◦ V paměti mohou být zavedeny jenom moduly od na cestě kořene, tj. fce main, až k listům
◦ Návrh stromů a explicitní zavádění a uvolňování musí zařídit programátor

Question 13

Q

UEFI

Answer

A

Unified Extensible Firmware Interface
Nástupce BIOSu, který má řešit jeho nedostatky
Nespoléhá se na boot (tj. první) sektor, ale definuje boot manager
◦ Umí zavádět pouze důvěryhodně podepsaný kód – což nejsou např. viry – BIOS uměl zamezit přepsání MBR
◦ Nicméně má legacy mode, ve kterém se chová jako BIOS
Umí přepnout procesor do cílového režimu, např. protected-mode – zavaděč OS to ale musí očekávat

UEFI boostrap - Stejná control flow jako MS-DOS

Question 14

Q

EFI executable

Answer

A

spustitelný soubor v UEFI bytecodu (ne Java bytecode)!

Question 15

Q

Guid Partition Table (GPT)

Answer

A

načisto udělaná tabulka diskových oddílů, tak aby se nemusel vláčet omezující balast z minulost (UEFI)

Question 16

Q

EFI System Partition

Answer

A

oddíl naformátovaný souborovým systémem FAT dle specifikace UEFI

Question 17

Q

MS-DOS API

Answer

A

 Chce-li program zavolat službu operačního systému, de-facto volá požadovanou rutinu, která je už někde
v paměti – ale jak ji najde?
 Řešením je, aby byla na předem známé adrese, kam se předá řízení procesoru nastavením CS:IP
 Rutin implementujících jednotlivé služby může být mnoho => použije se další registr, např. ax na určení konkrétní služby

Volání:
 Služba MS-DOS se zavolá pomocí přerušení 21h
◦ Tzn. adresa hlavní rutiny služeb OS je zapsána na 0x21. pozici tabulky vektorů přerušení

Příklad volání:
mov ah, 0x30h
int 21h
;po návratu jsou hlavní a vedlejší čísla verze v AL a AH

Question 18

Q

MS-DOS obsluha API

Answer

A

Program nastaví příslušné registry vykoná int 21h
Do zásobníku, na jehož vrchol ukazuje SS:SP, se uloží registry CS:IP (ukazující ve volajícím programu na další instrukci po int 21h) a registr Flags
◦ Provede procesor v rámci zpracování instrukce int 21h
Jádro OS získá kontrolu nad CPU a vidí všechny registry volajícího programu
Jádro OS provede příslušnou akci a nastaví příslušní registry podle výsledku akce

Question 19

Q

EGA-BIOS

Answer

A

Co když budeme chtít využít služeb, které neposkytuje BIOS, ale např. grafický adaptér?
Např. budeme chtít změnit režim obrazovky na
320x200x256. Program vykoná následující instrukce

mov ah, 0 ;služba Změň videorežim
mov al, 13h ;režim 320x200 256 barev
int 10h

Z hlediska procesoru se stane to samé jako při instrukci int 21h, pouze vykonávaný kód bude v paměti někde jinde

Question 20

Q

Zápis do video paměti (asi MS-DOS)

Answer

A

Na adrese a000:0000 je první pixel právě nastaveného videorežimu, levý horní roh
 Na každý pixel je jeden byte, byte je index do palety barev
 Přímým zápisem do namapované videopaměti měníme barvy jednotlivých pixelů
 V textovém režimu je znak v levém horním rohu na
b800:0000
◦ Má dva byty – 1. byte kód znaku, 2. byte atributy, např. barva

Question 21

Q

VESA - motivace

Answer

A

 Videorežim 320x200x256 potřebuje méně než 64kB na uložení indexů pixelů do palety barev
 Videorežim 640x480x16 také
 Ale videorežim 640x480x256 už ne – navíc to dříve nebýval standardní režim, dokud se neobjevila specifikace VESA - SuperVGA
 Před VESA sice bylo možné na některých kartách takový režim aktivovat, ale postup byl proprietární
 Proto vznikl rezidentní software, který VESA emuloval

Question 22

Q

VESA - stránkování

Answer

A

 Video režim 1280x1024 při 24-bitové barevné hloubce potřebuje více než 64kB paměti
 Řešením bylo stránkování
◦ Obraz se rozdělil na několik stránek po 64kB
◦ 64kB od A000:0000 umožňovalo přímý zápis a čtení do aktivní stránky
 Aktivní stránka se zvolí funkcí VESA BIOSu
◦ Buď pomocí int 10h – opakované volání int 10h je pomalé
◦ Anebo call na konkrétní adresu obslužné rutiny; adresu získáme přes int 10h – call je daleko rychlejší než int, který je potřeba pouze jednou

Question 23

Q

VESA – Linear Frame Buffer

Answer

A

 I když je stránkování video paměti pomocí call rychlejší než pomocí int, je stále pomalé
 Rychlejší je přímý přístup do video paměti, jako tomu bylo u videorežimů, kterým stačilo 64kB
 VESA umožňuje získat adresu Linear Frame Buffer (LFB)
◦ Obdoba A000:0000 u EGA, ale adresa LFB není pevně daná
◦ Je třeba LFB „povolit“ a následně získat adresu od grafické karty
◦ Blok paměti, který nelze použít pro data a kód programů

Question 24

Q

Zřetězení obsluhy přerušení

Answer

A

 Např. chceme-li sw emulovat VESA
1. Program si do vlastní proměnné načte adresu stávajícího vektoru přerušení – int 10h u sw VESA
2. Program zapíše do tabulky vektorů přerušení adresu své rutiny, která bude přerušení nově obsluhovat
◦ Např. u sw VESA obsluhuje služby s AH=4Fh (VESA extension)
◦ Nová rutina přerušení může, případně musí (např. int 08h hodiny), zavolat (už ne int!) předcházející obsluhu přerušení
3. Program skončí službou OS Terminate and Stay Resident (TSR)

Question 25

Q

Ukončení TSR

Answer

A

 TSR program měl smysl pouze tehdy, pokud obsluhoval některé přerušení
 V paměti mohl být načteno několik TSR obsluhujících stejné přerušení
 Ale co když se měl jeden z nich ukončit, a nebyl to ten poslední?
◦ Byl to problém, protože neexistoval standardizovaný protokol, jak vyjmout ze zřetězeného seznamu obsluh přerušení někoho uprostřed

Question 26

Q

Interrupt request (IRQ)

Answer

A

 Instrukce int je sw-vyvolané přerušení
 Pokud přerušení vyvolá hw, pak se bavíme o IRQ
◦ Každé IRQ má svoji prioritu – Level aka IRQL
 Při IRQ procesor zastaví vykonávání aktuálního programu, uloží Flags, CS a IP, a začne vykonávat příslušenou obsluhu přerušení dle tabulky vektorů přerušení
 Programmable Interrupt Controller (PIC) mj. překládá číslo IRQ na index do tabulky vektorů přerušení

Question 27

Q

Časovač

Answer

A

 Např. tik hodin je IRQ0 (nelze změnit ani maskovat)
a vyvolá obsluhu přerušení int 08h
◦ Proběhne každých 55ms
 Na tomto přerušení závisí mnoho důležitých činností a je proto nutné, aby
a) Bylo co nejrychlejší
b) Zavolalo původní obsluhu přerušení
 Pomocí časovače se implementuje preemptivní
multithreading (a následně multitasking)

Question 28

Q

Časovač - implementace

Answer

A

Nejprve se do proměnné oldVec8 uloží adresa původní
obsluhy přerušení, takže obsluha může vypadat následovně:

pushf;simulace volání obsluhy přerušení
call dword ptr cs:[oldVec8] ;pro původní obsluhu
… ;naše vlastní činnost
iret ;návrat do přerušeného programu

Question 29

Q

I/O Porty

Answer

A

 Input/Ouput base address – adresa prvního portu
 Periferie lze také ovládat pomocí portů – jedno zda blikáme s LED klávesnice, nebo programujeme PIC
◦ Zápis odešle příkaz; instrukce out
◦ Čtení čte stav nebo výsledek operace; instrukce in
 Např. při obsluze časově závislých činností v int 08h je nutné poslat řadiči přerušení informaci, že přerušení již skončilo

mov al, 20h ;signál Konec přerušení
out 20h, al ;port řadiče přerušení 8259

Question 30

Q

Viry

Answer

A

 MS-DOS umožnil ovládat počítač a jeho periferie
 Ale špatně nebo záměrně napsaný program mohl číst
a přepisovat jeho vnitřní proměnné, a libovolně měnit činnost systému
◦ Např. na přerušení se mohl pověsit vir, který se spouštěl z infikovaného MBR disku a infikoval MBR disket, a díky zavedení před jádrem OS mohl utajit své soubory na disku filtrováním systémových volání
 Antiviry musely skenovat paměť, což byla příležitost pro polymorfní viry, které měnily svůj kód v paměti za běhu

Question 31

Q

Režím jádra a uživatelský režim - motivace

Answer

A

 ..mohlo zároveň běžet několik procesů
 ..proces nemusel vědět, že zároveň s ním běží další procesy
 ..bylo jedno, kde v paměti běží který proces
 ..proces nemohl přistupovat do paměti jiného procesu či jádra
 ..výsledkem nebylo zpomalení počítače
 ..výsledkem bylo zefektivnění práce na počítači

Question 32

Q

Memory Management Unit

Answer

A

Výše uvedené cíle (motivace režim jádra a uživatelský režim) implikují, že procesy budou pracovat se
svým formátem (tj. virtuální) adresy do paměti, která bude následně převedena na fyzickou adresu do paměti
 Protože sw implementovaný převod by byl pomalý, převod virtuální na fyzickou adresu obstará hw
◦ Konkrétně Memory Management Unit (MMU)
◦ Detaily převodu zadá MMU přímo OS

CPU –(virutální)–> MMU –(fyzická)–> Paměť

Question 33

Q

x86 virtuální adresa

Answer

A

 x86 pracuje s virtuální adresou ve formátu segment:offset
 Z ní je třeba získat tzv. lineární adresu, a teprve tu lze převést na fyzickou adresu v režimu, ve kterém dokážeme od sebe izolovat jednotlivé procesy a jádro

CPU –(virutální/logická)–> MMU –(lineární)–> Stránkování –(fyzická)–> Paměť

Question 34

Q

Protected mode

Answer

A

 V prvé řadě musíme zabránit uživatelským procesům, aby nemohly modifikovat kód a data jádra
 Jelikož x86 adresuje pomocí segmentu a offsetu (vůči
segmentu), řešením bylo připojit dodatečné informace ke konkrétním segmentům
◦ => už nepracujeme se segmentem, ale se segment deskriptorem
◦ Procesor běží v tzv. Protected mode

Question 35

Q

Segment Descriptor

Answer

A

Segment má:
◦ Základní (base) adresu (lineární adresa)
◦ Velikost (limit)
◦ Typ (kód, data, atd.)
◦ Přístupová práva
◦ Další vlajky

Question 36

Q

Izolace jádra

Answer

A

 Pro izolaci je důležitá hodnota bitů CPL/DPL
CPL = current privilege level?
DPL = descriptor privilege level?
 Číslo oprávnění/privilege level aktuálního kódu
◦ 00 - většinou jádro
◦ 01 –může být jádro, když na 00 poběží hypervizor virtualizace
◦ 10 – může být ovladač, který nesmí do jádra
◦ 11 – většinou uživatelský proces
 Kód s nižším číslem oprávnění může přistupovat do segmentu s vyšším číslem oprávnění
 Opačně to nelze => izolace jádra od uživ. procesů

Question 37

Q

Izolace procesů

Answer

A

 Před vlastní inicializací protected mode musí jádro OS
vytvořit tabulku deskriptorů segmentů

 Tabulky existují dvě

1) Globální používaná jádrem
- > uložena v registru gdtr privilegovanou instrukcí lgdt
2) Lokální používaná konkrétním jedním procesem
- > Uložena v registru ldtr privilegovanou instrukcí lldt
- > Tj. při přepnutí kontextu může lldt vykonat pouze jádro s CPL=0 a tudíž si uživatelský proces nemůže měnit jemu přidělenou paměť

Question 38

Q

Segment deskriptory v kódu

Answer

A

 Uživatelský proces může mít až 6 segmentů s deskriptory uloženými v cs, ds, ss, es, fs a gs
◦ V 64-bitovém long-mode jsou nulové až na fs a gs
 Adresa v paměti má prefix požadovaného segmentu
◦ call cs:[adresa_funkce]
◦ mov eax, ds:[adresa_retezce]
◦ mov ecx, ss:[ebp-offset_parametru_funkce]
 V ebp bývá hodnota esp při volání funkce, tzv. frame pointer

Question 39

Q

Výhody a nevýhody segmentace

Answer

A

\+ Izoluje procesy a jádro
\+ Lze sdílet segmenty – např. read-only programový kód sdílených knihoven
\+ Lze relokovat i pouze jeden segment
\+ Není nutné alokovat nevyužitou paměť
\+ Tabulka deskriptorů se vejde do MMU

Segmenty mohou mít různou délku => jak je poskládat do paměti?
Segmenty mohou být velké => fragmentace paměti
Jak efektivně implementovat sdílenou paměť mezi procesy?
Jak efektivně odkládat paměť z RAM na disk, abychom zvýšili celkovou dostupnou paměť počítače?

Question 40

Q

Stránkování

Answer

A

Odstraňuje nevýhody segmentace
◦ x86 umožňuje kombinovat segmentaci a stránkování
◦ Nelze povolit stránkování bez protected mode
◦ x86 ji umožňuje použít v protected (32-bit) a long (64-bit) mode
Celá paměť se rozdělí do stránek o pevné velikosti
◦ 4kB, 2MB, 4MB a 1GB
◦ Virtuální stránka: page (o velikosti frame)
◦ Fyzická stránka: frame (o velikosti page)

Question 41

Q

Page Table

Answer

A

Jádro OS vytvoří tabulku stránek
◦ Řídící registr (x86) cr3 ukazuje na tuto tabulku stránek
◦ Pouze jádro s CPL=0 může měnit obsah cr3
-> Tj. dosáhneme stejného efektu jako s GDT a LDT
-> Procesor nastaví cr3 při přepnutí kontextu
Každá stránka má své vlajky, mj. zahrnující
◦ Jádro vs. Uživatelský proces
◦ Writeable, NX – do not execute
◦ Present (zda je fyzicky v RAM), Dirty a Accessed

Question 42

Q

Hierarchická Page Table

Answer

A

 Jenom několik málo procesů využije celý dostupný paměťový prostor, např. 2^32
 Řešením je vytvořit vnější/nadřízenou/page directory tabulku stránek, která bude odkazovat na další tabulku stránek
◦ Paměťový prostor procesu pak nemusí být spojitý, ale mohou v něm být díry na místech, které program nepoužívá

Question 43

Q

Translation look-aside buffer

Answer

A

 Běžící proces často potřebuje jenom omezené množství stránek
◦ Jak tedy zrychlit převod virtuální adresy na fyzickou?
◦ Pomocí asociativní pamětí Translataion look-aside buffer (TLB)
-> Musí se vyprázdnit při změně kontextu
-> Je rychlá, ale také je malá
—> Větší hit rate když je větší, ale také je pak pomalejší
-> Má zásadní vliv na výkon

Question 44

Q

Sdílená paměť

Answer

A

Efektivní cesta jak sdílet data mezi různými procesy
Procesy jsou zodpovědné za konsistenci dat ve sdílené paměti
OS pouze zajistí sdílení paměti
Do tabulky stránek procesu OS přidá page entry, která ukazuje na ten samý rámec (fyzická stránka) jako page entries v tabulkách stránek ostatních procesů, které tímto „trikem“ sdílejí tu samou paměť

Question 45

Q

Sdílení kódu

Answer

A

 Pokud několik procesů používá sdílený programový kód, proč ho do paměti nahrávat vícekrát?
 Příslušné stránky s kódem se označí jako read-only
a namapují se do paměťových prostorů příslušných procesů
◦ Tj. stále jde o sdílenou paměť
 Příkladem jsou dynamické knihovny
◦ dll
◦ so

Question 46

Q

Copy on write

Answer

A

 Co když několik procesů na začátku sdílí stejná data, která považují za privátní, ale mění je jenom zřídka?
1. Příslušná stránka se označí jako read-only
◦ Dokud z ní proces jenom čte, nic se neděje
2. Jakmile se proces pokusí zapsat do read-only stránky, procesor vygeneruje vyjímku, kterou zachytí OS
3. OS pak alokuje novou stránku, zkopíruje do ní původní read-only stránku, a aktualizuje tabulku stránek procesu
4. Po návratu z obsluhy proces normálně zapíše data už do nové stránky, aniž by o něčem vůbec věděl

Question 47

Q

Swapování

Answer

A

 Chceme-li poskytnout procesům více paměti, než kolik máme fyzicky RAM, nezbývá než paměť z RAM dočasně odložit do jiné paměti – flash nebo pevný disk
 Working Set – dynamická množina stránek, které má proces aktuálně ve fyzické paměti
 Chce-li dát OS více paměti některému procesu a není volný rámec, zmenší Working Set jiného procesu odebráním stránky, přičemž uloží obsah rámce na disk

Question 48

Q

Page Fault

Answer

A

Proces chce číst data ze stránky, která není v RAM
MMU nedokáže přeložit virtuální adresu na fyzickou adresu
◦ => vygeneruje vyjímku PageFault
OS uloží rámec některé jiné stránky, třeba i jiného procesu, na disk a načte do něj stránku požadovanou aktuálním procesem
OS příslušně upraví tabulky stránek dotčených procesů
Po dokončení proces dál normálně pokračuje aniž by něco poznal

Následky:
 Ve skutečnosti OS nebude měnit working sets při každém Page Fault
◦ Namísto toho se požadavky mohou nasbírat a vyřídit později – hromadně
◦ Page Fault-ovaný proces se mezitím může pozastavit

 Swapování má extrémně negativní vliv na výkon systému
◦ Zaměstnává procesor, disk a příslušnou i/o sběrnici

Question 49

Q

Mapování souborů

Answer

A

 Chceme-li zrychlit práci se souborem, je možné OS požádat o namapování souboru do paměti
 Proces pak zapisuje a čte přímo z rychlé paměti, namísto práce s pomalejším diskem
 OS namapuje soubor do paměti po stránkách jako
u swap souboru
 Při ukončení práce se souborem se pak na disk zapíší pouze ty stránky, které mají nastavený dirty bit
◦ Pokud by měl soubor např. několik GB, proč zapisovat vše?

Question 50

Q

Změna privilege level

Answer

A

 Uživatelský proces běží ve svém paměťovém prostoru
 Pokud volá funkci jádra operačního systému, které vyžaduje vyšší úroveň oprávnění, např. CPL=0, je nutné nějak změnit privilege level
 Dělá to procesor v okamžiku, kdy obsluhuje přerušení ať už int nebo IRQ
◦ Úroveň oprávnění určí z adresy/vektoru obsluhy přerušení
◦ Obsluha přerušení běží se zvýšeným CPL tak dlouho, dokud neudělá iret

Question 51

Q

Physical Address Extension (PAE)

Answer

A

 Éra 32-bitových x86 s více než 4GB RAM
 Ačkoliv procesor, tj. i jádro OS, dokázalo adresovat pouze 4GB RAM, tabulky stránek mohly adresovat více než 4GB RAM
 V podstatě šlo první kroky ke 64-bitovým tabulkám stránek – u PAE s 36-bitovou fyzickou adresou
◦ Zavedeno s Pentium Pro
◦ Nicméně, už 386 by teoreticky zvládnula 64TB virtuální paměti – technická realizace v praxi je ovšem něco jiného

Question 52

Q

80386 virtuální adresový prostor

Answer

A

 Virtuální adresy mají 48-bitů – dáno MMU
◦ 16 bitů segment selektor, 32 bitů offset v rámci segmentu
 16+32= 48 bitů virtuálního adresy
◦ Ale 2 bity selektoru jsou použity na privilege level
◦ 1 bit selektoru indikuje globální/lokální tabulku
◦ => 46 k adresování použitelných bitů => 2^46=64TB
 Jedná se ale jenom o teoretický limit! V praxi nikdy nebylo použito.

Question 53

Q

Kde se používá segmentace?

Answer

A

 Ačkoliv je segmentace považovaná za historický artefakt, nedá se říci, že by byla nepoužívaná
◦ Např. Vx32 user-level sandboxing na x86 ji používá ke spouštění nedůvěryhodných programů na FreeBSD, Linuxu a Mac OS
◦ Implementace TLS ve Windows

Question 54

Q

Segmented Paging

Answer

A

 Tabulky stránek jsou segmentovány
 Virtuální adresa je logical_page:offset
 logical_page je segment_number:segment_offset

Question 55

Q

Paged Segmentation

Answer

A

 Segmenty se skládají ze stránek
 Virtuální adresa je seg:offset
 Offset je page_number:page_offset
 Way to go on x86

Question 56

Q

Monolitické jádro (privilege level)

Answer

A

 Všechny služby jádra OS běží s CPL=0
 Ovladače mohou běžet jako moduly jádra také s CPL=0
 K drahému přepnutí kontextu dojde jenom 2x
◦ Při volání služby OS
◦ Po dokončení služby OS
=> Pozor, řízení se může předat jinému procesu

Proces běží -> Jádro obsluhuje -> Proces běží

Question 57

Q

Monolitické jádro - problém s velikostí

Answer

A

Jádro může být příliš velké, než aby se vešlo do paměti
◦ Nebo nechá příliš málo volné paměti
◦ Problém zejména u Embedded systémů
◦ U PC s Linuxem to zase takový problém není
 Např. AIX a MULTICS umí dynamicky načítat a uvolňovat moduly

Question 58

Q

Kernel Panic

Answer

A

 Když selže jádro, co budeme dělat?
◦ Nejspíš už nic.
 Vlastní jádro bývá obvykle dobře odladěné
 Daleko větší problém představují ovladače běžící s CPL=0
 Chyba v ovladači pak s sebou vezme celé jádro
◦ Bez ohledu na to, jak má být dotčené jádro dobré
 Příčinou může být i vadný hw

Question 59

Q

Mikrojádro – proč?

Answer

A

 Když přesuneme co nejvíce kódu mimo CPL jádra, pak zvyšujeme šanci, že jádro přežije
◦ A následně můžeme restartovat pouze ten kód, který selhal

 Mikrojádro obsahuje pouze základní, nezbytné služby
◦ Plánovač
◦ Alokace paměti (ale ne celý správce paměti)
◦ Meziprocesová komunikace

 Když „nejaderný“ kód OS poběží mimo CPL(plánovač má CPL jádra), pak ho můžeme napsat jako preemptivní a plánovat jako běžný proces
◦ Požadavky na vykonání služeb se pak dají seskupovat a tím se zvýší efektivita jejich obsluhy systémem
 Monolitické a hybridní jádra mají Bottom-Half, viz dále, které mají stejný cíl
◦ Kód pak může běžet na různých CPU,
 Dokonce i na jiném počítači u distribuovaných OS

Question 60

Q

Mikrojádro – skutečný výkon

Answer

A

 Mikrojádro je pomalé kvůli příliš velkému počtu
přepínání kontextu
1. Proces volá službu OS – přepne se kontext do CPL mikrojádra
2. Mikrojádro určí příslušný obslužný kód mimo CPL mikrojádra a předá mu řízení => přepnutí kontextu
3. Když se dokončí obsluha mimo CPL mikrojádra, předá se opět řízení do kontextu s jiným CPL
–> Může být opět mikrojádro a z něj pak následně
přepnutí do CPL uživatelského procesu

Question 61

Q

Mikrojádro – optimalizace

Answer

A

 Protože mikrojádro přeposílá požadavky jinam, optimalizace by spočívala v tom, jak při předání výsledků ušetřit alespoň jedno přepnutí kontextu
◦ Případně jak rovnou volat kód mimo CPL mikrojádra
 Taková možnost musí ale počítat s tím, že kód mimo mikrojádra mohl být nahrán znovu na novou adresu v paměti
 Nejrychlejší mikrokernel měla AmigaOS v době, kdy ještě Amiga neměla obdobu Protected-Mode
◦ Pak už na tom byla stejně jako jiné mikrokernely

Question 62

Q

Hybridní jádro

Answer

A

 Protože je mikrojádro pomalé, vývoj OS začne monolitickým jádrem
 Výkonnostně kritické části kódu pak zůstanou v jádře, zatímco ostatní se přesunou na úroveň s méně privilegovanou CPL
◦ Např. ovladače třetích stran, které často padají a zákazníci si myslí, že je to špatným OS

Question 63

Q

GetTickCount - co to je + problém

Answer

A

 RTL knihovny často nabízejí funkci podobného názvu, která vrací počet tiků od resetu procesoru
 Získání korektní hodnoty není na moderních procesorech triviální => proto se vyplatí, aby RTL knihovna zavolala příslušnou funkci OS

 80286 měla na adrese 0000:046c real-mode 4-bytovou proměnnou ROM-BIOSu, která udávala počet 55ms tiků od resetu procesoru
 Pozdější procesory mají tick-counter registr, který je dnes větší a má daleko nižší režii přístupu, ale..
◦ Registry nejsou synchronizované mezi jednotlivými jádry v systému - resp. není to garantované
◦ Power-saving na konkrétním jádru ovlivní hodnotu čítače
◦ Out-of-order může samotnou čtecí instrukci vykonat příliš brzy
 => ať si takové varianty ošetří jádro namísto volajícího
threadu

Question 64

Q

GetTickCount - volání

Answer

A

 Pro jednoduchost předpokládejme x86 uniprocesor
 Čítač tiků přečte instrukce RDTSC
 V uživatelském procesu tak kód může vypadat takto:
size_t tickcount = GetTickCount();
 Přičemž předpokládejme, že se návratová hodnota
vrátí v registru EAX

 Instrukci RDTSC lze vykonat v uživatelském režimu
 Kód příslušné funkce namapuje OS do adresového prostoru příslušného procesu
◦ Sdílení kódu
◦ Dynamické knihovny
 Obsluha takové funkce tedy vůbec nevyžaduje přepnutí kontextu => rychlost dokončení služby OS
◦ Což neznamená, že k němu nemůže dojít vlivem časovače

Volání služby:

GetTickCount se přeloží jako call instrukce, která předá řízení na adresu, na které je příslušný RTL kód, nejpravděpodobněji kód od výrobce překladače
RTL kód zatím blíže neurčeným způsobem zná adresu, kam OS namapoval svůj sdílený kód (dynamická knihovna), který dělá požadovanou činnost - RTL kód udělá příslušný call
Kód OS mj. zapíše tick count do EAX a udělá ret
RTL kód udělá ret
Proces zná počet ticků (zanedbali jsme errno)

Answer 65

A

 Naprostá většina programů používá knihovny
◦ Statické knihovny se během překladu stanou součástí výsledného kódu spustitelného programu
◦ U dynamických knihoven se to nestane, knihovna bude existovat jako samostatný soubor
 Soubor může na disku existovat jenom jednou
 Soubor může mít do paměti namapováno několik
procesů
 Viz koncept sdílení kódu

Answer 66

A

 Proces explicitně stanoví kdy a která knihovna se má načíst do paměti – tj. proces zavolá jednu z následujících funkcí, které předá cestu ke knihovně
◦ dlopen – Linux, MacOS
◦ LoadLibrary – WinAPI
 OS volajícímu procesu inkrementuje reference counter, kolikrát už danou knihovnu načetl
◦ Pokud knihovna nebyla dosud načtena, OS alokuje procesu paměť, do které nahraje knihovnu
◦ OS vyřeší, která část nově alokovaná data bude označena jako spustitelná a která jako datová

Answer 67

A

 Během načítání knihovny nemusí být cesta k ní
jednoznačná
◦ Např. bude-li to pouze jméno souboru bez cesty, systém bude soubor hledat v adresáři se spustitelným souborem
 A když tam nebude, tak v adresářích specifikovaných nějakou proměnnou – např. PATH ve Windows
 Bude-li program pod Windows specifikovat pouze jméno souboru knihovny v cestě dané PATH, lze podvrhnout falešnou knihovnu do adresáře k jeho .exe souboru, a tato podvržená knihovna tak bude načtena namísto té v cestě PATH

Answer 68

A

 Během procesu dynamic loading získá proces deskriptor načtené knihovny
 Proces explicitně stanoví, kdy knihovna
identifikovaná příslušným deskriptorem, uvolní z
paměti
◦ dlclose, FreeLibrary
◦ Uvedené funkce sníží reference counter knihovny o jedna
–> OS uvolní knihovnu z paměti teprve až reference counter = 0
–> Ukazatele do této paměti se tak stanou neplatnými

Answer 69

A

 Máme-li knihovnu načtenou v paměťovém prostoru procesu, potřebujeme ještě získat adresy požadovaných funkcí
◦ Programátor procesu musí znát prototyp těchto funkcí
 Proces zavolá funkci, které předá název funkce, a OS
mu vrátí pointer na adresu této funkce
◦ dlsym
◦ GetProcAddress
 Programátor knihovny označí, které funkce exportovat

Answer 70

A

 Dynamická knihovna není nic jiného než spustitelný program – má svůj main, který se spustí při jejím
načtení
◦ dllmain pod Windows
◦ .interp sekce v ELF formátu pod Linuxem
 Dynamická knihovna má tak možnost inicializovat se
◦ A stejně tak má možnost deinicializace před uvolněním
 dllmain
 sekce .fini

Answer 71

A

 Dynamic loading se hodí např. pro načítání plug-inů
 Ale co když budeme namapovat dynamickou knihovnu hned při spuštění programu?
◦ Buď v případě, že program knihovnu vyžaduje a tudíž nemá smysl řešit její podmíněné načítání
◦ Anebo v případě, kdy knihovna patří OS, který jejím prostřednictvím poskytuje služby procesu
 V hlavičce programu se označí, které knihovny má OS
dynamically load rovnou při zavádění programu

Answer 72

A

Ve zdrojovém kódu se proměnné ukazující na
symboly (funkce, proměnné, atd.) knihovny označí
◦ Např. pomocí __declspec (dllimport) pod Windows
◦ Značky jsou uvedeny v samostatné sekci v programu
–> Procedure Linkage Table (PLT)
–> Např. .rel.text pod Linuxem
◦ Značka říká, že se má na příslušnou adresu zapsat
hodnota získaná dlsym/GetProcAddress
–> Zařídí zavaděč knihovny - OS

+ example v přednáškách (3/26CZ)

Answer 73

A

 Do paměti se může zavést několik knihoven, tj. každá knihovna se může pokaždé zavést na jinou virtuální adresu
◦ Potřebujeme tzv. Position Independent Code (PIC)
◦ Překladač musí zajistit, aby se veškerý kód adresoval relativně k program counteru (IP registr)
◦ Alternativě se používala relokovatelný kód (např. před Vista), kdy zavaděč programu modifikoval kód knihovny ještě před spuštěním tak, aby šla spustit z adresy, kam byla zavedena

Answer 74

A

 Relokace vyžaduje přepsání kódu knihovny jejím zavaděčem
 Lepší je vytvořit tabulku, Global Offset Table (GOT), ve které budou adresy symbolů knihovny, a které (adresy) tam zapíše zavaděč knihovny
◦ Kód tedy bude symbol dereferencovat 2x
◦ GOT bude privátní pro každý proces
 A nezměněný kód knihovny tak bude sdílený pro všechny procesy

Answer 75

A

 Adresy symbolů knihovny není nutné resolvovat ihned, ale až bude třeba
1. Proces volá funkci knihovny
◦ Každá knihovnou exportovaná funkce má své ordinální číslo n – tj. volá se adresa PLT[n]
2. PLT[n] ale zatím ukazuje na rutinu zavaděče, která se zavolá jako první a resolvuje adresu rutiny do GOT než zavolá vlastní funkci
◦ Než je funkce zavolána, GOT se upraví tak, aby se příště už rovnou volala funkce knihovny, ne rutina zavaděče

Answer 76

A

 Některé útoky se spoléhají na to, že se předem ví, co se bude nacházet na konkrétních adresách
◦ Např. je možné změnit adresu v GOT tak, aby ukazovala na jinou funkci, než na kterou má
 Jednou z možností obrany je randomizace adres kódu tak, aby adresy byly náhodné a nedaly se uhádnout
◦ Což jde tím lépe, čím větší je virtuální adresový prostor

Answer 77

A

 Některé služby OS nelze vyřídit pouze v uživatelském adresovém prostoru, ale musí se změnit CPL na CPL jádra a předat jádru řízení programu
◦ Toto dokáže sw přerušení - x86 instrukce int
 Proces buď sám vygeneruje int, s číslem přerušení dedikovaného OS pro tyto účely, aneb zavolá rutinu v dynamické knihovně OS, která sama posléze vygeneruje příslušný int
 Stejné princip jako u volání MS-DOS API

Předání parametrů jádru:
 Při použití int se parametry předávají v registrech, nebo přes zásobník
 Vybrané registry mohou obsahovat virtuální adresu do virtuálního adresového prostoru procesu, kde je připravena nějaká struktura blíže specifikující, co má OS udělat

Answer 78

A

 Procesor použije číslo přerušení jako index do tabulky vektorů přerušení, aby získal adresu obsluhy přerušení
◦ Tabulka nemusí být na adrese 0000:0000 jako po startu v real mode, ale její pozici udává registr IDTR
 Procesor nastaví CS:EIP na získaný vektor přerušení
◦ V zásobníku jsou uloženy registry přerušeného vlákna flags, cs a eip; cs:eip ukazují na instrukci, která se má vykonat po návratu
 Jádro OS považuje zásobník přerušeného vlákna za nedůvěryhodný, protože v něm nemusí být místo, a tak bude používat svůj zásobník

Answer 79

A

 Obsluha přerušení vykoná pouze nezbytnou část
požadované činnosti
◦ Lze-li něco odložit na později, odloží se to – viz Bottom Half dále
◦ V takovém případě ale nelze vrátit řízení přerušenému vláknu, protože operace nebyla dokončena => vlákno se musí uspat a řízení se předá jinému vláknu
 Jádro také předá řízení jinému vláknu tehdy, když bylo cílem vlákno uspat nebo ukončit
 Plánovač vybere jiné vlákno, které je ve stavu runnable

Answer 80

A

 Po dokončení obsluhy přerušení už jádro ví, kterému procesu předá řízení
 Před ukončením obsluhy přerušení tedy jádro vybere zásobník vlákna, kterému předá řízení
◦ Tj. v zásobníku jsou registry CS:EIP a flags tohoto vlákna
◦ Pokud jde o jiné vlákno, musí se obnovit i zbývající registry
 Obsluha přerušení udělá instrukci iret, která nastaví registry CS:EIP a flags z aktuálního zásobníku SS:ESP
◦ A z CS:EIP procesor určí svůj režim - CPL

Answer 81

A

 x86 (IA-32) struktura, kam se ukládá kontext přerušené činnosti procesoru
◦ V x86 terminologii task, jinak jde o vlákno
◦ Lze vytvořit pro každé vlákno v systému
◦ Používá se např. k implementaci syscall jako rychlejší varianty int

 Deprecated na x86-64

Answer 82

A

 int generovaný programem je synchronní událost vůči běhu programu => lze toho využít

syscall/sysret jsou speciální instrukce, které toho využívají a dokáží přepnout procesor do režimu jádra cca 3x rychleji než int
◦ int – původní, pomalý mechanismus volání jádra
◦ sysenter/sysexit – protected mode, compatibility mode, vyžaduje TSS
◦ syscall/sysret – long mode
 Jádro musí nastavit zásobník v době, kdy může dojít např. nemaskovatelnému přerušení

 Kdy lze použít int, sysenter/sysexit či syscall/sysret
závisí na dostupném hw a jádru OS
◦ V každém případě se ale jedná o netriviální činnost, které by mělo být volající vlákno ušetřeno
 OS namapuje do virtuálního adresového prostoru procesu speciální stránku, která zavolá službu jádra jádrem očekávaným způsobem
◦ Kód na této stránce poskytne jádro OS, volající vlákno pouze udělá call na adresu této stránky

Answer 83

A

 libc má funkci syscall
 ntdll.dll má KiFastSystemCall a KiFastSystemCallRet
 Adresa musí být fixní, aby byla známa RTL v době
jejího psaní
◦ Buď fixní adresa, např. 32-bit Win
 call dword ptr [adresa]
◦ Nebo se použijí registry fs (Win) či gs (Linux), přičemž segmentový registr odkazuje na Thread Control Block
 call fs:[offset od začátku TCB]

Answer 84

A

 Výjimka je přerušení generované procesorem, když dojde k
◦ Trap – např. breakpoint
◦ Fault – opravitelná chyba, program může pokračovat
 Např. Page Fault
◦ Abort – neopravitelná chyba
 Např. Double Fault – dojde k Page Fault, ale handler je ve stránce, která není v RAM
◦ Některé výjimky přidávají na zásobník extra hodnotu s chybovým kódem, který je třeba odstranit před návratem z obsluhy přerušení, aby se na vrcholu byly cs, ip a flags

Answer 85

A

 V případě, že procesor nedokáže zavolat obsluhu
výjimky, dojde k Double Fault
◦ Pokud ani pro ni nebude obsluha, dojde k Triple Fault
 Což je samo o sobě známkou, že je něco špatně v obsluze první výjimky
 Výjimku nelze zamaskovat
 => buď budeme psát perfektní, bezchybný kód
 Anebo alespoň spolehlivé obsluhy výjimek

Answer 86

A

 Pokud by OS neměl handler vyjímek, došlo by
k restartu počítače
◦ OS ho má – tj. dojde-li k vyjímce v uživatelském procesu, OS vyjímku zachytí
 Např. dělení nulou je Fault
◦ Pokud proces nenastavil svůj handler, OS program ukončí
◦ Pokud ho proces nastavil, OS mu předá řízení
◦ Opět se k tomu použije Thread Control Block

Brainscape's Knowledge GenomeTM

KIV/OS Flashcards

Brainscape's Knowledge Genome^TM