11.4.2011 12:28
Nicky726 | skóre: 56
| blog: Nicky726
Rozbalit Rozbalit vše Re: Jaderné noviny – 31. 3. 2011: Boj s fork bombami
Portál AbcLinuxu, 5. května 2025 13:26
Aktuální verze jádra: 2.6.39-rc1. Citáty týdne: Paul McKenney, Constantine Shulyupin, Andrew Morton. Přepracování návěští skoků. Závěr začleňovacího okna 2.6.39. Boj s fork bombami.
Současné vývojové jádro je 2.6.39-rc1, které Linus vydal 29. března. Takže 2.6.39-rc1 je venku a začleňovací okno je uzavřené. Ještě se musím podívat na požadavek na přetažení cleancache (na což jsem měl spoustu času, ale rozhodl jsem se, že to reviduju až poté, co bláznění se začleňovacím oknem skončí). Jinak je hotovo. Mezi významné změny v 2.6.39 budou patřit systémová volání pro otevření podle manipulátoru, CLOCK_BOOTTIME, možnost vynutit běh obsluh přerušení ve vláknech, ipset, základní kód přechodné paměti, subsystém pro řízení multimédií, plánovač toku CHOKe a mnoho dalšího. Detaily najdete v kompletním changelogu.
Stabilní aktualizace: 28. března vyšla stabilní jádra 2.6.32.36, 2.6.33.9, 2.6.37.6 a 2.6.38.2. Každé obsahuje dlouhý seznam důležitých oprav; aktualizace 2.6.37.6 bude poslední pro sérii 2.6.37.
Předtím bylo vydáno 2.6.32.35 obsahující jedinou opravu chyby při překladu.
napsal Jonathan Corbet, 30. března 2011
Mechanismus návěští skoků jsme zde naposledy viděli v říjnu 2010. Ve zkratce umožňuje optimalizovat „vysoce nepravděpodobné“ větvení kódu tak, že běžná režie se blíží nule. Tohoto zrychlení se dosáhne patchováním kódu za běhu; to je také nákladem této metody: povolení nebo zakázání nepravděpodobného případu je drahá operace. Návěští skoků je tedy nejlepší používat pro kód, který není povolen téměř nikdy; zjevnými příklady jsou sledovací body a místa pro dynamické ladění.
Na prvotní implementaci návěští skoků bylo mnoho stížností včetně faktu, že je poměrně složité ho používat. V reakci na to byla zaslána přepracovaná verze, která výrazně mění rozhraní. Začne se deklarováním „klíče skoku“ [jump key]:
#include <linux/jump_label.h> struct jump_label_key my_key;
Povolení a zakázání klíče je jednoduchou záležitostí volání:
jump_label_inc(struct jump_label_key *key); jump_label_dec(struct jump_label_key *key);
A použití klíče pro řízení kódu, který je zapotřebí jenom výjimečně, vypadá následovně:
if (static_branch(&my_key)) {
/* Nepravděpodobný kód zde */
}
Pokud chybí plná podpora pro návěští skoku, je klíč skoku reprezentován hodnotou atomic_t. Z jump_label_inc() se stane atomic_inc() a jump_label_dec() se změní na atomic_dec. static_branch() je implementováno pomocí atomic_read(). Pokud je do jádra zakonfigurována podpora návěští skoků, z povolení a zakázání klíčů skoku se stanou náročnější operace, zatímco static_branch() bude téměř zadarmo. Pro zamýšlená použití návěští skoků je to rozumná výměna.
V době psaní tohoto článku změny do 2.6.39 začleněny nebyly. Je vždy možné, že by mohly být přetaženy do -rc2, ale v tuto chvíli je pravděpodobnější, že nová návěští skoku budou moci skočit až do 2.6.40.
napsal Jonathan Corbet, 30. března 2011
Rozhraní pro správu napájení APM nikdy nebylo příliš milováno – dokonce i ACPI se považuje za lepší alternativu. Za posledních několik let bylo vyrobeno jenom málo hardwaru, který by na APM závisel – pokud vůbec nějaký; Windows evidentně přestaly APM podporovat roku 2006. V Linuxu nicméně funguje dál a to má své náklady, takže není překvapivé, že by Len Brown chtěl tuto podporu v 2.6.40 odstranit.
K tomu nicméně téměř určitě v době, kterou si Len vytýčil, nedojde; mnoho vývojářů namítlo, že se stále může používat hardware, na kterém by nemohla běžet nová jádra, a Linux se obecně snaží neopouštět uživatele starého hardware. APM s námi tedy nejspíše ještě nějaký čas zůstane, ale to představuje problém: udržování podpory APM je, zdá se, v konfliktu s potřebnými změnami v kódu cpuidle. Jinak řečeno snaha udržovat APM funkční může zdržet zlepšení pro většinu uživatelů, kteří mají hardware novější.
Řešením možná bude částečné odstranění podpory APM. Nejvýznamnější vlastností APM je pro uživatele starých strojů nejspíše možnost vypnout systém; ostatní vlastnosti budou méně důležité. Jak poznamenal Andi Kleen, podpora pro nečinnost takovým uživatelům nejspíše tak důležitá nepřijde:
Podpora APM jako taková tedy ještě nějaký čas zůstane, ale s postupem času může začít přicházet o některé vlastnosti.
napsal Jonathan Corbet, 29. března 2011
Od posledního dílu této série bylo do hlavní řady začleněno těsně nad 2 200 neslučovacích sad změn; pro tento vývojový cyklus to celkem dělá 8 757 změn. Začleňovací okno 2.6.39 je nyní zavřené, takže sada vlastností pro tento vývojový cyklus by měla být kompletní. Mezi změny viditelné pro uživatele, které byly začleněny v poslední fázi začleňovacího okna, patří:
Byly začleněny počátky jmenného prostoru pro uživatele. Tento jmenný prostor je určitý druh kontejneru, ve kterém lze procesům bezpečně dát práva superuživatele, aniž by byl schopen ovlivnit zbytek systému. Kompletní podpora kontejnerů je dlouhodobý projekt, ale s těmito patchi je jádro o krok dále.
Dostatečně privilegovaný proces může nyní zapisovat do souboru /proc/pid/mem.
Z I/O CFQ plánovače byla odstraněna volba pro „izolaci skupin“; vzhledem k tomu, že výkonnostní problémy tohoto režimu byly odstraněny, je izolace procesů zapnuta vždy.
Nové blokové zařízení „mtdswap“ umožňuje swapovat přímo na paměťové zařízení [memory technology device].
Mezi změny viditelné pro jaderné vývojáře patří:
V jádře se již nepoužívá typ dma64_addr_t, byl odstraněn.
Framework videobuf v subsystému Video4Linux2 byl nahrazen novější verzí „videobuf2“.
Byl začleněn subsystém pro řízení multimédií, který má systému umožnit exportovat informace o topologii složitých mediálních subsystémů do uživatelského prostoru.
printk() a spol. mají nový specifikátor formátu „%pB“, který vypíše symbol z výpisu volání [backtrace symbol] a jeho offset.
Ve stromě zdrojových kódu jádra byly sloučeny architektury m68k a m68knommu.
Byla přidána podpůrná knihovna pro kódování a dekódování pomocí BCH (Bose-Chaudhuri-Hocquenghem).
Změnila se jména některých nízkoúrovňových funkcí spojených s přerušeními:
| Staré | Nové |
|---|---|
| get_irq_chip() | irq_get_chip() |
| get_irq_chip_data() | irq_get_chip_data() |
| get_irq_msi() | irq_get_msi_desc() |
| irq_data_get_irq_data() | irq_data_get_irq_handler_data() |
| set_irq_chained_handler() | irq_set_chained_handler() |
| set_irq_chip() | irq_set_chip() |
| set_irq_chip_and_handler_name() | irq_set_chip_and_handler_name() |
| set_irq_data() | irq_set_handler_data() |
| set_irq_handler() | irq_set_handler() |
| set_irq_nested_thread() | irq_set_nested_thread() |
| set_irq_noprobe() | irq_set_noprobe() |
| set_irq_type() | irq_set_irq_type() |
| set_irq_wake() | irq_set_irq_wake() |
Prototypy těchto funkcí se jinak nemění.
Jádro 2.6.39 nyní přechází do stabilizační fáze vývojového cyklu. Pokud nedojde k nějakým výjimečnostem, můžeme očekávat, že před vydáním finální verze by mohlo být začleněno nějakých 2 000 oprav a že k samotnému vydání dojde začátkem června.
napsal Jonathan Corbet, 29. března 2011
Unixové systémy bývají dobře opevněné vůči útokům z vnějšku, ale mnohem náchylnější na útoky lokálních uživatelů. Jedno slabší místo se týká „fork bomb“ - procesů, které se šíleně fork()ují, dokud systému nedojdou zdroje. Proti těmto útokům je obtížné se bránit a je obtížné je zastavit bez rebootu; a občas k nim může dojít nešťastnou náhodou. Jestliže vyjde snaha, se kterou přišel Hiroyuki Kamezawa, v budoucnosti bude s fork bombami méně problémů.
Problémem fork bomb je to, že jsou to pohyblivé cíle; v době, kdy si správce systému všimne rapidně se množícího procesu, může již být vytvořeno mnoho potomků a počáteční proces sám o sobě již bude ukončen. Zabíjení procesů jednotlivě není možné; i program napsaný obzvláště k tomuto účelu nemusí stíhat proud nových procesů. Prostě není možné zvládnout celý strom škodících procesů z uživatelského prostoru. Není tedy překvapením, že nejlepším řešením je v této situaci zatáhnout za záchrannou brzdu a začít znovu. I když to – jako v Kamezawaově případě – znamená jít do jiné budovy, kde je postižený stroj umístěn.
Odchytit strom škodlivých procesů může být těžké i z jádra. Stromy procesů jako takové existují jenom do té doby, dokud je naživu předek; jakmile se ukončí, rodičem všech jeho potomků se stane init. Tím se strom zploští a ztíží se tak identifikace procesů, které se na útoku podílejí. Kamezawův patch tedy začíná přidáním nové struktury pro sledování procesů; ta je organizována jako jednoduchý strom odrážející skutečnou strukturu rodiny procesů v systému. Od existujících datových struktur se nicméně liší tím, že „strom historie“ zůstane zachován, i když se některé procesy ukončí. To jádru umožní najít celý strom procesů podílejících se na fork bombě, i když ten, který útok zahájil, již dlouho neexistuje.
Udržovat kompletní historii všech procesů vytvořených za celou dobu běhu linuxového systému by bylo drahé, je zjevné, že přijde chvíle, kdy je nutné historii zahodit. Proto se jádro jednou za čas (ve výchozím nastavení jednou za 30 sekund) pokusí zjistit, jestli neprobíhá útok fork bombou; pokud nic takového neobjeví, zahodí veškerou historii delší než 30 sekund.
Jak jádro přijde na to, že čelí útoku? Fork bomby systém obvykle zastaví tím, že dojde paměť, takže kód hledá známky nedostatku paměti: konkrétně jestli od poslední kontroly docházelo ke zpožděním alokace paměti nebo ke spouštění kswapd. Také sleduje, jestli se v systému nezvýšil počet procesů. Jestliže žádná z těchto kontrol nenajde nic podezřelého, starší historie se zahodí. Pokud jsou alokace paměti obtížnější a počet procesů roste, sledovací struktura se ponechá.
Když fork bomba způsobí vyčerpání paměti, první reakcí jádra bude spuštění zabijáka při nedostatku paměti [OOM killer]. Tomu se postupem času problém podaří překonat, ale faktem je, že OOM zabiják byl vždy navržen tak, aby našel a zabil jeden proces, který dělá problémy. Neumí najít celý strom procesů, které se rychle množí, a zabít je všechny.
Zde do hry vstupuje zabiják fork bomb [fork bomb killer], kterého spustí OOM zabiják. Zabiják fork bomb projde strom historie procesů a do každého uzlu zapíše počet procesů pod ním a celkový objem paměti, kterou tyto procesy využívají. Nakonec se prozkoumá proces s nejvyšším skóre; jestliže je v jeho historii deset procesů nebo více, je považován za fork bombu a on i jeho potomci jsou pozabíjeni. A je uklizeno – snad.
Do /sys/kernel/mm/oom přibývá několik ladících prvků. Historie se sleduje jenom v případě, že je do mm_tracking_enabled zapsáno „enabled“ (což je výchozí nastavení). Hodnota mm_tracking_reset_interval_msecs řídí, jak často se pročistí strom sledující procesy; výchozí hodnota je 30000. Poměrně překvapivě chybí možnost nastavit, kolik potomků musí proces mít, aby byl považován za fork bombu; přednastavená hodnota se zdá být poměrně nízká.
Přijetí tohoto patche nebylo úplně příznivé; komentátoři mají obavy z nákladů na správu sledovací struktury a naznačují, že řešení v uživatelském prostoru by mohlo být lepší. Kamezawa se podle všeho smířil s tím, že patch nemusí být začleněn, a řekl: Chodit o budovu vedle, abych stiskl reset, je dobré pro moje zdraví. Jiní administrátoři, kteří to ke svým strojům nemají tak blízko, nicméně možná budou mít pocit, že jejich zdraví by spíš prospěla větší ochrana proti fork bombám.
Tak zřejmě mám špatně nakonfigurované jádro: Modul se kompiluje, když je nastavený CONFIG_APM, a ten potřebuje CONFIG_PM_SLEEP a ten potřebuje SUSPEND || HIBERNATION || XEN_SAVE_RESTORE. Naivně jsem se domníval, že na vypnutí není CONFIG_SUSPEND potřeba, protože suspendovat stroj nepotřebuji.
Teď ještě jestli to vyřeší i vypínání monitoru. Podle arch/x86/kernel/apm_32.c bude nutné ještě zapnout CONFIG_APM_DISPLAY_BLANK. Vyzkouším.
11.4.2011 12:28
Nicky726 | skóre: 56
| blog: Nicky726
11.4.2011 20:24
josi | skóre: 10
17.4.2011 18:18
josi | skóre: 10
17.4.2011 18:19
josi | skóre: 10
Nevim presne jak je to s transkripci japonstiny, ale u cinstiny se vede uz skoro vecnej spor jestli je pro cechy lepsi zapisovat pomoci oficialni transkripce cinstina -> anglina a nebo pouziva ceskou, ktera je skvela srozumitelnost, ale nikdo mimo nas ji nerozumi.
Jako "kolemjdoucimu" je mi samozrejme prijemnejsi ceskej prepis, ale ten mezinarodni ma svoje vyhody ... tezko rict, tady by se mozna vic uplatnil ten ceskej.
Většina médií ale stejně používá obě transkripce zároveň, někdy dokonce nějaké hybridy a mají v tom obrovský guláš.
Pro ty, kteří to mají daleko, přece existuje xt_SYSRQ xtables modul!
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.