Vlákno názorů k článku ReactOS: svobodná náhražka končících Windows XP od Unknown - Tleskam tomuto projektu, konecne smysluplny open source projekt!

Souhlas - když něco opisujete, tak v tom nemůže být moc kreativity. Proto jsem konstatoval, že za kreativitu mají nula bodů.

Funkčním OS na starý HW pro domácí použití mohou být ty původní Windows. Samozřejmě s jiným browserem, a nejlépe úplně odpojené od inetu. I tak ale odvedou daleko lepší práci, než ReactOS, na kterém ani po 18 letech nerozchodíte prakticky nic.

Obávám se, že ReactOS na tom bude ještě hůře, než popisujete. Btw. sám windows nepoužívám (na pracovním počítači i na osobním notebooku mám jen Linux. Pouze na domácím stolním jsou windows...), přesto mám s Windows XP od začátku celkem dobré zkušenosti. Uživatele totiž nezajímá jestli mu spadl celý OS (časťejší u Windows), nebo jen jedna aplikace (časťejší u Linux), výsledek je stejný - uživatel nemůže pracovat. Já mám rád Linux proto, že software, který používám, nemá ve Windows dostatečnou náhradu, u většiny uživatelů je to naopak.

Už dlouho se mi nestalo aby widle lehly a rozbily disk. Když spadne aplikace tak jdou do kelu i data, která jsou v paměti té aplikace, takže tam žádný rozdíl není. Rozdíl je jen tam, kde má uživatel otevřeno víc aplikací najednou a shodí mu to zrovna ta kterou momentálně nepoužívá pro vytváření dokumentu.

To že aplikace nemůže poškodit systém je pěkný koncept, ale v praxi to tak zdaleka není. Pokud aplikace obsahuje driver nebo kernelový modul, může provést prakticky cokoliv. Pokud jede čistě v user mode, může například provést DoS, změnit nebo smazat data, donutit jakoukoliv běžící GUI aplikaci k libovolné akci posláním window message/eventu atd.

Všechno to samozřejmě může, ale běžné linuxové aplikace (co si uživatel nainstaluje z distibuce, nebo zkompiluje) to nedělají. Běžné windowsové aplikace (co si luzr postahuje z netu) to dělají.

Fakt? Zdroj?

Aha. Takže když použijete driver modemu usbser.sys na zařízení, na které není stavěný, tak to driver nerozdýchá. A z toho podle vás plyne, že jde o chybu driveru. Další problém spočívá v tom, že musíte informace hledat v DDK a MSDN Library. Plus samozřejmě musíte zkoušet drivery na ReactOSu, i když Windows mají checked build a kernelový debugger. No comment :)

Podle mého názoru to, že driver se zařízením jiným, než pro které je zamýšlen nefunguje, je v pořádku. Ale to, že shodí jádro, v pořádku není. Zvláště pak u USB, kde se počítá s připojováním i potenciálně zlomyslných zařízení.

Driver je kernelový modul, a jako takový může shodit jádro. Jestli je to nebezpečné, to záleží od konkrétního problému.

Driver nema co shazovat kernel, to je chyba systemu.

Boha. Driver tohoto typu je kernelový modul, a v principu může shodit systém. A pokud se driver snaží přistupovat k zařízení typu A jako by to bylo zařízení typu B, tak se můžete dočkat překvapení v podobě BSOD.

Driver neschodí kernel přímo. Co jsem viděl chybné drivery, tak ty schazovaly HW. Přepsaly paměť, poškodily tabulku přerušení atd. Pokud ovladači dovolíte přístup k HW, tak bohužel může HW poslat do kytek.

Ovladac = zcela konkretni HW je nefunkcni. Kdyz mi nebude fungovat ovladac ... cojavim ... klavesnice, tak mi nebude fungovat ta klavesnice. Ze to prepise pamet nekde jinde, je chyba kernelu, ten mu nema co dovolovat prepisovat nekde nejakou pamet.

Ale jelikoz je ve widlich samo mozny vsechno, tak se neni cemu divit.

Videl sem trebas driver k nejaky externi krabici na seriovym portu, po jehoz instalaci se widle dostaly do stavu, ze uz proste nenastartovaly (vubec). Takhle se proste nemuze chovat normalne navrzenej system.

To si představujete dost naivně. Když natáhnete driver pro nějaké zařízení, tak s ním bude zkoušet pracovat jak se zařízením daného typu: psát do paměti tam kde zařízení má mít buffer, psát na porty které zařízení má mít, atd. Pokud se zařízení chová jinak než se chovat má, může to v některých případech dopadnout dobře; v jiných případech to může vést k výjimce v driveru, a tedy pádu kernelu.

Ad Videl sem trebas driver... o jehoz instalaci se widle... proste nenastartovaly - znovu opakuji, že kernelový driver má možnost provést v systému prakticky cokoliv (ve Windows stejně jako v Linuxu, AIXu, Solarisu). Takhle se chovají normálně navržené systémy.

Na USB je plná separace přístupu k paměti od zařízení. Vše je tvrdě pod kontrolou driveru. Souhlasím, že v případě bus master PCI/PCIe nabo FireWire to může být problém. Stejně tak v případě driveru řadiče EHCI/OHCI/UHCI/XHCI. Ale opravdu ten jednoduchý polling rozbočovač zvaný USB koncová zařízení separuje kompletně.

Jinak mikrojádra mohou dokonale separovat drivery a to i pro případ PCI/PCIe, pokud je k dispozici IOMMU. Linux to umí pro tunelování zařízení do virtuálů. Vlastní OS, stejně jako Win NT, je naneštěstí/naštěstí (prof Tadembauma sem teď tahat nebudu a sám jednoznačný názor nemám) monolitický.

Souhlas, na USB nemají zařízení přístup k paměti stroje. Ovšem driver přístup má.

Diskusi ohledně monolitického, mikro- a modifikovaného mikrokernelu považuji za neplodnou. Pokud přes to co jsem tu už psal a linkoval pořád nevíte, jak vypadá typický monolitický kernel, tak s tím nic nenadělám.

Opakuji otázku: se kterou verzí Windows jste pozoroval ten problém s víceportovými konvertory USB-RS232?

Dobrý den,

omlouvám se za velkou prodlevu v odpovědi. Ale s Windows se osobně potkávám opravdu strašně málo a na fyzickém stroji jen když někomu přímo nějaký problém pomáhám řešit, např ve firmě, pro kterou zajišťujeme vývoj kompletních laboratorních přístrojů a to jen tehdy, pokud nám vše chodí při připojení pod Linuxem a jsou problémy specifické pro Win. Přitom shazovat takový stroj s připojeným zařízením za více než 1M kč s rizikem ztráty dat je nepřípustné. I Windows na pro účely kontroly některých projektů ve škole Virtuálu mám k dispozici jen na jednom školním počítači, kde Win7 64 instalovalo do QEMU naše IT.

Report o padání od našeho partnera se mi v nějaké solidní podobě nepodařilo získat. Je to pro něj podprahová věc, vyřešil to tím, že požaduje ACM bezdrátové seriáky v režimu single channel. Ale nespíš to byly Win7.

Konečně jsem našel čas a získal správně podepsaný INF a varianty Firmware, abych to otestoval na tom školním virtuálu.

Inf k VID:PID, které byly avizované jako Winows standardně podporované se automaticky v MS službách nevyhledal. Takže jsem nakonec device přeflashoval zpět na naše VID:PID v režimu single. Nainstaloval se a fungoval.

Zkusil jsem předělat firmware se stejnou identifikací na multi a připojit ho k již nainstalované-enumerované instanci driveru.

Souhlasím, že to je drsný test, nedivil bych se chybovým hláškám a nefunkčnosti zařízení. Ale přišel okamžitě ukázkový pád.
win7-64-acm-multi-after-single.png. To jednoznačně svědčí o špatně napsaném driveru, který při specifické chybě ve čtených datech (záměna deskriptoru) ze zařízení shodí systém.

Vrátil jsem single firmware a systém běžel. Provedl jsem kompletní odinstalování driveru vřetně jeho vymazání z /Window/inf/o­emX{.inf|.pnf}. Přešel na multi firmware.

Windows se po restartu korektně pustily, inf nenašly a vytvořili zařízení bez obladače s popisem že se jedná o ACM. Při požadavku o update ovladače došlo okamžitě k pádu.

win7-64-acm-multi-fresh-install.png

Souhlasím, že inf pro multi v pořádku není. Pro single však odpovídá doporučení od MS. Opět upozorňuji, žádný kernelový kód, který by byl od někoho jiného než MS, ve hře nebyl.

Ověřil jsem tedy, že MS má chybu v ovladači. Neověřil jsem, že lze takto napadnout počítač bez vědomé instalace infu, protože na VID:PID, co by Windows měly umět, se mi nepodařilo vyvolat automaticky instalaci. Opravdu překompilovávat firmware na všechny možné VID:PID jsem nezkoušel.Pokud ale existuje nějaký USB ACM, který skutečně MS podporuje, tak jsem přesvědčený, že multi firmware bude chodit jako spolehlivý vypínač Windows. I pokud MS vůbec žádný USB ACM nepodporuje, tak pokud si uživatel jakýkoliv takový modem pořídí a s ním dostane v MS doporučeném stylu vytvořený INF, tak lze takový počítač okamžitě shodit vložením zařízení se shodnou identifikací, ale mírně změněnými deskriptory.

Jinak USB ACM serial class je opravdu velmi jednoduché rozhraní přímo definované v USB specifikaci. To je, pokud nemají být aktivovaná nějaká proprietární rozšíření výrobce daného zařízení, tak opravdu stačí enumerace na CLASS a INFy k jednotlivým VID:PID jsou zcela zbytečné. Na Linuxu to takto chodí běžně a spolehlivě. Na Windows by to vedlo díky mizerné kvalitě ovladačů k nepěkným překvapení a je tedy nakonec dobře, že je použití jakýchkoliv zařízení komplikované a musí to vždy pro každou verzi výrobce testovat a pevně dávat VID:PID. Ale overhead na straně tvůrců zařízení je to extrémně velký. Kdyby věnovali jediné procento úsilí nutného pro podporu MS produktů podpoře Linuxu, tak by obecná podpora všech zařízení byla na Linuxu nádherná. A i přesto, že podpora výrobců je ještě menší, tak na tom je dnes GNU/Linux systém s bezproblémovostí podpory mnoha zařízení lépe.

Bohužel Vaší reálnou identitu neznám, abych mohl poslat notifikaci e-mailem, tak třeba se zde časem objevíte.

S pozdravem,

Pavel Píša

e-mail k dohledání na mojí webové stránce
http://cmp.felk.cvut.cz/~pisa/

Zdravím,

bohužel těch informací je málo, a upřímně HW není úplně moje specialita. Windows podporují USB ACM. BTW existuje několik patchů, které by vás mohly zajímat:
http://support.microsoft.com/kb/918365 (pro XP)
https://technet.microsoft.com/library/security/ms13-081 (možné řešení toho BSOD)

Popsaný problém může být způsobený jak problémem driveru ve Windows, tak problémem na straně microcontrolleru na druhé straně. To že něco funguje s jedním USB stackem zdaleka neznamená, že je to bezchybné. Například existuje (existovala) řada USB klíčenek s bezproblémovou funkcí ve Windows, které ale nešly na jiných OS. Typicky se chyba projevila po změně pořadí operací, nebo prostě Windows chyby dané implementace skously, na rozdíl od jiných OS. Na Linuxu koukněte na unusual_devs.h, je to dost poučné čtení.

Pokud chcete problém opravdu řešit, na prvním místě bych se kouknul, jestli existují nějaké patche pro USB stack na straně microcontrolleru. Pak bych na zařízení pustil USB Compliance Test.
http://www.usb.org/developers/tools/usb20_tools/
http://compliance.usb.org/resources/GoldSuite%20Test%20Procedure.pdf

Pokud testy projdou v pohodě, můžete odinstalovat ve Windows drivery zařízení (nejprve musíte nastavit environment variables devmgr_show_non­present_devices a devmgr_show_details na hodnotu 1), nainstalovat NetMon a zachytit USB frames.
http://msdn.microsoft.com/en-us/library/windows/hardware/jj151572(v=vs.85).aspx

Pokud se vám nepodaří najít zjevnou příčinu chyby, můžete se vrhnout na debugging kernelu. První přiblížení je tady:
http://blogs.technet.com/b/askcore/archive/2008/11/01/how-to-debug-kernel-mode-blue-screen-crashes-for-beginners.aspx
Z toho dostanete minimálně stack trace. Pak můžete nastavit breakpointy, kouknout na kód a frames, a zjišťovat jak dál. Zkusil bych debuggovat ve virtuálním stroji - ušetříte si spoustu restartů.

Pokud ani tohle nepovede k výsledku, ČVUT má v rámci smlouvy se společností Microsoft zajištěnou podporu. Můžete se obrátit na ně. Je důležité jim sdělit, že je vaše zařízení USB compliant (pokud tedy opravdu je).

Mimochodem nemusíte přece řešit všechno sám. Pokud působíte na ČVUT, máte po ruce lidi, kteří mají zkušenosti s psaním driverů a debuggováním kernelu. Namátkou Zdeněk Čulík, Filip Kroupa, možná Jan Kravar... a jistě přibyli nějací noví. Na MFF UK působí třeba Martin Děcký, jeden z autorů HelenOS. Já také nedělám všechno sám. Pokud mám k dispozici odborníky, který jsou v dané oblasti produktivnější, svěřím práci jim.

Dobrý den,

za odpověď děkuji. Co se týče USB stacku, tak zrovna ten konkrétní pochází od kolegy z firmy http://mujweb.cz/porazil/zload.html . Mohu to zkusit alternativně s dalším stackem, který prvně psal můj diplomant pro 8051, ale postupně jsme ho s dalšími kolegy hodně přepsali a rozšířili o podporu LPC2148, 1768 a dalších. Mohu zkusit stejný profil naimplementovat nad tímto druhým naším používaným stackem. Zdojákay zde: http://sourceforge.net/p/ulan/sysless/ci/master/tree/libs4c/usb/ Nebudu tvrdit, že nemáme v našich implementacích chybu. Komplianci proti Windows nástrojům jsme zatím netestovali. Ale odladěné to máme i s vlastním driverem pro vlastní protokol včetně uspávání jak na Win8 tak na Win2k. Mezi verzemi jsou celkem nepříjemné rozdíly v tom, které Power IRP se volají mimo kontext threadu a tak, ale jde to zvládnout napsat tak, že to chodí všude.

Určitě děkuji za odkazy na testování, zkusím, co je z toho opravdu free a užitečné. Roční členské příspěvky USB konsorcia neplatíme - nejsou potřeba, ale k některým nástrojům tak možná přístup mít nebudeme. USB vendor ale máme koupené.

Časem zkusím i ty aktuální záplaty. I když to mi připomíná, že máme teď (po mnoha letech bezproblémového provozu) podezření, že se v případě našeho vlastního driveru pro naší řídicí síť a zařízení začalo u zákazníků s poslední verzí Win7 a Win8 nejspíš po nějakých updatech dít cosi velmi podezřelého. Když nastavím logování uvnitř našeho driveru, tak přes DebugView na vzdálené ploše u zákazníka občas odchytím divnou chybu URB/IRP, která neodpovídá žádným popsaným kódům a vypadá na nějaký overrun/chybný management bufferů a téměř bych čekal, že je to chyba OHCI/UHCI nebo EHCI driveru po update. Takže spíš budeme muset řešit jak u zákazníka zařídit zatím návrat k verzi driverů, která chodí a pak hledat jaké obezličky na straně našeho driveru nebo zařízení pomohou s tímto novým divným chováním Windows žít. Ale upozornění na masivní update USB infrastruktury je dobré vodítko.

Co se týče debuggingu Windows tak za poslední roky zkušenosti nemám. U vlastního KMD a WDM kódu jsme až tak moc pádů neměli a na vše stačil DebugView (tak jak říká Linus, kód se má psát tak, aby debugovat nepotřeboval nebo aby všechno potřebné pro testování vypsal sám).

Jak je to s debuggováním Windows jsem již roky nezkoumal. Naposled, když jsem měl ještě sériový terminál a Window NT 4 na dalším počítači. Ideální by to bylo přes GDB-stub v QEMU. Ale zatím jsem nezkoumal jaké jsou možnosti. Teda krokování a další věci přes GDB půjdou určitě, ale problém bude s debugovacími informacemi z MS kompilátoru. Pro ReactOS to jde. Před lety jsem si někde měl možnost pohrál i se SoftICE, ale to nevím, jestli ještě žije a ať legální nebo nelegální shánění uzavřených nástrojů mě moc neláká a pro vlastní vývoj je nepotřebuji.

Takže toto jsou naše aktuální problémy s Windows a za pomoc bych byl jistě rád. Na Linuxu veškerá naše zařízení byla testovaná týdny v kuse a proti mnoha verzím a počítačům, vše bez potíží, stejně jako nebyly roky potíže u zákazníků s Windows.

Ale všechno toto má minimum společného s tím, že Windows spadnou na své vlastní drivery u zařízení, které nemá možnost do systémové paměti sahat. Ale třeba máte pravdu a v těch updatech je to již opravené. Pokud ale není, tak si stále myslím, že je to informace zajímavá především pro MS.

Backtraky pádu Windows jsme svého času analyzovali, bohužel Win8 v QEMU se sice tváří, že se o uložení dumpu snaží, ale procenta přibývají tak pomalu (odhaduji to na mnoho hodin možná den), že jsem nikdy nevydržel. Možná nějaké nastavení MiniDumpu? Asi to budu muset znova hledat.

Tak zdravím a díky za odkazy i na kolegy, o některých jsem ještě nevěděl, jinak na předmět k Martinu Dětskému jeden můj bývalý student nedávno chodil, ale že se zabývá i Windows jsem nevěděl,

Pavel Píša

Ještě když se dívám na ty Bulletiny, tak cítím marnost nad marnost. Kdyby to bylo na Linuxu, tak tam mám GIT hashe a kouknu se u sebe do GITu, vidím, co se změnilo, jak se tomu přizpůsobily ostatní drivery a nebo třeba i najdu chybu v té změně a mám přímo e-mail člověka, který na dané řádce změnu provedl a kterého mám kontaktovat.

Přestávám vůbec chápat, jak je možné tak kritickou věc jako je jádro OS vyvíjet jiným stylem a pokud bych jako autor měl zájem, aby pro mé jádro někdo jiný drivery vyvíjel, tak mu tento nástroj nedat cítím jako něco zrůdného. Před 20 lety mi to až tak hrozné nepřipadalo, ale teď už je mi mého času a i ostatních mnohem víc líto a vzhledem k ostatním projektům, na kterých pracuji mi začíná připadat to, že nemám přístup k implementaci API nad kterým stavím obludné.

I když ono i v době, kdy jsem uvažoval o portaci našich driverů na Windows 95, jsem četl konferenci o VxD a i přes opravdu vstřícné a velmi dobře reagující přispěvatele přímo z MS mi to připadalo jako skupina nešťastníků (včetně těch z MS) tápajících ve tmě, bažinách a rozpadajícím se kódu.

Zdravím,

ohledně debuggingu Windows: symboly si můžete stáhnout z webu MS. WinDbg (a nejspíš i ostatní debuggery) umí také použít Microsoft Symbol Server, ze kterého si natáhnou potřebnou část a cachují ji lokálně.
http://msdn.microsoft.com/en-us/windows/hardware/gg463028.aspx
http://support.microsoft.com/kb/311503

Pro debugging driverů se také doporučuje použít checked (debug) build Windows. Ten postrádá řadu optimalizací, a naopak přidává spoustu kontrol. Checked build je k dispozici v rámci MSDN.
http://msdn.microsoft.com/en-us/library/windows/hardware/ff543450(v=vs.85).aspx
http://msdn.microsoft.com/en-us/library/windows/hardware/ff549603(v=vs.85).aspx

Minidump si můžete snadno nastavit.
http://support.microsoft.com/kb/315263/en-us#method2

Většina firem nedá veřejnosti přímý kontakt na vývojáře, protože u rozšířenějšího SW by pak už vývojáři nedělali nic jiného, než komunikovali se zákazníky (což je mimochodem úplně jiný typ práce). Proto je mezi zákazníky a vývojáře vložené oddělení podpory, většinou s několika úrovněmi eskalace.

Zdrojáky Windows můžete coby univerzita licencovat v rámci Windows Academic Program. Pokud si vzpomínám, ČVUT bylo součástí tohoto programu. Další možnosti jsou Enterprise Source Licensing Program, OEM Source Licensing Program, MVP Source Licensing Program a Government Security Program.
http://www.microsoft.com/education/facultyconnection/articles/articledetails.aspx

Zkusil jsem vás trochu nasměrovat, snad to pomůže. Víc pro vás v rámci svých kompetencí bohužel udělat nemůžu, takže alespoň přeji mnoho úspěchů.

To je zajímavý námět pro tvůrce procesorů a operačních systémů. Vytvořit nějaký systém oprávnění k přístupu k HW, kde by kernel dokázal vymezit, co který ovladač smí a co nesmí. Zatím to možné není, ovladač buď nesmí nic (neprivilegovaný mód) nebo smí všechno (běží v privilegovaném módu).

Linux to pak ještě běžně řeší tak, že ovladač nesmí nic, ale může volat funkce jiného ovladače, který už smí všechno (včetně shození počítače). Taková metoda rozděl a panuj, kde do "privilegovaného ovladače" dáte funkce pro práci s HW a do "userspace ovladače" teprve dáváte nějakou logiku. U grafických karet to funguje výborně.

Jinak vám ještě závidím veskrze pozitivní zkušenosti s jinými OS. Já to štěstí neměl a s Kernel Panic a mrznoucím PC jen kvůli blbě napsanému ovladači jsem si opakovaně užil i s Linuxem.

No jo, jenže kdo řekne, co ovladač smí a co nesmí? To je u každého zařízení jiné. V důsledku to musí říct driver.
Ve Windows driver nepoužívá přímo přístup k HW; volá I/O Manager. Jenže I/O Manager samozřejmě nemůže vědět, jestli je volání správné.

Rozdělení driverů na kernel-mode part a user-mode part je fajn, ale přináší overhead. Ve výsledku je způsob toho rozdělení tak trochu černá magie, s tím že pro různé scénáře (včetně různých typů zátěže při přístupu na stejné zařízení) mohou vítězit různé modely.

Opravdu by me zajimalo, co je zajimaveho na tom, ze kernel neumozni ovladaci zapisovat do pameti, kterou mu nepridelil. Pak se totiz dost tezko muze stat, ze by prepsal data nebo dokonce kod neceho jineho. Tak nejak bych cekal, ze kernel po svem startu zacne zjistovat co vidi za HW, a podle nejakych pravidel sacuje sadu ovladacu. Kdyz najde, tak ovladac nacte a spusti. Ovladac si potom rekne co potrebuje (namapovat pamet, pridelit preruseni ...) a kernel se podiva, zda muze nebo nemuze splnit jeho prani.

Samozrejme chapu, ze kernel muze dost tezko ovladaci zabranit v tom, aby rekneme dal pokyn svemu HW "a ted zkratuj sbernici". Ale to, ze ovladac prestane komunikovat mi prijde jako zcela stadardni a snadno predvidatelny stav, pricemz neni duvod k tomu, aby se z toho system posr..

Samo, asi tezko chtit, aby zapsal log na disk, kdyz prave disk neni dostupny, ale porad nejak nevidim duvod k modry smrti s vypisem registru.

Seznamte se s konceptem hierarchical protection domains, aka protection rings. Normální aplikace běží v ring 3, aka user mode. Kód v user mode nemá možnost pracovat s I/O, a jednotlivé procesy mají oddělený paměťový prostor. Veškeré operace vyžadující I/O nebo manipulaci s paměti mimo adresní prostor aplikace končí výjimkou. Pokud aplikace chce takové operace provést, musí provést volání kernelu.
Kernel běží v ring 0, aka kernel mode. Kód běžící v kernel mode může provádět I/O operace, přemapovat paměťový prostor, zapisovat do paměti atd.

Kernelové drivery běží v kernel mode. Mají tedy možnost zapsat prakticky kamkoliv a udělat cokoliv. Kernel nemá možnost driveru zabránit například v zápisu do paměti libovolné aplikace.

Kernel navíc netuší, jak se k danému zařízení přistupuje. Každé zařízení má jiný interface, a jenom driver ví, kam se má vlastně zapisovat.

Pokud jde o selhání zápisu na disk, to samo o sobě systém nezboří. Zboří ho například to, že se snaží načíst stránku paměti ze swapu, a disk neodpovídá. V takovém případě totiž nemůže pokračovat v práci žádný program, který tu stránku paměti požaduje ke své funkci (a načtení té stránky ze swapu probíhá zpravidla právě proto, že ji nějaký program potřebuje).

Odborníci jistě odpustí zjednodušení, která v kontextu byla nutná. Vy byste ovšem potřeboval minimálně kurz základů OS.

A placal lael nam tu vysvetluje, jak M$ neumi napsat system, a proto jim to nefunguje. Mimochodem, ve widlich zcela libovolna aplikace muze zapisovat do pameti aplikace jine ... o nejaky ochrane si muzou uzivatele widli nechat leda zdat.

Mimochodem, dik zes potvrdil, ze widle bez swapu fungovat neumi.

...A placal lael nam tu vysvetluje...

+14
:D

Dodatek: teď se omlouvám Laeli, ale prostě ta věta je suprově napsaná (jde tam o tu souhru pismen L). Jde mi fakt jen o tu větu.

Na tuxovi pokud mi skleroza slouzi napr nefungovalo wotko, protoze ve wine nefungovalo ovladani mysi ... kdyz se resilo proc ze to, tak proto, ze wg si proste mys cet naprimo nekde z pameti ... coz je samo prasarna, ale ve widlich to funguje.

Samo, na jejich foru je hromada "reseni" problemu se hrou typu "tak to spustte jako admin, a musite jeste "as administrator" " ... a kupodivu, to mnoha lidem zafungovalo. Osobne taky na widlich pouzivam admin ucet - bez nej se na widlich delat da ... ale jen presne vyjmenovany ukony. Chudak neadmin si ani nezmeni casovou zonu nebo nepripoji tiskarnu.

Ad ve widlich zcela libovolna aplikace muze zapisovat do pameti aplikace jine - nesmysl. Běžte a zkuste si to.

Bezim a zkousim kazdej den ... naprosto vpohode. Jeste nejaka pripominka?

Super. Napíšete k tomu nějaké technické detaily? Vaše "naprosto vpohode" toho moc neřekne.

Vždyť to tady ti lidi píšou :-) Takhle fungují třeba trainery pro hry - modifikují údaje v paměti běžícího procesu:

https://answers.yahoo.com/question/index?qid=20071013004822AAH74YC

Tyhle techniky lze provést pomocí debugovacího interface, případně pomocí code injection. To ale samozřejmě neznamená, že procesy nemají oddělené adresní prostory.

Podobně byste mohl tvrdit, že Linux nemá oddělené adresní prostory, protože můžete použít LD_PRELOAD. A úplně stejně by to byl nesmysl.

Tady nikdo nenaznačoval, že procesy nemají oddělené adresní prostory. To je zase jeden z Vašich pokusů uhnout od tématu?

Myslím, že tato část vlákna už žije vlastním životem a vznikla z citace:
"Údajně je wine na prd ... hráči ve Widlích jsou zvyklí běžet s právy admina a ještě jsou zvyklí na to, že jeden proces zasahuje do paměti procesu jiného. Hezké ne?".

Což by se (asi) dalo shrnou jednou větou. Ano, z toho pohledu je wine "na prd", protože asi neumí (buď vůbec, či spíše ne úplně shodně jako u XP (XP!) /rozložením procesu v paměti/) implementovat OpenProcess a PROCESS_VM_WRITE a podobné meziprocesní aktivity.

To opravdu může být, v určitých případech, problém. Naneštěstí zrovna v takových případech, kvůli kterým část (část!) lidí zůstává na XP a nepřechází na novější systém (a to ani warez).

Pokud bychom to měli komentovat obecně ke článku, nikoli jako odpovědi v rámci vlákna, tak pro tuto sortu lidí není ReactOS či wine adekvátní náhradou. Pro ní prakticky neexistuje žádná náhrada.

Tuším, že XP povolí OpenProcess s PROCESS_VM_WRITE a PROCESS_VM_OPE­RATION /pro zdrojová admin práva/ na cizí procesy. Takže pak asi bude fungovat např. WriteProcessMemory. Nezkoušel jsem, odhaduji.

Ale, je-li používán tento způsob pro trainery (netuším), tak je to IMHO zcela legální postup (pro admin konta, admin práva, na XP). A emulátor by si s tím měl umět poradit.

Ano, to je jeden ze způsobů. Pokud máte SeDebugPrivilege, můžete otevřít jakýkoliv proces, číst a zapisovat jeho paměť, vytvářet nové thready, nastavit mu kvóty atd.

Dá se obdobným způsobem dostat z aplikace i k paměti, kterou si alokoval kernel /driver/, spuštěný v ring 0? To by snad jít nemělo. Ovlivnit by se tím měly dát jen procesy ring 3, spouštím-li OpenProcess z aplikace (ring 3) a ne z kernelu /driveru/. Nebo se mýlím a ring ochrání jen před execute a I/O?

O možnosti číst/zapisovat paměť kernelu tímto způsobem dost pochybují. Ovšem můžete natáhnout driver (který může být poměrně jednoduchý), a ten může použít objekt Device\Physical­Memory. Pokud si pamatuji, ve starších verzích Windows šel ten objekt použít i z user mode.

I pomerne velky blb by moh pochopit, ze driver a predevsim OS by se jaksi pri nalezeni neznameho zarizeni mel zahovat tak, ze nebude delat nic (a v idelanim pripade neco zaloguje) ... a ne ze system sejme.

Zato expert vaší erudice by si mohl všimnout, že zařízení jsou identifikovaná přes hardware ID. Autor původního příspěvku vzal HW nepodporovaný driverem, a vynutil zavedení nesprávného driveru tak, že změnil hardware ID v inf souboru. V druhém případě nastavil HW hardware ID neodpovídající modelu zařízení, takže došlo k zavedení nesprávného driveru.

Než budete psát o blbech, měl byste se vždycky třikrát zamyslet, co vlastně píšete. Jinak to totiž nutně vyvolává jistou asociaci.

To, že kernelový driver při neočekávaném deskriptoru zařízení, shodí celý systém, svědčí o cedníkovitosti driveru a neserioznosti jeho tvůrce (MS) nebo špatné implementaci celého systému.

Jinak rádi zařízení zapůjčíme k otestování, ať si to u MS spraví. Pokud by za to předvedli, jak má nad jejich usbser vypadat inf pro multiport, tak by nás to vysloveně potěšilo. Nemusíte mi psát vy, předejte to podpoře. Vy nejspíš svojí pravou identitu tajíte, když jsem Vám při vašem nepodloženém vychloubání před lety nabízel veřejnou diskuzi, tak jste se stáhl. Můj e-mail na FEL ČVUT najdete opravdu velmi rychle, tak můžete ukázat, že Vaše řeči myslíte vážně a pomoc zásadní bezpečnostní díru Windows opravit.

Za tím, že je driver usbser nepovedený, si stojím. Přitom jeho blokoce na konkrétní VID:PID již úplná zvrácenost. protože od toho, aby nebylo potřeba kvůli standardizovaným zařízením pořád přepisovat drivery a INFy, byly vymyšlené classy (u vzniku standardu USB přímo MS byl, takže by to mohl vědět) a slušné operační systémy raději připraví obecný driver spravovaný v mainline než aby nutily každého výrobce skládat vlastní bastl z milostivě utroušených zbytků.

Na druhou stranu mám velkou úctu Dave Cutlerovi za návrh koncepce NT jádra, i když je vysloveně škoda, že moderní OS nenavrhoval pro někoho jiného, např. IBM nebo DEC, od kterých většinu znalostí stejně načerpal. Ale to, co s tímto bezesporu slušným základem dělá MS, je spíš jen ke škodě. Další problém je, že některé věci, které byly koncepčně v roce 1992 revoluční jsou již dnes poněkud nevýhodné a koncept komunikace ovladačů přes interní, často nedokumentované IOCTL také moc k přehlednosti nevede. Takže mnohem flexibilnější a ze začátku možná i adhoc naimplementovaný soubor přímo volaných funkcí, jako je v jádře Linuxu, nakonec vede k lepšímu modelu a především výkonu. O RCU a dědičnosti priorit a dalších RT vymoženostech Linuxu si pak může nechat Windows jen zdát.

Ten driver se - jak jste psal - pro dané hardware ID nezavádí. Zavádí se jen pokud ho k tomu donutíte, například speciálním .inf souborem. Pokud například pro grafickou kartu nVidia vnutíte driver AMD, tak vás asi nepřekvapí, že zapíše někam kam nemá, a shodí tím systém. Proč vás tedy překvapuje, že usbser.sys nefunguje s HW, pro který není určený?

MS nemá co opravovat. Nejvýš by mohl přidat podporu pro jiná hardware ID, a provést související změny driveru. To je ovšem feature request, nikoliv bug fix.

Driver zjevně není takový problém napsat. Tady máte převodník USB na 4xRS232C, včetně driveru. Ten driver si zvládnul napsat každý výrobce, a také to každý zvládnul. Dost pochybuji, že u toho musel driver zkoušel na ReactOSu, a nedovedl si najít informace v DDK a na MSDN :)
http://www.ftdichip.com/Products/ICs/FT232BM.htm

Je pěkné, že vám můžu poslat email, ale nějak necítím tu potřebu. Když chcete něco napsat mě, můžete sem. A svůj email jsem tuším také v nějaké diskusi psal.

Souhlas, Dave Cutler vymyslel NT velmi pěkně. Kdyby je ale navrhoval pro někoho jiného, zřejmě by se nikdy neprosadily tako jako u MS. IBM je i proti MS naprosto nepružný mamut, který dovede spoustu produktů utopit v byrokracii ještě interně před uvedením, a samozřejmě zabili i produkty po uvedení (včetně PC a OS/2).

Jo, Linux je prostě super. Například prioritizace interruptů funguje tak, že se po dobu obsluhy interruptu zakážou všechna přerušení (local_irq_di­sable). Design s BKL, který se odstraňuje dodnes (recentně rozbitý na subsystem locky) je také skvělý. A latence je tak skvělá, že dodnes uživatelům chrčí zvukové karty. Sice formálně existuje možnost použít CONFIG_PREEMPT, ale ten kód je odporný hack, a je v takovém stavu, že se k tomu ještě žádné mainstreamové distro neodhodlalo (alespoň když jsem se naposledy koukal).

MS jde podle mě správným směrem. Má modulární a portovatelý kernel moderní konstrukce, plus v šuplíku Singularity OS.

Je hezké, jak přesně dokazujete to, o čem jsem povídal. Při povídání o čtyřportovém ACM seriovém portu odkazujete na driver FTDI. FTDI si raději vymysleli zcela vlastní USB protokol, který je zcela mimo ACM a napsali si kompletně vlastní driver, protože MS se k implementaci ACM standardu neměl a když ho přidal, tak stejně se zařízeními chodí jen někdy. Nakonec v některých případech jsme pro Linux a i Windows použili vlastní HW, který FTDI protokol simuluje, protože je to snadnější, než použít standard a drivery od MS. Přitom ten FTDI protokol je, co se USB komunikace týče, pěkný hnus a za dvojkovými huby, při připojení více zařízení, jsme si opravdu užili - teda na Linuxu. Ale řekl bych, že to bylo spíš vlastností dvojkového hubu a FTDI (v tomto případě originálního). Takže kolem a kolem, s MS systémem dodaný ACM driver je vlastně k ničemu.

O BKL se bavit můžeme, ale již pěknou řádku revizí v jádře není. Lokování a latence v Linuxovém síťovém stacku zatím ideální není. Ale vlastní jádro ve fully-preemptive variantě je opravdu úplně někde jinde než Windows. Teď jsme na několika výstavách ukazovali řízení robota přes I/O kartu pouze s PWM, IRC a ADC přímo na registrech a chodí to spolehlivě. Při použití sched FIFO a mlockall (zakázání odswapování řídicího tasku) drží časování dokonale. Pro jiné aplikace toto řešení s kódem generovaným z Matlabu/Simulinku používáme do 20kHz (problém je jen na deskách BIOSem, který aktivuje SMI a s tím se moc udělat ze strany OS nedá). A to se ve všech případech bavím o normálních tascích v user-space. Žádné kernelové programování nebo dokonce soft-PLC executiva napsaná mimo Windows, která ve volném čase přepíná na Windows. Jinak, pokud to MS neopravil, tak dědičnost priorit na běžných Windows nikdy pro mutexy neimplementoval a pouze později přidal nějaké random boostování pro ošetření těch nejkatastrofál­nějších situací. Něco jsem slyšel, že na WinCE to měl nějak trochu lépe. Také vyčítat Linuxu něco okolo priorit IRQ od zastánce systému, který po celou dobu IRP dispatch blokuje kompletně přeplánování (nebo tomu alespoň tak do XP bylo), je úsměvné. Standardní Linuxové jádro zatím neumí pouštět obslužné rutiny přerušení ve vláknech, ale RT varianta to umí, a to již není, co se týče latencí, jen o level lepší než Windows ale rovnou o několik řádů.

Nevím, jak má poslední MS Win naimplementované mutexy. Linux využívá implementaci na bázi futexů, kdy i robustní mutex s priority inheritencí nepotřebuje v bezkolizním případě volat jádro. Opět bych čekal, že je to lépe naiplementované než Windows WaitForSingle/Mul­tipleEvents (Jejich kód jsem si mohl přečíst jen v ReactOSu, ale při dodržení API se nic moc lepšího nenabízí). A tak bych mohl jít dál a dál.

Jinak ty problémy s hlášenými chybami v URB completion máme v úplně jiném, vlastním driveru a to je ten, který jsem testoval na ReactOSu.

Porovnávat driver grafické karty s PnP zařízením, které může přidat každý kolemjdoucí a pro standardní zařízení se systém ani nikoho na nic před instalací ovladače neptá, je poněkud účelové a prozrazuje jakým způsobem se uvažuje v Redmondu o bezpečnosti. Souhlasím s tím, že bez IO MMU nelze systém spolehlivě ochránit proti záměrnému útoku z PCI zařízení nebo proti jeho závažné chybě, ale na PCI je pouze řadič USB, jím připojená zařízení lze ohlídat dobře a proti jejich chybám by systém měl být odolný nebo se o to alespoň trochu snažit.

Krátká otázka: na které verzi Windows měli kolegové problém s těmi zařízeními, které implementují více než jeden COM port? Předpokládám Windows XP?

V FTDI implementovali ten driver už kdysi pro Windows 2000.

Linus projevil svou genialitu mimo jiné tak, že Linux "navrhl" s BKL. K jeho odstranění došlo dvaceti(!) letech, a to tak, že byl rozbit na několik menších locků.

Jádro ve fully-premmptive konfiguraci žádné mainstreamové distro nepoužívá. Podle diskusí autorů dister je tak zabugované, že to nepřipadá v úvahu. Navíc je jeho výkon v běžném použití dost mizerný.
IRP dispatch ve Windows blokuje interrupty s nižší prioritou (alespoň ve Win2K, kde mě zajímalo). Nicméně jde o rychlou akci, a zbytek obsluhy přerušení je preemptivní. Na Linuxu jsou po dobu zpracování přerušení zakázána všechna přerušení, což vede k příšerné latency.

Pokud chcete RTOS, doporučuji Windows s RTX64, nebo Windows CE.

Windows mají hromadu synchronizačních primitiv, a upřímně to není úplně moje hobby. EnterCritical­Section v bezkolizním případě nepropadá na kernel, na rozdíl od WaitForSingle­Object. Pak jsou tu levné atomické operace: InterlockedIn­crement, InterlockedExchange apod., plus interlocked singly linked list (SList). Velmi rychlé jsou Slim Reader/Writer Locks (v .NETu System.Threadin­g.ReaderWriter­LockSlim). Tady najdete novinky implementované ve Vistě, včetně nějakých čísel:
http://msdn.microsoft.com/en-us/magazine/cc163405.aspx

Obecně platí, že když má útočník přístup k vašemu HW, tak to obnáší rizika. Riziko plynoucí z toho, že modifikuje .inf soubor driveru a pak připojí USB zařízení, mi připadá zanedbatelé v porovnání v možností že vytáhne napájení ze sítě nebo rozmlátí stroj kladivem.

Už to tady někdo psal, že kdysi bývaly Vaše artumenty celkem na úrovni. Vy jste ovšem zamrznul v době před 5 lety. Zatímco tady plkátem v diskusích pořád to samé dokola, okolní svět se posunul značně dál. BKL bylo kompletně odstraněno z kernelu 2.6.39 (pokud se nemýlím) a překvapivě pro Vás linux disponuje hard real time MICROkernelem (nikoliv modifikovaným).

Muzete to prosim upresnit s tim RTOS mikrokernelem, mel jsem za to, ze Linux je monoliticky kernel ,ale pak nechapu to vase tvrzeni.Mozna tak l4linux,ale ten je snad porad monoliticky s vlastnostmi l4.Dekuji.

Třeba: http://en.wikipedia.org/wiki/RTLinux

Jestli tomu rozumím dobře, tak:
1. Máte kus HW, ke kterému nemáte ovladač
2. Dospěl jste k názoru, že ovladač jiného zařízení je natolik podobný, že by fungovat mohl
3. Pracnou úpravou .inf souboru jste dokázal zmást OS natolik, aby se pokusil onen ovladač spustit i pro nepodporovaný HW
4. Po připojení daného HW to teď havaruje a shodí systém

Pokud ano, pak nějak nechápu, proč se tomu někdo diví. Ovladač evidentně s daným zařízením nepracuje, ale ani nemá ambice to zkoušet. V základním stavu se tudíž po připojení daného zařízení nic nestane. OS reaguje korektně (zařízení ignoruje), byť nás tím zjevně nepotěší. Teprve ruční zásah do .inf souboru vede k havárii systému. Trochu mi to pak připomíná stížnost typu "Linux je mizerný OS, přepsal jsem pár řádků ve zdrojácích jádra a teď už to ani nenabootuje".

Kritiku "MS Windows nemají pro velkou množinu HW ovladač" ovšem zcela chápu a sdílím.

Ja to chapu jinak ...

1) ma HW, ktery funguje zcela stejne jako jiny obdobny HW, jen je toho integrovano vice v jedne krabce.
2) veme ovladac, ktery vpohode spolupracuje s nekolika samostatnyma krabkama
3) upravi inf proto, ze ma sice zarizeni stejne kategorie, ale M$ se rozhodl v inf vyjmenovat jen konkretni kusy
4) widle se zhrouti, protoze si nedovedou predstavit, ze bude vice zarizeni integrovano a ohlasi se jediny ID.

Mimochodem, na tohle tema sem se bavil pred chvili s kolegou, rikal ze se mu nekde vali USbcko (flashka), ktera widle spolehlive sejme. To jiste potesi, kdyz nekdo dojde do kramu, tak si proste podle vzhledu vybere (protoze podle ceho jineho, ze ...), prijde domu/do firmy/... a vrazenim do konektoru sejme system.

Vaše představy jsou až dětsky naivní. Pokud máte více COM portů visících na jednom USB zařízení, jsou ty porty vedené jako různé funkce toho samého zařízení. Řekněme jako kdybyste měl více klávesnic na jednom USB zařízení. V takovém případě se driver musí pochopitelně chovat jinak, než kdyby mělo zařízení jedinou funkci.

Ad vrazenim do konektoru sejme system - pokud pustíte někoho k HW, přináší to rizika. Já mám doma velký kondenzátor, a když ho v krámu připojím do USB portu pokladny, tak to v ní pěkně zajiskří, a bude vymalováno. Vyjma toho vlastní také velké kladivo. Jo a zapomněl jsem, že umím odstavit počítač tak, že vytáhnu napájení ze zásuvky :). Opakuji: pokud kohokoliv pustíte ke svému HW, přináší to bezpečnostní (a jiná) rizika.

Srovnávat sejmutí systému zastrčením USB klíčenky do USB portu, tedy to, co by každý očekával, že je správně, s kondenzátorem... prostě ROTFL :-D

Přesněji zastrčení USB klíčenky do portu po modifikaci .inf souboru driveru, který donutí driver pracovat se zařízením, na které není stavěný.

Jak jsem psal, pointa je v tom, že když dáte někomu přístup ke svému HW, obnáší to rizika. Můžete se vám to líbit nebo nelíbit, ale to je tak jediné, co s tím můžete dělat.

Nikoli, bavime se tu mimo jine o strceni scela standardni USB klicenky do zcela standardne nainstalenych widli, pocemz se ty widle se 100% uspesnosti slozej.

No vidis lael, ja kdyz vrazim do USB sroubovak ... tak se nestane ... vubec nic ... jake prekvapeni u dle normy fungujiciho USB portu. Tech maximalnich 500mA co tam tecou totiz tak nejak tu desku nemuze vyvest z rovnovahy ... a presne stejne se chova kazde rozumne zarizeni s porty dostupnymi venku.

A podotykam, ze i kdyz stejny sroubovak vrazim do primarniho vystupu zdroje (ktery je vpohode schopen dodat vic nez 30A - cimz se da celkem vpohode svaret, tak se ... voiala ... opet nestane VUBEC NIC ... protoze jaksi vyrobce toho zdroje nebyl debil ...

Ve finale.. usb klicenka je jaksi primarne svou funkci urcena ke strkani do USB portu.

Jen s tím šroubovákem nesmíte otočit, protože pak se něco stane :)

Odpálit USB port přepětím nebo zkratem většinou bohužel není problém. Při troše smůly to odnese i board. Kde jsou ty doby, kde se I/O porty oddělovaly optočleny.

Pokud vás problematika zajímá, koukněte třeba sem:
http://powerelectronics.com/power_management/power_ics/Overcurrent-protection-IC-limits-PET-810.pdf

Protože ten ovladač i HW odpovídají definici USB organizací specifikované třídy zařízení. Takže na pro OS splňující standard - např. Linux, není třeba žádný nový ovladač psát. Zařízení se rozpozná, nenajde se exact match, tak se vezme class ovladač a vše chdodí. Ale na Windows class driver od MS chodí hůře, než když se strefíte do adhoc protokolu a driveru někoho jiného. A ten class je stejně ještě blokovaný jen na několik VID:PID.

Ten driver prostě podporuje určitě hardware ID. Pokud vynutíte jeho používání s jiným HW, je to váš problém.

Co přesně jsi na myšlence "pro OS splňující standard - např. Linux, není třeba žádný nový ovladač psát. Zařízení se rozpozná, nenajde se exact match, tak se vezme class ovladač a vše chdodí." nepochopil? Aha, vono z toho plyne, že to MS dělá blbě. No to je ovšem zcela nepřípustný závěr, že.

Pokud kritizujete to, že by Windows mohly obsahovat driver s širší funkcionalitou, tak samozřejmě souhlas. Pokud kritizujte to, že driver nefunguje s driverem pro který od výrobce není určený, tak nesouhlas.

Co je specielniho na seriovym portu?

V tomto případě to, že je součástí čipu, který je připojený na USB sběrnici, a proto se s ním nezachází jako s UARTem 16550 na klasickém PC.

Zarizeni muze mit zcela libovolny descriptor od vyroby, a vyvojar systemu stim musi pocitat. Stejne tak jako muze mit sitovka libovolnou MAC adresu. Prekvapive kdyz si vyberu ovladac k jine tiskarne nez jakou mam pripojenou, system to prevazne nesejme ... .

Zařízení má hardware ID, které mu nastavil výrobce. Pokud pro zařízení zavedete driver, který je určený pro jiné zařízení, poměrně logicky můžete systém shodit.
Ovladače tiskárny nejsou kernelové drivery.

Pripojuji se k nazoru s ohledne zpraseneho ubsser.sys, zejmena ve Windows 8.1 (update). Soudruzi tam udelali oproti predchozim verzim dalsi (nebo spis jine) chyby pokud jde o USB CDC komunikaci.