Architektuta rodiny operačních systémů Windows NT

POSIX je zkratka z anglického sousloví portable operating system interface based on Unix (přenositelná systémová rozhraní založená na Unixu) a označuje sadu mezinárodních standardů, které popisují aplikační rozhraní v operačních systémech založených na Unixu. Pokud by výrobci operačních systémů tyto standardy implementovali, rozhraní různých operačních systémů by byla definována stejně a stejně by se také chovala, což by ušetřilo práci programátorům aplikací, kteří by neměli tolik problémů s přenositelností na jiné platformy.

Z historických důvodů Windows původně ze všech těchto standardů implementovaly pouze POSIX 1. Windows Vista a Windows Server 2008 s sebou přináší implementaci standardů POSIX v podobně SUA (Subsystem for Unix–based Application – subsystém pro aplikace založené na operačním systému Unix). Tato rozšířená varianta subsystému POSIX implementuje kolem 2 000 funkcí různých unixových aplikačních rozhraní a obsahuje kolem tří set unixových programů. Subsystém SUA je dostupný na Windows Server 2008 a v Ultimate a Enterprise edicích Windows Vista.

Na rozdíl od subsystému Windows, bez kterého celý operační systém nemůže fungovat, POSIX se spouští jenom tehdy, pokud si uživatel přeje spustit proces určený pro tento subsystém. Konfigurace obou subsystémů je uložena v registru pod klíčem
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Subsystems

Na Windows 10 byl POSIX nahrazen Windows Subsystem for Linux (WSL). Vzhledem k tomu že Linux je OS POSIX kompatibilní, je možné očekávat, že zde rozhraní POSIX bude implementováno.

Z obrázku je patrné, že hlavním procesem subsystému POSIX je psxss.exe , který se nachází v systémovém adresáři. Také vidíte, že hlavní proces subsystému Windows nese název csrss.exe a že subsystémy mají i komponentu běžící v režimu jádra. Jedná se o ovladač win32k.sys , který se stará o správu grafického uživatelského rozhraní a grafiky vůbec.

Na tomto místě může vyvstat otázka, proč každý subsystém nemá svůj vlastní ovladač jádra. Důvodem je vysoká duplicita kódu. Vývojáři Windows se rozhodli tomuto nebezpečí předejít, a proto subsystém POSIX využívá funkcí (a knihoven DLL) poskytovaných subsystémem Win- dows včetně ovladače win32k.sys. Situaci znázorňuje obrázek 2.7. Kdyby tomu tak nebylo, musely by existovat dvě sady knihoven DLL a dva různé ovladače pro obsluhu grafického uživatelského rozhraní. Kód obou sad knihoven a ovladačů by však byl na mnoha místech totožný, což je v programování nežádoucí, protože dochází ke zvýšení rizika vzniku chyb.

Struktura subsystému Windows je složitější než v případě POSIXu. Skládá se z následujících komponent: * Hlavní proces subsystému csrss.exe a knihovny DLL, které používá. * Ovladač jádra win32k.sys a drivery grafické karty a videa. * Vrstva knihoven DLL zajišťující překlad volání dokumentovaných funkcí Windows API na volání nativních (a často nedokumentovaných) rutin z knihovny ntdll.dll, která je zodpovědná za volání jádra.
Mezi tyto knihovny patří kernel32.dll, user32.dll, gid32.dll či advapi32.dll.

Mezi úkoly hlavního procesu subsystému patří vykreslování oken konzolových aplikací a podpora 16bitových programů určených původně pro operační systém MS–DOS. Csrss.exe také dostane oznámení, kdykoliv dojde k spuštění nového či ukončení již běžícího procesu nebo vlákna. Ve svém adresovém prostoru si uchovává vlastní kopii seznamu všech běžících procesů a vláken, aby pro ně mohl vyřizovat požadavky, jež mohou vzniknout při volání některých funkcí Windows API.

V dobách předcházejících Windows NT 4 do hlavního procesu subsystému patřily i moduly, které se starají o grafické uživatelské rozhraní a grafické kreslení vůbec. Vývojáři se tímto uspořádáním pravděpodobně chtěli přiblížit elegantní struktuře operačních systémů založených na mikrojádru. Taková struktura však vyžadovala velmi častá systémová volání a přepínání kontextu procesů. Ovladače grafické karty a obrazovky totiž běžely v režimu jádra, takže pokud nějaká aplikace chtěla například překreslit okno, bylo nutné přepnout kontext na hlavní proces subsystému, kde sídlil správce grafického uživatelského rozhraní, a následně se přepnout do režimu jádra, aby ten mohl doručit požadavek na překreslení ovladači grafické karty.

Systémová volání a přepínání kontextu mezi procesy patří mezi časově náročné operace, což mělo negativní dopad na výkon systému jako celku. Situace se výrazně nezlepšila ani po provedení mnoha optimalizací (byl upraven plánovač procesů a csrss.exe dokonce mohl číst některé oblasti paměti jádra, aby se ušetřilo kopírování). Vývojáři proto ve Windows NT 4 přesunuli správce grafického uživatelského rozhraní a ostatní grafické funkce do ovladače win32k.sys, čímž se snížil počet systémových volání a přepínání procesů. Jak již víte, jádro systému sdílí společný paměťový prostor a může komunikovat s ovladači grafické karty bez použití systémových volání.

Ovladač win32k.sys se tedy stará o grafické uživatelské rozhraní; spravuje okna, tlačítka, textová pole, obsluhuje myš a klávesnici. Umožňuje také kreslení různých grafických útvarů, jako jsou body, přímky či křivky. Ovladač se postará, aby se požadavky na vykreslování dostaly k správným ovladačům grafiky, tudíž aplikace, jež využívají GUI, vůbec nemusí (a většinou ani nepotřebují) vědět, jakou grafickou kartou počítač disponuje a jak se s ní zachází. Win32k.sys se chová podobně jako HAL – smazává rozdíly mezi různými kusy hardware. Bránu k ovladači win32k.sys tvoří knihovny gdi32.dll a user32.dll. První z nich obsahuje rutiny pro kreslení různých grafických útvarů (body, čáry, křivky) a druhá exportuje funkce pro práci s prvky uživatelského rozhraní, jako jsou okna, menu či ikony.

Mezi velmi důležité knihovny DLL také patří kernel32.dll, jenž exportuje vybrané části exekutivy (práce s procesy a vlákny, správa paměti, synchronizace), a advapi32.dll, která obsahuje rozhraní pro práci se službami a bezpečnostním modelem.

Jedná se pouze o pseudoproces, který nevykonává žádnou činnost v uživatelském režimu. Na disku nenajdete žádný soubor, který by obsahoval jeho kód a data, ani žádné knihovny DLL, jenž by využíval. Úkolem Nečinných procesů je spotřebovávat čas procesoru, když žádná součást operačního systému ani žádná aplikace nemá co na práci. Jádro vytvoří tento proces během raných fází inicializace operačního systému. PID Nečinných procesů je vždy roven nule.

Proces System také nevykonává žádný kód v uživatelském režimu, a tudíž nepoužívá žádné knihovny DLL a nenajdete žádný soubor s příponou .exe , který by jej reprezentoval. Už ale nejde čistě o pseudoproces; v jeho kontextu běží skupina vláken známá pod označením pracovní vlákna (worker threads). Jádro tato vlákna vytvoří během bootovacího procesu a jejich úkolem je vykonávat činnosti, jenž jim někdo zadá. Pracovní vlákna stráví většinu času čekáním, až jim nějaká součást jádra (nebo ovladač) určí, co mají vykonat. Jakmile práci dokončí, čekají na další zadání.

Jádro využije služeb pracovních vláken ve chvíli, kdy potřebuje vykonat úkol, který je časově náročný (a tudíž by mohl brzdit výkon systému, kdyby nebyl proveden asynchronně), nebo nemůže být splněn za aktuálních podmínek. V takovém případě jádro předá úkol na bedra této speciální skupině vláken. Vlákna většinou dokončují zpracování požadavků od hardware, které nebylo možné provést při obsluze přerušení. Dále je využívá například správce paměti pro zapisování „špinavých“ (dirty) stránek z vyrovnávací paměti na disk.

Spolu s Nečinnými procesy je System jediným procesem s pevně daným číslem PID. Toto číslo má v jeho případě od Windows 2000 do Windows Serveru 2019 hodnotu 4. V předcházejících verzích neslo hodnotu 1.

Smss.exe je spuštěn v poslední fázi startu jádra a jedná se o první proces, který vykonává kód v uživatelském režimu. Provede poslední fázi inicializace operačního systému, který je pak připraven na přihlášení uživatelů.

Jak název napovídá, hlavním úkolem tohoto procesu je vytváření relací. Relaci si můžete představit jako ohradu, ze které ten, kdo je v ní uzavřen, nevidí ven a zároveň nikdo nevidí dovnitř. Tyto ohrady se využívají pro oddělení prostoru jednotlivých uživatelů. Díky nim například každý uživatel může mít namapované disky pod jinými písmeny. Jednotlivé relace se označují číslem.

Smss.exe nejprve vytvoří relaci 0, která se též označuje jako konzolová relace. V rámci ní běží systémové procesy, služby a všechny procesy uživatele, který se přihlásí jako první. Pro každého dalšího uživatele vytvoří správce další relaci.

Pro každou novou relaci správce spustí jednu kopii procesu winlogon.exe. Smss.exe je též zodpovědný za inicializaci hlavního procesu subsystému Windows – csrss.exe. Pro relaci 0 se místo Winlogonu spouští wininit.exe.

Jakmile dokončí svoji práci, správce relací navždy hlídá hlavní proces subsystému Windows a všechny kopie programu winlogon.exe. Pokud zjistí, že některý z těchto procesů byl neočekávaně ukončen, vyvolá modrou obrazovku smrti s kódem STATUS_CRITICAL_SYSTEM_PROCESS_DIED.

Úkolem procesu winlogon.exe je umožnit uživateli přihlášení pomocí grafického uživatelského rozhraní. Může autentizovat uživatele různými způsoby, nejčastěji se ale stále používá zadání uživatelského jména (login) a hesla. Jednotlivé metody autentizace jsou implementovány v oddělených knihovnách DLL.

Winlogon v sobě má zabudovanou jednoduchou metodu ochrany proti programům, které se snaží zachytit údaje, jež uživatel zadal při pokusu o přihlášení. Většinou se jedná o tzv. keyloggery – programy, které zaznamenávají stisky jednotlivých kláves. Aby takový program nemohl přesně určit, kdy uživatel zadává přihlašovací údaje, může být Winlogon nastaven takovým způsobem, že před zobrazením přihlašovací obrazovky je třeba stisknout speciální kombinaci kláves.

Přihlašovací obrazovka i obrazovka, která uživatele vyzývá k stisku této kombinace kláves, se může mírně lišit v závislosti na verzi operačního systému.

Jako výchozí kombinace je nastaven známý „trojhmat“ Ctrl+Alt+Del. Trik spočívá v tom, že jakmile Winlogon zjistí, že tato kombinace byla stisknuta, tuto informaci pohltí a zobrazí okno, kam uživatel vyplní přihlašovací údaje. Přesněji, o stisku aktivační kombinace se dozví okno s názvem SAS Window, které je též zodpovědné za její pohlcení.

Pokud tedy keylogger neoperuje v samotném jádře systému nebo neinfiltroval do adresového prostoru procesu winlogon.exe (například v podobě knihovny DLL), nemůže stisk aktivační kombinace přímo detekovat, a tedy přesně zjistit, kdy uživatel zadává přihlašovací údaje.

Jakmile uživatel zadá login a heslo, Winlogon tyto údaje odešle procesu lsass.exe, kde proběhne jejich ověření. Pokud vše dopadne dobře (uživatel zadal správné jméno a heslo), lsass.exe zjistí, jakými oprávněními uživatel disponuje, a vytvoří tzv. token. Jedná se o objekt, kterým se pak uživatel prokazuje, potřebuje-li doložit, že má oprávnění k provedení určité operace.

Pokud má uživatel administrátorská práva a je-li zapnut mechanismus UAC (User Account Control), lsass.exe vytvoří tokeny dva. První z nich v sobě obsahuje všechna oprávnění, kterými uživatel disponuje. Druhý obsahuje jenom vybraná z nich. S pomocí druhého tokenu pak Winlogon vytvoří procesy, které provedou inicializaci prostředí. Token s omezenými právy se použije, kdykoliv uživatel spustí nějakou aplikaci, jež nevyžaduje administrátorská práva.

Pokud se uživatel pokusí spustit program vyžadující oprávnění administrátora, UAC se může dotázat (záleží na nastavení systému), zda chce daný program, který vyžaduje administrátorská práva, a tudíž by mohl být pro systém nebezpečný, spustit. Pokud dá uživatel spuštění zelenou, použije se pro daný program token, který obsahuje všechna uživatelova oprávnění.

Winlogon zůstává aktivní i po úspěšném přihlášení uživatele. Kromě toho, že je jeho povinností zajistit i odhlášení, stále čeká na onu aktivační klávesovou kombinaci a v případě, že zjistí její stisknutí, zobrazí dialog, který vidíte na obrázku 2.11. Winlogon také může být nakonfigurován tak, že spustí rovnou Správce úloh.

Jakmile Winlogon obdrží tokeny od LSASS, může být zahájena inicializace pracovního prostředí uživatele. Tato činnost již nespadá do pravomocí tohoto procesu, ale do kompetence procesů, jejichž názvy jsou uvedeny v hodnotě Userinit v klíči
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\Current Version\Winlogon.

Winlogon přečte obsah této hodnoty a pokusí se všechny nalezené procesy spustit.

Inicializace pracovního prostředí spočívá v podstatě jen ve spuštění startovacích skriptů a předání řízení shellu, jehož název userinit.exe nalezne pod hodnotou Shell ve stejném klíči, jako Winlogon hledal hodnotu Userinit. Výchozím shellem pro všechny uživatele je Průzkumník Windows (explorer.exe), který zodpovídá za zobrazení pracovní plochy a umožňuje uživateli mimo jiné procházet adresářovou strukturu a spouštět další programy.

Mnoho součástí Windows je implementováno jako služby – programy běžící na pozadí, které ve většině případů nepotřebují (a ani nevyhledávají) interakci s uživatelem a jejichž běh nezávisí na tom, zda je přihlášen či nikoliv.

Interně systém Windows mezi služby řadí i ovladače jádra, ačkoliv ty nepatří mezi entity, o které se správce služeb (Service Control Manager – SCM), reprezentovaný procesem services.exe, příliš stará. Jeho hlavním úkolem je instalovat, spouštět a zastavovat služby určené pro běh v uživatelském režimu a posílat jim další druhy příkazů.

Službu tvoří obyčejný spustitelný soubor formátu PE s příponou .exe , který navíc obsahuje speciální kód pro komunikaci se správcem. Na rozdíl od normálních aplikací, více služeb může sdílet virtuální adresový prostor jednoho procesu. Vše záleží na nastavení konkrétní entity. Kód služeb, které nemají vlastní proces, je vykonáván v kontextu instancí procesu svchost.exe, který je pro jejich „hostování“ přímo určen.

Pro pohodlnou kontrolu služeb je připravena aplikace services.msc, která nejen zobrazí seznam všech nainstalovaných služeb a jejich aktuální stav, ale umožňuji s nimi i manipulovat.

Konfigurace všech služeb se nachází v registru pod klíčem
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services.

Každá nainstalovaná služba má zde vyhrazený jeden podklíč. Ten nese její interní jméno a může obsahovat další klíče s informacemi o jejím nastavení. Na obrázku 2.13 vidíte příklad podklíče pro službu s interním jménem ALG. Mezi nejdůležitější hodnoty patří:

Hodnoty Description a DisplayName mají pouze informativní charakter. Jejich obsah zobrazuje snap-in services.msc ve sloupcích Název a Popis. Pokud je hodnota DisplayName prázdná, nebo vůbec neexistuje, utilita zobrazí ve sloupci Název interní jméno.

Položka ErrorControl určuje, jak se má správce zachovat, když při spouštění služby dojde k chybě. Možné hodnoty a popis chování správce naleznete v tabulce 2.

Hodnota ImagePath v sobě uchovává název souboru služby. Pokud není hodnota přítomna, SCM předpokládá, že soubor služby se nachází v systémovém adresáři a jmenuje se X.exe , nebo X.sys , kde X je interní název služby.

Podle hodnoty Start se SCM rozhodne, kdy může být služba spuštěna. Tabulka 3 popisuje hodnoty, kterých tato položka může nabývat.