Microsoft zvažoval přejmenování Internet Exploreru

Bohužel to se u patchů občas stává, nejen u MS. A naštěstí se to projevuje jen pokud nejsou fonty instalované v adresáři Fonts.

Co maj fonty spolecnyho s tim, ze se zhrouti system?

Co má ztuhnutí celého stroje společného s nějakým X11?
https://bugzilla.redhat.com/show_bug.cgi?id=1050437
https://bugzilla.redhat.com/show_bug.cgi?id=1068894

Tyhle chyby nejsou způsobené X11, ale Kernel Mode Setting, tedy přepínáním rozlišení

Vis loliku, pokud se prepina rozliseni, tak je to manipulace s HW, a tam si dovedu predstavit milion a jeden duvod, proc neco vytuhne, kdyz se to udela blbe.

Ale to, ze nekde v konfiguraku fontu je napsana nejaka hovadina, a system kvuli tomu zbuchne ... to se hned tak nekde nevidi.

Ale ona tam ani není napsaná hovadina, po té opravě prostě nezkousne ten hypermoderní křáp žadný OTF font, ke kterému je uvedena celá cesta. U TTF to nevadí. Já nevím, čím o MS soudruzi myslí. Po posledním velkém záplatovacím průseru s OTF, kdy zaplavili podporu Adobe, Corelu, Quarku a dalších mraky uživatelů s "neviditelnými" fonty, by si jeden myslel, že by snad u MS někdo mohl nějaké OTF fonty nainstalovat a testovat. Ale kdepak.

Cože, tohle se ještě projevuje jen u určitých typů fontů? To už je LOL⁴ :-D

Ano. Zlé jazyky šuškají, že BSOD způsobila oprava přidávající symbol ruského rublu :-D :-D :-D

Tak to už je další mocnina LOLu :-)

• že fonty kreslí userspace
• že vadné fonty ignoruje
• že všechny typy fontů budou mít společný kód pro načítání (v MS jsou asi odborníci na copy&paste)
• že nový symbol měny nepotřebuje aktualizaci kódu, ale pouze aktualizaci tabulky Unicode a mapy klávesnice

Pak už se ani nedivím, že microsoftí aktualizace mají gigabajty :-)

- Ve Windows jede velká část GUI v kernelu. Důvodem je výkon. Nakonec si sám můžete zkusit, že je rastrování textu ve Windows výrazně rychlejší než třeba na Linuxu.
- Vadné fonty by se samozřejmě měly ignorovat. Nicméně to není tak triviální, protože TrueType zapisuje fonty jako algoritmy.
- Fonty typu TTF a OTF mají odlišnou strukturu, takže se (nepřekvapivě) načítají jinak.
- Samotný symbol měny potřebuje nové fonty (48 fontů, 32MB). Plus přičtěte aktualizaci rozložení klávesnice, on-screen klávesnice, update abecedního třídění atd.

• A co teprve v DOSu, tam se to vykreslovalo ještě rychleji ;) Měl jsem dojem, že oddělení userspace a kernelspace bylo zavedeno právě z toho důvodu, aby se podobné věci nestávaly. Asi to v Redmondu opět chápou po svém. Navíc v Linuxu rastrování textu není ve skutečnosti nějak pomalejší, protože používá Cairo (hardwarovou akceleraci), pokud je k dispozici.
• Vadný font, který nejde ani načíst, není triviální ignorovat? Co?
• Tak přinejmenším najít a otevřít příslušný soubor jde udělat nějakým obecným algoritmem a parsování provádět až nad streamem, jako to ostatně dělá FreeType. Jde pak dělat takové věci jako on-the-fly načítat font ze ZIPu nebo webu či vygenerovat font v paměti a hlavně nemáte stejný kód rozkopírovaný na mnoho míst, kde se postupem času do něj dostávají chyby, na které při testování nikdo nepřijde, protože v jiných kopiích toho samého kódu to funguje správně.
• To jsou všechno jen data, alespoň na systému, který je rozumně navržen. Ta aktualizace ale zcela zjevně mění i nějaká DLL, SYS a EXE. Což je samozřejmě vždy nebezpečné.

- Nevím na čem to konkrétně havaruje, ale pokud máte i službu Workstation (řekněme linuxový init) závislý na rastrování fontů, protože textová konzole 80x25 už v systému dávno neexistuje, tak půjde systém dolů ať je to umístěné v kernel space nebo user space.
- V tomhle případě zřejmě nejde o vadné ani chybějící fonty. Jde o fonty umístěné mimo adresář fonts. Ale jak jsem psal, obecně je detekce chybného fontu poněkud obtížná, protože jde jsou popsané algoritmicky.
- Layout klávesnice (a řada dalších věcí) je ve Windows v knihovně typu DLL. Má to dobré důvody.

1. Proč by měl být init závislý na rastrování fontů? Třeba u serveru je mi úplně jedno, jestli bude nějaké fonty rastrovat. (Mimochodem co myslíte, že se v Linuxu stane, když inicializace fontu selže? Zůstane to v 80×25.) Navíc opakuji, že jde o chybu načtení jednoho fontu, který se navíc ani nepoužívá, ostatní fonty jsou úplně v pohodě.
2. Ne, jde o font, ke kterému je pouze uvedena absolutní cesta. Klidně může vést do adresáře Fonts, i tak to spadne.
3. Dobré důvody má i spouštění veškerého kódu v privilegovaném režimu. Přesto se to z jiných, mnohem lepších důvodů, nedělá. Stejně tak by layout klávesnice neměl být v kódu. Podívejte se na Xkb nebo MacOS X Installable Keyboard Layouts, jak se to má řešit.

Ad 1 - v procesu bootování se rozjíždí winlogon.exe, který následně přihlášení v GUI. Pokud selže natažení fontu (CreateFont), tak to není větší problém. Ovšem v případě problému s tímhle updatem dojde na PAGE_FAULT_IN_NON­PAGED_AREA, což logicky končí na BSOD.
Ad 3 - layout klávesnice by naopak měl být v DLL souboru. Uživatel layout klávesnice neupravuje, a pokud snad taková výjimečná situace nastane, může si DLL vygenerovat (MS na to tuším má nějaký generátor). Výhodou DLL je to že se verzují a mají digitální podpis. Pokud je potřeba aktualizovat layout klávesnice, prostě nahradíte soubor. Jestliže si uživatel vytvořil vlastní layout, je v separátní DLL, a tu mu při patchování nerozbijete. Podobné je to i v řadě dalších případů.

Mimochodem je hodně absurdní, když systém spadne kvůli inicializaci rastrování fontů a zobrazí BSOD, kde vypíše rastrováním fontů chybovou zprávu. To si spíš už MS jen dělá ze zákazníků srandu.

Drahý Jiříčku, zjevně jste ještě nenapsal tolik řádek kódu, byste si uměl představit, jak může dojít k chybě ve zpracování fontu typu OTF. Až dopíšete alespoň Hello World, přijďte si o tom popovídat.

Ano, k chybě dojít může, ale tohle je už diletantství

Sranda, ze take problemy ma len Microsoft :)

Samozřejmě že to máme nachystané. To je v MS součástí interní dokumentace patchů. Proto se jejich vydání někdy tak vleče :D

Jistě, větší SW bez chyb neexistuje. Ale jako vtipné vidím Internet Explorer jako Ementaller, když v roce 2013 měl Firefox více než dvojnásobek bezpečnostních děr oproti MSIE. V době kdy Firefox používalo jen pár lidí v něm bylo odhaleno méně děr než v MSIE, ale dneska je to úplně jinak. Chrome je na tom podobně mizerně. Komu se tedy máme smát?

Počet bezpečnostních děr za rok 2013:
Mozilla Firefox 270
Google Chrome 245
Microsoft Internet Explorer 126

Zdroj: Secunia Vulnerability Review 2014, figure 21
https://secunia.com/?action=fetch&filename=secunia_vulnerability_review_2014.pdf

Vy ale uvažujete jenom aktuální verzi(ta není úplně nejhorší, osobně mi tam dost vadí hlavně příšerné nástroje pro vývojáře), díky přehmatům MS se ovšem běžně používají verze od IE7+, takže jednak vývojáři musí tak jako tak optimalizovat i pro ně(a to dokáže nasrat) a taky uživatelé to posuzují podle verze, kterou jim MS z politických důvodů dovolí používat oproti konkurenci, kde mají vždycky to nejnovější. Nálepky zmetku už se IE prostě jen tak nezbaví a jedna nezpackaná verze to nenapraví.

Na WinXP (BTW 12 let starém a již nepodporovaném OS) je k dispozici MSIE 8.

Nejde o jednu nezpackanou verzi - za rok 2013 jsou to dvě verze. Navíc problém podle všeho není v tom, že by starší verze MSIE byly tak špatné a nebezpečné. Prostě se na rozdíl od FF hodně používaly, takže byla motivace v nich nacházet díry. Dnes se používá i FF a Chrome, a výsledek je tristní.

Ad nálepky zmetku už se IE prostě jen tak nezbaví - to ukáže čas. Dnes ale nálepku zmetku zjevně zaslouží Firefox a Chrome.

IE8, to je opravdu výhra. Pokud kromě bezpečnosti budeme brát v úvahu i funkčnost, tak jako "nezpackanou" můžu označit opravdu jenom poslední verzi. Vím o čem mluvím, já s těmi prohlížeči musím opravdu pracovat, ne jenom hledat v Bingu argumenty proti linuxu.

Pokud "nezpackanou" verzí myslíte takovou, která se lépe drží doporučení W3C, tak máte pravdu. Nicméně to nic nemění na tom, že dnes nálepku zmetku zjevně zaslouží Firefox a Chrome.

:-)
Prudiči majkrosoftu měli dnes v noci noční šichtu?

A kde je pepa, nevydržel?