Dávám Windows šanci aneb Vista z pohledu Linuxáka [3]

8.1.2008 12:27 | Přečteno: 4425× | Windows | poslední úprava: 8.1.2008 12:28

Slíbil jsem, že půjdeme více pod pokličku, tak se do toho pustíme. Řeknu vám, že někdy na té pokličce leží pořádné závaží a dostat se do hrnce je značně obtížne. Dnes se pokusíme zjistit co se v Redmondovic rodince kuchti v hrnci s nápisem paměť procesu a také v malém rendlíku s nápisem csrss.exe.

Kde pro informace?

V případě Windows je třeba jednoznačně jít ke zdroji, tedy na msdn.microsoft.com nebo přidružené weby. Na informace, které člověk pomocí googlu najde někde mimo se nejde příliš spolehnout. Množství informačního šumu, polopravd či vyložených bludů, které se v nich nacházejí je úchvatné. Jeden zdroj čerpá z jiného a z informace typu "já si myslím, že by to tak mohlo fungovat, tak to tak napíšu" se pomalu stane taková virtuální pravda.

Kolik paměti využívá proces?

To není tak jednoduchá otázka, jak by se na první pohled mohlo zdát. Získat tento údaj v operačním systému s virtuální paměti a sdílením, mmapovavnými soubory a podonbně je naopak úkol netriviální. Jak na to v linuxu jsem před časem psal. Ve Windows je hlavním ukazatelem pamětí pracovní sada (Woking Set). Tato hodnota se rozpadá na 3 části- private, sharable a shared. První část je uživatelům předkládána jako velikost procesu. Je to implicitní hodnota uvedena ve správci úloh a v nástroji "Sledování prostředků". Získat lze ještě hodnotu Virtual size a Commited (český překlad, Svěření, je kouzelný). Každopádně pokud se windowsáka zeptáte kolik u něho zabíta Firefox tak vým odpoví hodnotou vyčtenou buďto ze sloupce Working Set, nebo Private Working Set.

Microsoft to v helpu uvádí následující:

To determine which program is using the most memory, follow these steps:

• 1. Open Task Manager by right-clicking the taskbar and then clicking Task Manager.
• 2. Click the Processes tab.
• 3. To sort programs by memory usage, click Memory (Private Working Set).

Jsem nyní poměrně pracovně vytížen takže jsem to blíže nezkoumal, bral jsem to tak, že WS odpovídá linuxí hodnotě RSS. K práci ale potřebuju VirtualBox a všiml jsem si, že při spuštění dvou strojů (oba mají přiděleno 512 MiB paměti) mají oba jednotlivě zhruba 75 MiB WS a 200 MiB Virtual Size. V jednom ze strojů jsem spustil OpenOffice. S hodnotami to téměř nehlo. Zavřel jsem oba stroje a najednou jsem měl o více než gigabajt volné paměti více. Zázraky. Kouzla. Divy. Čáry. Černá magie. Toto mě přinutilo prozkoumat blíže o co jde.

Co o tom píšou hoši z Redmondu?

The working set of a program is a collection of those pages in its virtual address space that have been recently referenced. It includes both shared and private data. The shared data includes pages that contain all instructions your application executes, including those in your DLLs and the system DLLs. As the working set size increases, memory demand increases.

Máte pocit, že WS je tedy hodnotou, ze které lze o paměti využité procesem usuzovat jen velmi obezřetně? Co kdybych vám ukazal systemové volání umožnující nastavit spodní a horní limit WS procesu?

Vybavení těmito vědomostmi si můžeme říst co tedy vlastne WS znamená- je to často využívána paměť procesu, kterou systém bude držet ve fyzické paměti jak jen to půjde aby zamezil stránkování. Které stránky do WS spadnou je na operačním systému a podle jednoho blogu na msdn se využívá LRU strategie. Pokud se systém rozhoduje špatně tak je možné nastavit limity WS a systém se bude snažit tyto mantinely dodržet. Každopádně na počítači s menším množstvím paměti bude mit aplikace za stejných podmínek menší WS než na počítači s větší paměti.

Dalo by se říci, že systém udržuje pro každý proces množinu aktivních stránek. Existuje nějaká hodnota (pravděpodobně závislá na množství volné paměti a dalších parametrech), která určuje limit stáří stránky aby se vešeldo WS dané aplikace. Jedním z parametrů je zcela určitě to, zda je aplikace minimalizována či ne. Minimalizací aplikace způsobí zmenšení WS řádově o megabajty přičemž samotný akt minimalizace téměř žádné uvolnění paměti nezpůsobí. Stránky, které z WS vypadnou systém ve volných chvílích zapisuje na disk pokud je potřeba (pokud se jedná o kód nebo data uložená v .exe nebo .dll tak to není zapotřebí- jako miniaturní stránkovací soubory se využijí přímo tyto soubory na disku). To neznamená, že je zcela uvolní. Pouze v případě, že by to bylo zapotřebí provést tak už není potřeba odstránkovat. To je důvod, proč windows vykazuje v zásadě vždy značné využití stránkovacího souboru- jsou tam v holném počtu kopie stánek, které jsou zároveň i v paměti.

Můžeme tedy odpovědět na odázku z nádpisu kapitoly? Ano. Odpověď zní, že ve Windows není žádný spolehlivý prostředek jak určit velikost využité paměti procesem. Žádná hodnota poskytována systémem to neumožní spolehlivě zjistit. Zavřít aplikaci a sledovat kolik volné paměti přibude je samozřejmě taktéž pochybný a vysoce obskurní způsob. Stačí že zavřením aplikace zanikne nějaký soubor, který byl v diskové cache a dostaneme mylné výsledky.

Paměť z ptačí perspektívy

Celou fyzickou paměť lze rozdělit do čtyř základních oblastí - volná paměť, paměť obsazená programy, (disková) cache a pamět jádra. Poslední zmíňovaná se navíc dělí na paměť stránkovatelnou a nestránkovatelnou. Vista se snaží aktívně využít volnou paměť. Při typickém scénáři využití počítače v Gentoo jsem dosáhl zaplnění celé paměti zhruba na konci pracovního dne. Vista to bezpečně zvládne do dvou hodin. Může za to featura superfetch a teké množství procesů, které na pozadí provádějí nejrůznější činnosti včetně např. skenování disku z cílem nalézt malware nebo indexace obsahu. Přínos superfetche a readyboostu je předmětem mého současného zkoumání.

Priority IO

Vista implementuje priority IO a systémové nástroje toho využívají. A nutno říci, že to opravdu funguje dobře. Pokud s diskem pracuje nějaká aplikace tak se scanování disku (s prioritou iddle) zastaví. Lze očekávat, že aplikace toho budou také brzy využívat. V Linuxu jsou IO priority součástí CFQ scheduleru a lze je ovládat pomocí ionice. Distribuce toho zatím dle mých pozorování prakticky vůbec nevyužívají. Přitom takové updatedb s nízkou prioritou by zcela jistě nejednomu ušetřilo narvy. Vista: dvojka, Linux: trojka. Váha: 3.

Na konzoli kuk!

Proč má v XP konzole (cmd.exe) klasickou dekoraci okna a widgety a nepoužívá se aktuálně nastavený skin? Ve Viste dodá dekoraci DWM ale widgety (posuvník) jsou stále staré. Zato se ve viste nedá do konzole provést drag&drop. Blog na msdn dává částečné vysvětlení této záhady.

the command prompt window (like all console windows) is run under the ClientServer Runtime System (CSRSS), and CSRSS cannot be themed. But why can't CSRSS be themed? CSRSS runs as a system service, so any code that runs as part of CSRSS creates potential for mass havoc. The slightest mis-step could crash CSRSS, and with it the entire system. The CSRSS team decided that they didn't want to take the risk of allowing the theme code to run in their process, so they disabled theming for console windows.

O CSRSS se příliš hodně informací získat nedá. Víme že je to klientská část win32 API, stárá se o vytváření procesů a thready, běží jako systémová služba v režimu jádra a tudiž pád tohoto procesu stáhne dolů celý operační systém. Aha, na jednu zcela bezvyznamňoučkou věc bych zapomněl- stará se o konzoly. A to tak, že cmd.exe a PowerShell běží v režimu CSRSS.

Hlavním uváděným důvodem proč není na okno konzole použitý theme je tedy snaha zamezit tomu, aby chyba v kódu vykreslujícím dekoraci oken a widgety nezpůsobila pád celého systému.

Proč ve Vistě nefunguje přetažení souboru nebo složky do konzole? To je vysvětleno v tomto textu v kapitole "User Interface Privilege Isolation". Konkrétně se jedná o tento úryvek

A lower privilege process cannot:
* SendMessage or PostMessage to higher privilege application windows. These Application Programming Interfaces (APIs) return success but silently drop the window message.

Hezky vysvětleno. Zustává uz jen jediná prostá, taková neduležitá otázka: proč, u všech rohatých, běží konzole v režimu jádra se zvýšnými privilegiemi ikdyž ji spustí obyčejný uživatel? A není to tak náhodou docela velká chyba návrhu? Na první otázku se mi odpověď najít, i přes nemalé vynaložené úsilí, nepodařilo a dedukce taktéž nezabírá. Na druhou nechť si každý odpoví sám. Dle mého názoru se v hrci nazvanem csrss.exe vaří hnus fialový.

Toť pro dnešek vše. Příště bude určite jedna kapitola věnovaná tématu "Systém, který si žije svým vlastním životem" a další.

       

Komentáře

[rastos]

the command prompt window (like all console windows) is run under the ClientServer Runtime System (CSRSS), ... CSRSS runs as a system service, so any code that runs as part of CSRSS creates potential for mass havoc.

Nemám slov ...

Vlastne niečo ma napadá: onedlho všetky CLI programy vo Windows budú považované za apriori nebezpečné a anti-víry ich budú dávať do karantény. Zbohom HalloWorld.exe.

To, že už nepôjde urobiť drag&drop súboru z explorera do cmd.exe - jedna z mála užitočných trikov čo tam mali a oni to vyrazia ... Mimochodom, ešte stále sa to okno cmd.exe nedá dynamicky resizovať?

[Kuláš]

He, to je dost podivná logika. Je rozdíl, jestli něco běží pod něčím a jestli něco běží jako součást něčeho (run as a part of). O každém uživatelském programu se dá říct, že běží pod kernelem, že využívá služby kernelu. Kernel má maximální práva, znamená to, že je mají i uživatelské programy? Se podívej, pod jakým uživatelem běží ty CLI aplikace, které pustíš na Windows...

Stejně jako v kernelu nebo v nějaké službě běžící s právy roota, může být chyba, která může vést k získání roota, tak může být chyba i v CSRSS. V tom rozdíl není.

[miho]

Presne se to clovek nedozvi nicmene podle toho co pisou, tak cmd bezi "as a part of" csrss Ostatne jinak by nebyla obava z padu systemu v dusledku padu cmd.exe

Prava jsou take hodne zasmodrchana. Na cem zavisi je tzv. bezpecnostni token. Kazdopadne konzole ma oproti uzivateli, ktery je spousti zvysena prava jinak by nebyl problem s drag&drop.

[mess]

... konzole ma oproti uzivateli, ktery je spousti zvysena prava...

To je celkem podstatná bezpečnostní díra, nemyslíte?

[R]

deltree /y \

[rastos]

Deltree isn't present in Windows NT-based operating systems, including Windows NT, Windows 2000, Windows XP, Windows Server, or Windows Vista.

Know your enemy.

[R]

Aha, takze rd /s \

[mess]

Lepší je format C: .

[srigi]

Este lepsie je mke2fs -j /dev/XXX

[miho]

Ne nutne, sshd take bezi pod rootem. Konzole uzivatele pusti jen k jeho pravum, ale sama o sobe je ma zvysene aby mohla bezet v kontextu systemove sluzby. Dokud nekdo nenajde kde nenechal tesar dirku tak bude vse v poradku. Cele je to o tom, zda to neni "design flaw", ze konzole bezi v takovem rezimu.

[rADOn]

Konzole musi bezet jako systemovy proces kvuli kompatibilite s DOSem - widle nemaji zadnou abstrakci terminalu a programy pisici do konzole muzou bud pouzit podedena volani DOSu (vicemene k nicemu), nebo psat rovnou do graficke pameti ve znakovem rezimu. Coz vyzaduje strachat se v mapovani pameti procesu takze neprekvapi ze to bezi pod systemovym uctem.

Vylepseni jako ANSI.SYS a podobne se nikdy neujaly a win32 api tohle AFAIK nijak neresi, takze widlaci stale tahaji na noze kouli navrhu MSDOSu.

[I.X.]

Řešení by přitom bylo relativně prosté - oddělit po vzoru OS/2 konzoli Windows a DOSu. Jakkoliv řešení ála OS/2 taky žádnou extrémní bezpečností z hlediska systému nevynikalo, byl to IMHO krok správným směrem - a je s podivem, že MS tento krok nikdy neučinili.

Snad v tom byla nějaká korporační politika, snad šprajc vývojářů u MS (má to takhle konkurence, takže my to budeme mít jinak). To nemluvím o tom, že konzole Windows podporuje příkazy MS-DOSu někde na úrovni verze 5.0 (nabízí se otázka na téma vnitropodniková komunikace v rámci MS, ale to bych šel vyloženě OT).

[Kvakor]

Kdyby jenom mapovani pameti. DOSovske totiz musi bezet ve VM86, kde kazde presruseni a kazda privilegovana instrukce prepne zpet do protected modu, takze se musi odemulovat.

Navic se musi prevade adresy z Segment:Offset na linearni adresy, musi se spravne nastavit deskriptory pro registry (baze, limit, prava), LDT, brany a podobne silenosti, ktere si uz z hlavy nepamatuju.

K tomu se jeste musi pridat veci jako DPMI a obecne cely DOS extender, sluzby BIOSu (hlavne INT 0x10) plus ostatni sluzby typu mys (INT 0x33, pokud si dobre pamatuju). Proste zadna sranda.

A microsofti implementace stoji za starou belu (a nejspis zamerne), alespon ve srovnani s tim, co umel OS/2 nebo treba linuxove DOSemu. V tom jsem videl behat DOOMa i se zvukem .

[martyCZ]

K procesu csrss.exe se v odkazovane diskuzi nejfundovaneji vyjadruje Gabe. Diskuze ale predpoklada urcitou znalost Win32 a v diskuzi se primarne resi proc neni konzole kreslena pomoci vizualnich temat a proc po Vistama nefunguje drag&drop do konzole. Nicmene informace zde uvedene objasnuji, jaky je vztah csrss.exe ke konzolim a jake bezpecnostni riziko predstavuje rozhodnuti spoustet csrss.exe s vyssimi pravy.

V csrss.exe bezi smycka zprav - v podstate zaklad celeho Win32 GUI. Je to proto, ze konzolova aplikace nemusi smycku zprav implementovat (treba aplikace pro DOS). Kazde okno musi ale nejakou smycku zprav mit (resp. musi byt nejakou smyckou zprav obsluhovane) a tato smycka nekde bezet musi. Krome jednoho procesu csrss.exe pro vsechny konzole v systemu se nabizi jeste spoustet takovyto proces pro kazdeho uzivatele zvlast (resp. pro kazdy bezpecnostni token zvlast). V podstate jedinou vyhodou by byla moznost kreslit pomoci temat (ktere autori csrss.exe nechteli do procesu pro cely system tahat), nevyhodou by byl prepis celeho sytemu pro beh konzoli: odkaz.

Vysvetleni, jak (ne)funguje komunikace pomoci zprav mezi procesy na ruznych tzv. integrity levels ve Vistach, proc nefunguje a jaky to ma dopad na drag&drop do konzolove aplikace (+ srovnani s X): odkaz.

V tomto prispevku se docteme, ze rozdeleni obsluhy konzoli v GUI systemu do dvou procesu je bezne a opet je tu srovnani s X: odkaz.

Samotny konzolovy proces bezi s pravy uzivatele. Co bezi s vyssimi pravy je proces csrss.exe, ktery se stara o kresleni samotneho konzoloveho okna (analogie s X serverem bezicim pod rootem): odkaz.

Z vyse uvedeneho vyplyva, ze csrss.exe sice bezi s vyssimi pravy (a muze zpusobit pad celeho systemu), nicmene vzhledem k povaze tohoto procesu a jeho urceni je to v poradku. Vlastni kod konzolove aplikace bezi s pravy uzivatele a pad systemu (primo) zpusobit nemuze. Takoveto rozdeleni je otazkou rozhodnuti pri navrhu celeho systemu a tezko ho ted menit (kdyz v podstate neni duvod).

[Slahoun]

Velice pekne napsane, citelne, srozumitelne.

Ja bych v trosku selskem duchu doplnil, ze ostatni diskutujici by proste mohli zkusit zabehnout k prvnimu pocitaci s windows vista a a zkusit si z konzole vykonat nejaky ukon, na ktery nemaji ty spravna uzivatelska prava (nemaji prirazeny -"slepeny"- ten spravny token). A pak zkusili konzoli spustit skrze "Run As".

Zrejme by nedokazali nic zavratnejsiho, nez ze konzole respektuje aktualne dostupna uzivatelska prava. A to by melo pro zacatek stacit. Dalsi otazky mohou byt zajimave, ackoliv to nesmrtelnost chrousta taky.

[skeptik]

*THUMBS UP* Jeden z mála zdejších blogů, jejichž přečtení čtenáři něco dá (i když známky a váhy si stejně musí každý vyčíslit sám). Dík, jen pokračuj...

[Mandarinka]

Přesně tak. Paráda! Váš blogseriál je lepší, než cokoliv, co se na internetu (minimálně českém) tváří jako "článek", "recenze" nebo "detailní pohled"... Určitě to archivujte a vystavte někde na viditelném místě.

[dustin]

Také děkuji za odbornou úroveň a z mého pohledu nestrannost. Opravdových odborníků na windows je obecně poměrně málo a znalců detailů windows i současně linuxu jak šafránu.

[Heron]

Rýpavý komentář:

A nutno říci, že to opravdu funguje dobře..... Vista: dvojka

Dotaz: jak by to mělo fungovat na jedničku?

[happy barney]

rýpavá odpoveď:

Sú situácie, kde i ten najlepší je len druhý. Spýtaj sa pápeža.

[Luk]

Distribuce toho zatím dle mých pozorování prakticky vůbec nevyužívají. Přitom takové updatedb s nízkou prioritou by zcela jistě nejednomu ušetřilo narvy.

Schválně jsem se podíval do svého openSUSE 10.3 (protože se mi už dříve zdálo, že tam updatedb nebrzdí systém tak, jak jsem byl zvyklý z FC 6), a s potěšením zjistil, že se tam s I/O prioritou pracuje - ionice se používá jak pro updatedb, tak pro beagle.

[znalec Windows]

V rádoby odborném článku se nacházejí ZÁSADNÍ chyby z architektury jádra OS Windows. např jste nenašel memorydump, protože default konfigurace vytváří mimidump a ten leží v adresáři %SystemRoot%\Minidump. Process SCRSS není procesem v režimu jádra - je kompletně v USER mode. (v jádře je pouze WIN32K.sys, což je jeho bývalá část, které se stará o grafické operace) Dále nehodlám číst, hodnocení jsou irelevantní.

[koubax]

A co že o tom Vy tolik víte, nechtěl by jste napsat nějký článek? Některým lidem zde na ABíČku by se to hodilo