Zpravodaj o Víně – 4. 9. 2013: Výkonnostní vylepšení Direct3D

5. 9. 2013 | Luboš Doležel | Různé | 19300×

Nové verze Wine. Výkonnostní vylepšení v podpoře D3D. Bezpečnostní problémy a aplikace pro Windows. Změny v databázi aplikací.

Obsah

• Nové verze Wine
• Výkonnostní vylepšení v podpoře D3D
• Bezpečnostní problémy a aplikace pro Windows

Nové verze Wine

Od vydání stabilní verze 1.6 vyšly dvě vývojové verze. První je 1.7.0, která vyšla 2. srpna 2013 s těmito změnami:

• Podpora vertikálního textu v postscriptovém ovladači.
• Používá se liblcms verze 2 místo verze 1.
• Data Unicode aktualizována na Unicode 6.2.0.
• V instalátorech je podporován objekt hyperlinku.
• Lepší podpora pro atributy v XML.
• Různé opravy chyb.

Wine 1.7.1 vyšlo 30. srpna 2013 s těmito změnami:

• Podpora pro zaklíčované objekty událostí [keyed event objects].
• Podpora pro synchronizační mechanismus „init once“ (inicializuj jedinkrát).
• Podpora aktivačních kontextů pro DLL, typové knihovny a třídy COM.
• Podpora pro načítání 32bitových typových knihoven v 64bitovém Wine.
• Různé opravy v ovladači Mac.
• Nějaké opravy pro sériové porty.
• Různé opravy chyb.

Výkonnostní vylepšení v podpoře D3D

Kvalitní podpora Direct3D je pro nemálo uživatelů Linuxu důležitá, protože vývojáři her z různých důvodů místo OpenGL, které funguje téměř všude, dávají stále přednost Direct3D (a později často portování na OpenGL musejí řešit dodatečně). Před skoro dvěma měsíci se objevil Direct3D 9 state tracker pro Gallium, který takto poskytuje Direct3D jako plnohodnotně podporované API, tedy bez emulace přes OpenGL a s vyšším výkonem. Vyžaduje jisté úpravy ve Wine a stav zatím zůstává nejistý, protože tyto úpravy zatím začleněny nebyly. Navíc se mohou z tohoto state trackeru radovat jen ti, kdo používají open source ovladače.

Stefan Dösinger mezitím pracoval na jiných vylepšeních výkonu Direct3D ve Wine, ze kterých se ale mohou radovat všichni, a protože se jedná o jednoho z významných vývojářů Wine, dá se očekávat, že se patch ve Wine brzy objeví:

V uplynulých měsících jsem pracoval na pracovním vlákně / vlákně pro proud povelů [command stream; CS] pro wined3d. Přesouvá většinu volání OpenGL do odděleného vlákna s cílem navýšit výkon (bug 11674) a opravit chyby, které je jinak těžké opravovat (24684).

Přiložené patche můžete otestovat jejich aplikováním (git am cesta/k/patchům/*) a nastavením HKCU/Software/Wine/Direct3D/CSMT = „enabled“. Ujistěte se, že jste zakázali StrictDrawOrdering. S těmito patchi už není potřeba a odstranilo by veškeré výkonnostní výhody. (Může se ale hodit při ladění.) Patche fungují s Wine 1.7.1.

Prosím, ozkoušejte tyto patche na svých hrách. Zajímá mě jakýkoliv úspěch nebo selhání a výkonnostní rozdíly. Uvítal bych čísla s výkonem s obyčejným Wine 1.7.1, tímto patchem s CSMT vypnutým a zapnutým a s Wine 1.7.1 + přílohou bugu #44420 a __GL_THREADED_OPTIMIZATIONS.

Poznámky pro ty, co nejsou vývojáři:

• Hry limitované výkonem GPU nebudou mít vyšší výkon. To, jestli vás GPU limituje, závisí na vašem hardwaru.
• Nezkoušel jsem to zatím na ničem jiném než hardwaru Nvidia. Mělo by to ale fungovat se všemi GPU a ovladači.
• Ano, jde v podstatě o to samé jako __GL_THREADED_OPTIMIZATIONS od Nvidie. Akorát je to nezávislé na ovladači, je to pod naší kontrolou, a proto je snazší opravovat chyby.
• U spousty her zaznamenáte zvýšení výkonu o 50-100 % a nyní běží stejně rychle jako na Windows nebo dokonce rychleji. Příklady budiž hry na Source Enginu, StarCraft 2, 3DMark 2001.
• Call of Duty Modern Warfare 2 se zlepšilo o hodně, protože už nepotřebujete StrictDrawOrdering. Ještě to není tak dobré, jako by to mohlo být, protože hra používá dynamické povrchy [surfaces], které v patchi ještě nejsou řádně implementovány.
• Některé hry mají úzké hrdlo závisející na CPU mimo d3d. Takovou hrou je například Mass Effect 2.
• Některé hry mají úzké hrdlo závisející na CPU v ovladači OpenGL a relativně málo vlastní herní logiky. Myslím si, že to platí pro Civ V, které s těmito patchi není o moc lepší.

Poznámky k implementaci:

• Jedním z velkých návrhových rozhodnutí bylo dělat všechna volání OpenGL z jediného vlákna, včetně vytváření prostředků a map bufferů. Toto je rychlejší než používání glFlush k synchronizaci čehokoliv, co bychom dělali z hlavního vlákna, a je to snazší než vše výkonně synchronizovat pomocí ARB_sync. To znamená, že potřebuji prioritní frontu příkazů. Toto ale ještě není plně implementováno, takže můžete vidět volání GL i z hlavního vlákna.
• Při volání GL ze dvou různých vláken narážím na chyby, i když se jedná o dva různé kontexty.
• Dalším kontroverzním návrhovým rozhodnutím je to, že proud příkazů nedrží žádné reference na objekty uložené v čekajcích příkazech nebo ve vlastních stavových strukturách. To zabraňuje klientským knihovnám a aplikacím v tom, aby „viděli“ CS kvůli opožděné destrukci objektů a uvolňování privátních dat aplikace.
• Aktuálně se s destrukcí čeká, než CS provede všechny čekající příkazy. Cílem je ošetřovat soukromé prostředky a odstraňování ze seznamu prostředků zařízení v hlavním vlákně a uvolňování prostředků GL, resource->heap_memory a hlavní struktury v pracovním vlákně.
• Velkým problémem, co je potřeba vyřešit, je to, že není žádné jasné rozlišení mezi funkcemi, které se volají z hlavního vlákna, a funkcemi, které se volají z vlákna pracovního. Mým plánem je zavést komentáře podobné těm, které vysvětlují, kdo je zodpovědný za aktivaci kontextu.
• Buffery jsou dvojitě bufferované a používají glBufferSubData při používání vícevlákenného CS. Toto je nutné, protože nemůžeme vykreslovat z mapovaného bufferu. V budoucnu by to mělo jít vyřešit pomocí GL_ARB_buffer_storage.
• Smyslem wined3d_device_get_bo a wined3d_device_release_bo je cachovat vytvářené GL BO. Než to udělám, tak budu muset napsat benchmark pro dynamic volumes, abych ověřil, že to skutečně stojí za to.

Stefan dále popisoval, jaké regrese lze očekávat v testech; konkrétně které je nutné vyřešit a které jsou spíš planý poplach. Na mailing listu zatím Stefanova zpráva nevyvolala žádný ohlas – proto stahujte Wine 1.7.1 a testujte!

Bezpečnostní problémy a aplikace pro Windows

Andrew Church se na mailing listu Wine dotazoval, jaký je správný postup pro hlášení bezpečnostních problémů. Dostalo se mu odpovědi, že žádný, ale že může napsat přímo nejvyššímu, tedy Alexandru Julliardovi. Andrew ale nakonec narazil na již známý problém:

[...] Ukázalo se, že je to známý problém (unixfs umožňuje plný přístup k systému souborů přes API Windows, i když není v dosdevices žádný odkaz, co by to umožňoval – nahlášeno jako #22450), takže jsem jen k bugu přidal komentář.

Unixfs, neboli přístup ke kořenovému adresáři v systému, se automaticky objevuje jako jednotka s písmenem Z. Odkazovaný bug spočívá v tom, že unixfs je sice možné zakázat odstraněním klíče z registru, při aktualizaci na novější verzi Wine se ale tento klíč obnoví a Z: se znovu objeví. Zásadní otázkou ale je, čeho chce člověk zakázáním unixfs vlastně dosáhnout. Marcus Meissner:

V závislosti na typu útoku, o který ti jde, nemusí zákaz unixfs stačit.

Pokud chceš spuštěnému malwaru zabránit v přístupu k unixovému filesystému, tak máš smůlu, protože malware by mohl dělat systémová volání na vlastní pěst (int 0x80 na x86, kupříkladu).

Tazatel si je ale toho, že Wine není sandbox, naštěstí dobře vědom:

Jo, toho si jsem vědom – pokud budu spouštět potenciálně zákeřný kód, tak to udělám ve VM . Jde mi spíš o situace, kdy jinak dobře vychovaný program pasivně hlásí vzdálenému serveru to, co vidí, třeba listuje adresáře přes rozhraní shellu – ideálně bych rád omezil to, co vidí, bez režie spojené s během celého VM.

Dále poznamenal, že zákaz unixfs není nikde dobře zdokumentován. Navrhl, aby součástí takové dokumentace bylo upozornění, že zákaz unixfs není nástroj pro obranu proti malwaru.

       

Komentáře

[D.A.Tiger]

Proč má takový obavy z jednotky Z?

Mohu se plést, ale řekl bych, že i pro Windows aplikace pod Wine platí stejná oprávnění jako pro nativní linuxové aplikace. Stejně tak má přístup jen k tomu, k čemu daný uživatel - stejně jako nativní aplikce.

Tedy, dostane-li se mu tam škodlivý kód skrze kompromitovanou aplikaci, v ohrožení je hlavně (a pravděpodobně pouze) domovský adresář daného uživatele, po případně zdroje, které má přidělené. Navíc sice Linux získává na popularitě, ale nevím, jestli crackeři už začínají počítat i s variantou, že jejich "dílo" může být spuštěno i na Linuxu (popř. Macu) a jestli by jim to za to stálo....

[Bedňa]

Asi takto:

Získal moje heslá na FaceBook, G+, do emailu, k účtu, fotografiám mojej milenky, ale nenainštaluje mi tam Tetris!

[D.A.Tiger]

No jo, ale pokud máš na disku fotky svoji milenky, hesla k FB, nebo G+ pak pak bych to všechno hledal v ~ a ne někde pod / kam standardně směřuje jednotka Z.

[Bedňa]

To bolo len tak na okraj, v skutočnosti je ti root na prd, keď si už u nejakého užívateľa máš predsa to čo je naozaj cenné a to je obsah jeho home. Poďalšie dosť často to bude užívateľ ktorý má právo prezerať si účty ostatných užívateľov, načo root, to sa dnes už nenosí.

[Jendа]

a ne někde pod / kam standardně směřuje jednotka Z

No ale přes Z:\home\jenda se dostaneš do ~, ne?

[D.A.Tiger]

To ano. Ale předpokládám, že drtivá většina dalších jednotek (mimo CD-ROM) u většiny uživatelů bude ukazovat někam do ~.

[Max]

Windows je na tom stejně jako linux. Pokud se tedy bere běžné nastavení. Ve windows stejně jako v linuxu má program práva jen tam, kam uživatel. Jenomže takovým programům je to vesměs fuk. Dost často jim nezáleží na ničení dat uživatele, ale spíš pomaloučku, potichoučku monitorovat, odesílat, popř. se zapojovat do botnetů apod. A k tomu všemu stačí jen uživatelská práva (i k automatickému spouštění po startu).
Zdar Max

[D.A.Tiger]

Dost často jim nezáleží na ničení dat uživatele, ale spíš pomaloučku, potichoučku monitorovat, odesílat, popř. se zapojovat do botnetů apod. A k tomu všemu stačí jen uživatelská práva ...

Souhlasím, také si to myslím.

Navíc to klidně může dělat i nativní aplikace - sám jsem používal mírně modifikovaného Linuxového trojana z knihy "Bezpečnost v Linuxu" pro testování některých nastavení - proto mě udivuje, že ho víc trápí relativně "neškodná" jednotka Z, místo toho aby se zaměřil na zabezpečení proti těmto věcem. Případnou podporu antivirů (zmohli by něco pod wine), nebo třeba propojení ClamAV s wine.

Prostě používat aplikace z nedůvěryhodných zdrojů, stahovat a instalovat všechno co na mě kde vyskočí je VŽDY riskantní, bez ohledu na který os je to mířené. To platí pro i wine, nebo klidně i Dosbox ...

[Jendа]

Navíc to klidně může dělat i nativní aplikace - sám jsem používal mírně modifikovaného Linuxového trojana z knihy "Bezpečnost v Linuxu"

Samozřejmě, ale člověk by čekal, že Wine bude po odstranění Z: alespoň trochu sandboxovat… Že to jde obejít přes ruční systémová volání mě nenapadlo - jak se to vlastně dělá?

Případnou podporu antivirů (zmohli by něco pod wine)

Antiviry nefungují a ani nemůžou fungovat, by-design.

[Luboš Doležel (Doli)]

Že to jde obejít přes ruční systémová volání mě nenapadlo - jak se to vlastně dělá?

Hello world v assembleru

[Ondrej 'SanTiago' Zajicek]

Dost často jim nezáleží na ničení dat uživatele, ale spíš pomaloučku, potichoučku monitorovat, odesílat, popř. se zapojovat do botnetů apod

Jenze s uzivatelskymi pravy jsou takove programy trivialne odhalitelne, zatimco s rootovskymi maji moznosti se takrka dokonale maskovat.

[Jendа]

trivialne

Jak kdy. Třeba když ti to patchne extension ve Firefoxu a zabydlí se to v ní, tak se to bude hledat dost blbě.

A i toho roota může získat brzo a snadno - aliasem na su/sudo.

[Jendа]

v ohrožení je hlavně (a pravděpodobně pouze) domovský adresář daného uživatele

Jinými slovy to nejdůležitější, co na běžném osobním/jednouživatelském desktopu je.