Jaderné noviny - 6. 8. 2008

25. 9. 2008 | Jirka Bourek | Jaderné noviny | 2982×

Aktuální verze jádra: 2.6.27-rc2. Citáty týdne: Linus Torvalds, Ted Ts'o. Poznámky z Ottawa Linux Power Management summitu. Změny v práci s popisovači souborů v 2.6.27. Může být chyba v uživatelském prostoru regrese v jádře? Katalog jaderných zpráv. Krtinec od TALPA.

Obsah

• Aktuální verze jádra: 2.6.27-rc2
• Citáty týdne: Linus Torvalds, Ted Ts'o
• Poznámky z Ottawa Linux Power Management summitu
• Změny v práci s popisovači souborů v 2.6.27
• Může být chyba v uživatelském prostoru regrese v jádře?
• Katalog jaderných zpráv
• Krtinec od TALPA

Aktuální verze jádra: 2.6.27-rc2

Současné vývojové jádro je 2.6.27-rc2 vydané 5. srpna. Je v něm mnoho změn, mnoho z nich jsou opravy nebo reorganizace include souborů (pro architektury specifické include soubory se přesouvají z include/asm-xxx do arch/xxx/include), ale je tam také ovladač pro SGI "GRU" zařízení správy systému, podpora pro architekturu MIPS v obecném kgdb debuggeru, nový subsystém pro správu regulátorů napětí a proudu, změny v zamykání vnitřní správy paměti a VFS, ovladač pro SPI master řadič na Orion čipech a odstranění dlouho zastaralých funkcí cli() a sti(). Detaily najdete ve zkráceném changelogu, spoustu detailů v kompletním changelogu.

V době psaní tohoto článku nebyla od vydání 2.6.27-rc2 začleněna do repozitáře hlavní řady žádná sada změn.

Současný -mm strom je 2.6.27-rc1-mm1. Nedávné změny v -mm se skládají hlavně ze značné redukce velikosti, protože stovky patchů se přesouvají do hlavní řady.

Současné stabilní jádro 2.6 je 2.6.26.2 vydané 6. srpna. Obsahuje rozsáhlou sadu oprav pro širokou škálu problémů. Předchozí jádro 2.6.26.1 (také s rozsáhlou sadou oprav) bylo vydáno 1. srpna.

Pro uživatele 2.6.25: 2.6.25.14 (1. srpna) a 2.6.25.15 (6. srpna) pokračují v řadě oprav tohoto vydání jádra.

Citáty týdne: Linus Torvalds, Ted Ts'o

A teď - věc, kterou by sis odtud měl odnést, je: lidé od jádra mají cool hračky a procesory, které jsou rychlejší, než máš ty.

-- Linus Torvalds

Mám podezření, že část problému spočívá v tom, že lidé od AV dokázali přesvědčit lidi, kteří rozhodují o výpočetní technice, že všechny počítačové systémy potřebují mít antivirový software ze stejného důvodu, proč je potřeba pro systémy s DOSem/Windows. Tento blud se dostal do tak špatného stavu, že někteří AV technici zjevně nechtějí ani diskutovat o principech toho, co je a není nutné k zajištění bezpečnosti systému.

A jestliže je náhodou cílem bezpečnostní divadlo, stejně jako je tomu u bezpečnostních kontrol na letištích, tak na tom snad ani nezáleží. Jestliže je někde hloupý šéf informatiky, který chce za takovou věc platit bez ohledu na to, jestli je to skutečně nutné k udržení bezpečnosti, jedna ze škol kapitalismu říká, že nezáleží na tom, jestli to skutečně poskytuje nějakou funkční hodnotu nebo ne.

Na druhou stranu se zdá být dost jasné, že v LKML je spousta vývojářů, kteří si nic takového nekupují :-).

-- Ted Ts'o

Poznámky z Ottawa Linux Power Management summitu

Linux power management summit v Ottawě proběhl 22. července 2008 - těsně před letošním Linux sympoziem. Pro ty, kteří tam být nemohli, zaslal Len Brown sadu poznámek. Diskuze pokrývala širokou škálu témat, včetně procesoru OMAP3, bootu ze snapshotů, správy napájení USB, správy napájení serverů a dalších.

Celý článek na LWN.

Změny v práci s popisovači souborů v 2.6.27

Jedna ze změn začleněných do 2.6.27 je sada rozšíření systémových volání, která je určena k obejití některých dlouhotrvajících bezpečnostních problémů s POSIX popisovači souborů; V Jaderných novinách jste se o těchto rozšířeních mohli dočíst v květnu. Autor této práce Ulrich Drepper nyní zaslal popis těchto změn, kde vysvětluje, proč jsou důležité a jak se budou používat v C knihovně. Stojí za prohlédnutí obzvláště pro vývojáře, kteří pracují na vícevláknových programech.

Může být chyba v uživatelském prostoru regrese v jádře?

Přidávání nových funkcí do jádra při zachování rozhraní pro uživatelský prostor je standardní způsob vývoje jádra. To ale někdy může způsobit, že se projeví chyba v programu v uživatelském prostoru. Když se tak stane, je to jasně regrese - něco, co předtím fungovalo, teď nefunguje - je to ale regrese v jádře? Zdá se, že v konečném důsledku na tom nezáleží, protože jádro se musí změnit, aby program v uživatelském prostoru fungoval, i za cenu "ošklivosti".

Pro zcela vnitřní funkce jádra není možné vyžadovat kompatibilitu přes různé verze jádra. Když se ale do hry dostane uživatelský prostor, věci se trochu komplikují. Změna, která mění způsob, jakým funguje dokumentované rozhraní, se v podstatě nedělá nikdy; rozhraní pro uživatelský prostor jsou udržována navždy. Když nová funkce správně používá dokumentované rozhraní, ale rozbije program v uživatelském prostoru, je to komplikovanější.

Tato situace se objevila nedávno, když si Andrew Morton všiml, že strom linux-next znefunkčnil X server na jeho laptopu. Problém byl rychle diagnostikován jako závada v X ovladači Synaptic touchpad. Velikost pole, které bylo předáváno ioctl(), mělo velikost udanou v bitech místo v bytech, které mělo obsahovat. Maximální délka předaného bufferu tak byla osmkrát jiná.

Jako řešení Dmitrij Torokov nabídl patch ne pro jaderný kód, ale pro X ovladač synaptics. To Andrewovi a ostatním příliš nesedlo, až nakonec Linus Torvalds vydal prohlášení:

Jestliže má někdo commit, který rozbije uživatelský prostor, tento commit bude vzat zpět, dokud to nebude opraveno. Je to takhle jednoduché. Pravidlem je: vědomě nerozbijeme uživatelský prostor.

Dmitrij měl zjevně pocit, že to byl ovladač a ne jeho změny, co obsahovalo chybu, což je zcela pochopitelné, protože je to pravda. To ale nemění fakt, že nová jádra by znemožnila fungování existujících a fungujících laptopů kdekoliv. Změna v jádře jenom plně využila existující, dokumentované rozhraní, jak Dmitrij objasnil:

Tohle není jako kdybychom tím porušili ABI. Program (ovladač synaptic) obsahuje vážnou chybu. Starší jádra ji zakryly tím, že nepoužívaly celý buffer, o kterém se tvrdilo, že je k dispozici. Teď máme víc informací, které můžeme hlásit, takže nás ta chyba zasáhla.

Deklarovat pole 64bytů a říct přitom jádru, že jich tam může uložit 511, je zjevně chyba. Jak ale zdůraznil Andrew:

Skutečně nezáleží na tom, jaké jsou příčiny, který kus kódu je na vině ani na ničem podobném.

Záleží na tom, že se lidem něco rozbije. A zjevně spoustě lidí. To je problém. Praktický problém. Mohli bychom prosíííííím být praktičtí a najít nějaký způsob, jak tomu zabránit?

Vzhledem k tomu, že kód je v linux-next, je určen pro jádro 2.6.28. Dmitrij si myslí, že to by dalo kolem šesti měsíců na to, aby distribuce aktualizovaly ovladač synaptics. To je ale zásadní nepochopení toho, jak a kdy jsou jádra aktualizována - nedělá se to jenom přes distribuce. Zavedení změny, jako je tahle, by v linux-kernel vyvolalo spoustu zpráv od nešťastných lidí, kterým přestal fungovat X server.

Jaderní vývojáři úmyslně překládají a spouštějí jádra na pestré škále hardwaru a distribucí. To zahrnuje starší distribuce, které již nejsou aktualizovány a zůstávají tak se zachybovaným ovladačem a tím nefunkčním X serverem v podstatě navždy. Zjevně mohou znovu přeložit ovladač synaptics - jaderní hackeři jsou známí tím, že překládají i jiné věci než jádro - ale o to nejde.

Mít běžné uživatele, kteří často aktualizují své jádro, má také velké výhody. Snažit se zajistit, že jim v tom nebude nic bránit, může jenom pomoci. Linus to popisuje takto:

A jestli chceme povzbuzovat lidi, aby svá jádra aktualizovali velmi agresivně (a to jednoznačně chceme!), tak to znamená, že se musíme ujistit, že to nebude znamenat potřebu aktualizovat cokoliv dalšího.

Linus a Dmitrij vypracovali opravu, která zachovává staré chování pro specifickou délku předaného bufferu a umožňuje doručovat nové události všem ostatním uživatelům daného ioctl(), kteří předali správnou délku. Linus to okomentoval: Jo, není to hezké, ale pragmatismus před krásou.

V určitém rozsahu je to šedá oblast. Regrese jsou špatné z mnoha důvodů, ale udržování obezliček pro zachybované programy v uživatelském prostoru má také své nevýhody. Doufá se, že toto řešení problému nebude časem potřeba a bude možné ho odstranit. Je těžké určit, kdy poslední uživatel starého synaptics ovladače upgraduje, takže s námi tento kód bude po dlouhý čas. Vzhledem k alternativě se zdá, že to za to stojí.

I když byl Linus zcela rozhodný, co se týče odsouzení jakékoliv známé regrese dokonce i pro programy, které rozhraní špatně používají, je potřeba někde nakreslit čáru. Jestliže nějaký obskurní program s pár uživateli přestane fungovat, protože jádro dělá něco zdokumentovaného a rozumného, je těžké si představit, že bude potřeba tento druh řešení. U tohoto konkrétního problému bylo relativně snadné rozhodnout, u příštího to tak být nemusí.

Katalog jaderných zpráv

Jaderní vývojáři často používají printk(), aby vypsali zprávu, když se něco pokazí. Tyto zprávy pak bývají užitečné; když nic jiného, mohou být alespoň použity k nalezení místa ve zdrojovém kódu, odkud jsou vypisovány, což je obratem nejužitečnější pro někoho, kdo chce zjistit, co ta zpráva vlastně říká. Takže když vám jádro řekne například "lguest se bojí být hostem", rychlým prohledáním zdrojových kódů najdete komentář, který tvrdí "Lguest nemůže běžet pod Xenem, VMI nebo sebou samým. Dělá Složité věci." Problém vyřešen - nebo alespoň pochopen.

Pro většinu uživatelů a správců Linuxu je ale sama interpretace printk() prohledáváním zdrojových kódů Složitá věc. Jestliže jim jádro nemůže přímo říci, kde je problém, raději by stáli o přímočařejší způsoby, jak zprávy přeložit do nějakého druhu užitečné angličtiny.

A možná ne: pro mnoho uživatelů Linuxu nemusí být angličtina lepší, než přímá mluva jádra. Bylo by skutečně hezké přeložit tyto zprávy do nějakého druhu užitečné francouzštiny, čínštiny atd. Ve zkratce: printk() samo o sobě nikdy nebude schopno poskytnout uživatelům dostatečné informace způsobem, který lze pochopit a použít k řešení problémů.

O něco více než před rokem se Jaderné noviny věnovaly nějakým návrhům, jak přidat jaderným zprávám strukturu. Diskuze poté utichla až do stavu, kdy se zdálo, že v oblasti zpráv se nic neděje. Je potřeba ale nezapomenout na to, že se zde jedná o společnosti jako IBM, které po několik dekád vytvářejí obrovské svazky plné dokumentace. Tyto společnosti se tak snadno nevzdají, proto e-mail (od Martina Schwidefského) o novém návrhu jaderných zpráv není příliš překvapivý.

V nejnovějším schématu každý zdrojový soubor, který generuje strukturované zprávy, definuje makro KMSG_COMPONENT jako řetězec, který pojmenovává specifickou subsekci. Toto jméno bude často souhlasit se jménem modulu, který je tímto kódem generován, ale nemusí to tak být vždy. Očekává se, že jednou vybrané jméno bude pevné navždy; stává se v podstatě součástí rozhraní do uživatelského prostoru a mělo by vždy souhlasit s dokumentací.

Potom je každé zprávě přiřazena identifikační celočíselná hodnota. Kombinace jména komponenty a čísla zprávy by měla být v jádře unikátní; používá se pro různé nástroje, které spojují detailní vysvětlení toho, co má zpráva sdělit. Číslo zprávy se používá v jedné z mnoha nových jako-printk() funkcí:

kmsg_alert(id, format, args...);
kmsg_err(id, format, args...);
kmsg_warn(id, format, args...);
kmsg_info(id, format, args...);
kmsg_notice(id, format, args...);

kmsg_dev_alert(id, dev, format, args...);
/* ... */

_dev verze přebírají dodatečný argument typu struct device (jako dev_printk()) a ve výsledné zprávě dekódují jméno zařízení. Tato zpráva (ve všech variantách) bude v každém výstupu obsahovat jméno komponenty a číslo zprávy. Například ovladač "xpram" pro S/390 zahrnuje následující:

#define KMSG_COMPONENT "xpram"

    /* ... */
    if (devs <= 0 || devs > XPRAM_MAX_DEVS) {
        kmsg_err(1, "%d is not a valid number of XPRAM devices\n", devs);

Kdyby tento konkrétní test na chyby spustil, vypadala by výsledná zpráva nějak takto:

xpram.1: 42 is not a valid number of XPRAM devices

Prozatím náš uživatel asi necítí, že je informován lépe než předtím. Je zde ale dodatečná informace, která je k dispozici a je spojená se značkou zprávy. V tomto konkrétním případě vypadá takto:

/*?
 * Příznak: xpram.1
 * Text: "%d is not a valid number of XPRAM devices"
 * Vážnost: Chyba
 * Parametr:
 *   @1: počet oddílů
 * Popis:
 * Počet XPRAM oddílů specifikovaný v parametru 'devs' předaném modulu
 * nebo v jaderném parametru 'xpram.parts' musí být celé číslo v rozsahu
 * od 1 do 32. Ovladač XPRAM vytvořil maximální počet 32 oddílů, které
 * pravděpodobně nejsou konfigurovány tak, jak bylo zamýšleno.
 * Akce uživatele:
 * Jestliže byl ovladač XPRAM přeložen jako oddělený modul, odstraňte
 * modul a znovu ho nahrajte se správnou hodnotou parametru 'devs'.
 * Jestliže byl ovladač XPRAM vložen do jádra, opravte parametr
 * 'xpram.parts' na řádce jaderných parametrů a restartuje Linux.
 */

Zde máme mnohem bližší popis zprávy. Obsahuje informaci o tom, co je potřeba udělat, aby zpráva zmizela, což pomůže ještě více (doufejme). Tuto informaci lze poskytnout ve zdrojovém kódu nebo v odděleném souboru s dokumentací; také může pravděpodobně být hezky zformátován a svázán platícím zákazníkům, aby se hodil do knihovny administrátora. Lze ho přeložit do jiných jazyků pro uživatele Linuxu po celém světě (i mimo něj: dalo by se dobře pobavit klingonským překladem tohoto druhu textu).

Patch zahrnuje skript (napsaný v Perlu bez dokumentovaných zpráv samozřejmě), který (když je vyvolán příkazem make D=1) projde zdrojový kód a ujistí se, že je každá jaderná zpráva spojená s popisem; také může popisy zformátovat do man stránek, pokud je to požadováno. Umí hledat chybějící popisy nebo přetížená [overloaded] čísla ID zprávy; skript momentálně nehledá změny v textu zprávy.

V první verzi od Martina byla tato práce udělána jako specifická pro architekturu S/390; po návrhu Andrewa Mortona ji Martin v pozdějších verzích zobecnil. Cena za tuto práci je pro ty, kdo ji nepoužívají, nulová, takže je slušná šance, že si nakonec najde cestu do hlavní řady. Předtím, než bude moci být systém katalogu zpráv skutečně užitečný, budou ale vývojáři muset projít a zdokumentovat významnou část zpráv vypisovaných jádrem - a udržovat tuto dokumentaci aktuální s tím, jak se jádro bude vyvíjet.

Krtinec od TALPA

Pozn.: Talpa je druh krtka.

TALPA API pro hledání malwaru bylo na LWN probíráno v prosinci roku 2007. O několik měsíců později je TALPA zpátky - v podobě sady patchů zaslaných zaměstnancem Red Hatu. Následná diskuze určitě nebyla tím, v co vývojáři TALPA doufali; místo toho je to dobrý příklad, jak může být potenciálně užitečný nápad zastaven špatným provedením a předvedením jaderné komunitě.

Myšlenka za TALPA je jednoduchá: různé společnosti v oboru hledání virů by rády háček v jádře, který by jim umožnil hledat malware a bránit jeho šíření. Patch tedy do kódu VFS přidává háček, který zachytí každou operaci otevření souboru. K tomuto zachycení lze přidat sérii filtrů, z nichž nejdůležitější je mechanismus, který zpřístupní otevíraný soubor procesu v uživatelském prostoru jako popisovač souboru pouze pro čtení. Tento proces může soubor prohledat a říct jádru, jestli by operace otevření měla pokračovat, nebo ne. Tímto způsobem může hledající proces zabránit jakémukoliv přístupu k souborům, které jsou odsouzeny za to, že obsahují bity se zlými úmysly.

Samozřejmě je zde pár dalších detailů. Cachovací mechanismus brání opakovanému prohledávání nezměněných souborů, čímž se významně zvyšuje propustnost. Je zde také háček ve volání close(), který může spustit nové prohledání souboru. Procesy se mohou z prohledávání vyjmout, pokud jim vadí; prohledávání lze vypnout pro specifické soubory jako například pro ty, do kterých se ukládají relační databáze. Patch je ale i tak relativně malý, protože toho ve skutečnosti moc nedělá.

Tato schopnost může snadno prokázat svou užitečnost. I když se u linuxových systémů neobáváme napadení malwarem, spousta souborů určených pro zranitelnější platformy může přes linuxové servery procházet. Je zde také potenciál pro detekci pokusů o využití exploitů proti linuxovému hostiteli. V linuxovém světě je běžná reakce na specifickou zranitelnost patch místo testování na exploity, ale mohou být systémy, které nelze rychle restartovat a které by mohly těžit z aktualizované databáze a přitom provozovat kód se známými slabinami. Jak upozornil Alan Cox, tato vlastnost může být použitelná i pro zcela jiné účely, jako je například efektivní indexování souborů, když se mění.

Co může být ze všeho nejlepší, existuje možnost, že by tento háček mohl nahradit spoustu mnohem méně příjemných věcí, které prodejci protimalwarového softwaru dělají teď. Některé z těchto produktů používají binární moduly, vkládají háčky do tabulky systémových volání a obecně se chovají nevítanými způsoby. Přesunout tohle všechno do procesu v uživatelském prostoru za dobře definovaným API by mohlo být prospěšné pro všechny zúčastněné.

Patchům se ale v jaderných konferencích obecně dostalo nepřátelského přijetí. Někteří vývojáři nejsou nadšeni konečným cílem:

Takže ty nás zkoušíš donutit začlenit něco do linuxového jádra kvůli bezpečnostním nedostatkům zcela jiného operačního systému? Nad tímhle argumentem by ses možná měl ještě zamyslet.

Toto je námitka, kterou lze obejít; jaderní vývojáři obvykle nechtějí určovat, které aplikace budou nebo nebudou podporovány systémem jako celkem.

Druhá námitka ale může být obtížnější: o tomto háčku se říká, že není nejlepším řešením problému. Místo vkládání háčku hluboko do vrstvy VFS, by lidé od anti-malwaru mohli vložit háček do C knihovny (například pomocí LD_PRELOAD), vložit hledání malwaru přímo do procesů (řekněme mailových klientů nebo webových serverů), které se starají o průchod souborů systémem, nebo vložit hledání do skládatelného [stackable] souborového systému implementovaného ve FUSE (nebo podobným mechanismem). To vedlo k protiargumentům, že prohledávání implementované tímto způsobem se nepřátelská aplikace může vyhnout například přímým prováděním systémových volání místo volání přes C knihovnu. Říká se, že řešení čistě v uživatelském prostoru mohou některé druhy útoků obejít.

Tento argument nicméně podtrhává skutečný problém s těmito patchi. Patch zahrnuje sadu třinácti "potřeb," mezi které patří zachycení otevření souboru, cachování výsledků, vyjímání procesů atd. Žádná z těchto potřeb ale nepopisuje problém, který je řešen. Konkrétně, jak poznamenal Al Viro a další, není nijak popsáno nebezpečí, proti kterému se tento patch snaží bojovat:

Různí lidé se léta ptají po definici toho, čemu se k čertu snažíte zabránit. Nejenom že se neobjevila žádná koherentní odpověď (a ne, tento seznam potřeb není odpověď - je to seznam "jaké háčky chceme"), ale dokonce se zdá, že nejste schopni se rozhodnout, jestli očekáváte, že daný malware bude pasivní, nebo se bude aktivně snažit zabránit odhalení aktivním procesem na hostiteli, který prohledávání provádí.

Pokud by bylo možné napadnout prohledávajícího hostitele, pak je prohledávající mechanismus, který může být obejit škodlivým programem, skutečný problém. Ale to je velmi odlišné nebezpečí od jednoduché snahy zabránit zlým přílohám vytvářet chaos na stanicích s Windows; a nezdá se, že to by bylo nebezpečí, kterému se tyto patche snaží čelit.

Nedostatečný popis problému způsobil, že diskuze o těchto patchích se opakuje v kruzích; není možno vyhodnotit, (1) jestli cíle těchto patchů stojí za podporu ani (2) jestli patche mohou skutečně uspět ve splnění těchto cílů. Jinými slovy kód nelze revidovat. Dokud vývojáři TALPA tuto situaci nebudou moci vyjasnit, jejich práce bude vypadat jako příklad "nejdřív střílíme a pak se ptáme". Takový druh kódu se do hlavní řady nedostává, i když by mohl být užitečný.

       

Komentáře

[Mandarinka]

Vyvíjet OS s doktrínou, že je imunní proti škodlivému softwaru je hodně špatný přístup. Ten důvod, proč byl patch peo AV software zamítnut mi přijde jako dost složitá konstrukce, takže tipuju, že ho spíš odmítají a priori a tahle námitka je jen pro formu.

[c]

Pokud jsem to dobre pochopil, tak problem neni v tvrzeni "tux je vuci takovym aplikacim imuni", ale spis v tom, ze bud chteji resit malware pro widle a pak jsou hacky do kernelu nesmysl, nebot malware pro widle se na tuxu nespusti = nemuze zadnym zpusobem obejit check v userlandu, nebo chteji resit malware pro tuxe, ale pak by se asi melo jit spis cestou prevence/zamezeni vyskytu takove aplikace, nez prohledavanim vseho co se otevira.

Doposud se pokud vim postupovalo prave tak, ze kdyz se objevil zpusob jak propasovat do systemu nautorizovanou aplikaci ktera bude delat nejake nekale veci, tak je to vyhodnoceno jako dira a resi se to zaplatou. Ne dalsi (jiste take deravou) aplikaci, ktera bude ty nekale veci hledat (coz je naopak klasika pro win prostredi).

Osobne ac win pouzivam, tak zadne takove aplikace nepouzivam (maximalne sem tam neco nainstaluju, abych zjistil ze je vse OK), protoze jediny skutecny virus je uzivatel.

[Mandarinka]

Hmm, mě vadilo spíš, to, že prý "patch nedefinuje hrozby, na které má treagovat etc," což je imho výmluva. Imho.

Jinak přístup k virům mám zhruba stejný... totiž, jak na windows, tak na linuxu. Windows NT podle mě jsou zhruba na stejné úrovni technicky, akorát mají praktickou nevýhodu v tom, že málokdo používá jiný účet než administrátora a přístupová práva se méně vynucují. Ovšem zdá se mi (zase imho), že linuxáři mají představu, že windows jsou úplně jiná liga, a že amjí jakési magické nezacelitelné trhliny, které za ty nákazy můžou, a které linuxu nehrozí. Podle mě naopak je situace linuxu lepší jen o tu disciplínu uživatelů. Iluze týkající se bezpečnsoti se linuxu nemusí vyplatit.

[trekker.dk]

Hmm, mě vadilo spíš, to, že prý "patch nedefinuje hrozby, na které má treagovat etc," což je imho výmluva. Imho.

Není. Někdo konečně sepsal, proti čemu ten patch má bojovat, a vypadá to, že se celá věc pohne kupředu.

[Ondrej 'SanTiago' Zajicek]

Ovšem zdá se mi (zase imho), že linuxáři mají představu, že windows jsou úplně jiná liga, a že amjí jakési magické nezacelitelné trhliny

Ano maji, ale ne Windows jako OS, ale Windows jako cela platforma (OS+programy). A ta nezacelitelna chyba je v tom, ze spousta programu predpoklada, ze bude spoustena pod administratorem a spoustet je pod neprivilegovanym userem je problematicke.

[Hynek (Pichi) Vychodil]

A nebo taky naopak. Tento patch nedokáže vysvětlit proč by měl být právě tam, kde je. Nevysvětluje účel a bezúčelný kód do jádra prostě nepatří. Kód, který se dostane do jádra a propaguje něco do userlandu v jádře zůstane "na věky věků". Dělat něco takového pro bezúčelný kód si prostě lidé zodpovědní za jádro prostě nevezmou na triko, protože prostě jsou zodpovědní. Autoři patche takovou zodpovědnost nenesou a zjevně ani nechápou.

[Mandarinka]

Je to zkrátka háček pro antivir, tak jako že není definován účel? Je, ale někdo řekl, že ne dost. Je to skutečně tak? Nebo by to jinému patchu prošlo. Nic mi po tom vcelku enní, ale přijde mi, že v tom někteří lidé zapojili vášně...

[trekker.dk]

Je to zkrátka háček pro antivir, tak jako že není definován účel?

Není. Máš to tam napsané.

Různí lidé se léta ptají po definici toho, čemu se k čertu snažíte zabránit. Nejenom že se neobjevila žádná koherentní odpověď (a ne, tento seznam potřeb není odpověď - je to seznam "jaké háčky chceme"), ale dokonce se zdá, že nejste schopni se rozhodnout, jestli očekáváte, že daný malware bude pasivní, nebo se bude aktivně snažit zabránit odhalení aktivním procesem na hostiteli, který prohledávání provádí.

To je dost důležitá otázka, bez které lze těžko posoudit, jestli ten patch bude fungovat, jestli bude dělat to, o čem tvrdí, že bude dělat. Nakonec má prý sloužit k detekci pasivního bordelu, čímž se dostáváme zpátky k tomu, že je to zbytečnost, která v jádře není potřeba, ale pokud to půjde vypnout, tak ať to tam klidně je.

[JS]

Me neni zcela jasne, kdyz bude v jadre hacek pro antivir, nemuze ho zneuzit i ten vir? Jak se proti tomu chcete branit? To me spis stavi na stranu, ze je to zbytecne - akorat se ten souboj virus a antivirus presune z uzivatelskeho prostoru do jadra. Nemyslim, ze je to dobry napad.

[petr_p]

Úvaha nad sjednocením Talpy s již zavedeným Dazukem

[aubi]

Zakládám vlákno věnované opravám textu.

A zjevně spoustě lidem. -> spoustě lidí.

Moc děkuju za tenhle seriál, vždycky si bezvadně počtu.