Jaderné noviny - 25. 3. 2009

23. 4. 2009 | Jirka Bourek | Jaderné noviny | 3386×

Aktuální verze jádra: 2.6.29. Citáty týdne: Ingo Molnár, Dan Williams, Ted Ts'o, Tom Christiansen. Návrat utrace. Nftables: nový engine pro filtrování paketů.

Obsah

• Aktuální verze jádra: 2.6.29
• Citáty týdne: Ingo Molnár, Dan Williams, Ted Ts'o, Tom Christiansen
• Návrat utrace
• Nftables: nový engine pro filtrování paketů

Aktuální verze jádra: 2.6.29

Jádro 2.6.29 je venku, Linus ho vydal 23. března. Pro ty, kteří si nás zrovna naladili, významné vlastnosti 2.6.29 zahrnují souborový systém Btrfs (stále ve velmi experimentálním režimu), souborový systém squashfs, jaderné nastavování režimu pro grafické adaptéry Intelu, osobní údaje procesů [credentials], podpora WiMAX, vlastnost zmrazení souborového systému a mnoho dalších; detaily vizte na stránce 2.6.29 na KernelNewbies

V době psaní tohoto článku ještě nezačalo začleňování změn do 2.6.30.

Stabilní aktualizace 2.6.27.21 a 2.6.28.9 byly vydány 23. března. Obě obsahují dlouhý seznam oprav pro chyby v USB subsystému, grafický ovladač i915, device mapper a zvukové subsystémy (a další).

Citáty týdne: Ingo Molnár, Dan Williams, Ted Ts'o, Tom Christiansen

No, já považuji vývoj jádra za jednoduše další formu vývoje softwaru, takže se nehlásím k názoru, že je v jádru jiný. (Ano, jádro má mnoho unikátních aspektů - ale většina softwarových projektů má unikátní aspekty.)

Co se metodologie a nástrojů týče, dokonce tvrdím, že jaderný postup práce a styl vývoje lze s velkým úspěchem aplikovat na většinu softwaru v uživatelském prostoru.

-- Ingo Molnár

Rád bych upozornil na to, že právě kvůli tomu, že NetworkManager obvykle neobchází pitomé ovladače a špatnou infrastrukturu, ale místo toho povzbuzuje vývojáře (včetně mě), aby tuto infrastrukturu a ovladače opravili, jsme v posledních letech urazili vcelku dlouhou cestu co se kvality ovladačů týče.

NetworkManager je jak mrkev, tak klacek, na kterém ta mrkev visí. Kdyby NM prostě obcházel chyby a proprietární ovladače, byla by z toho věž hacků a zkázy a my bychom pravděpodobně ještě trčeli v bezdrátové zemi roku 2006.

-- Dan Williams

Kams dal odvahu, chlape?

Používám [ext4] na svém laptopu od července a ještě jsem neztratil významnější objem dat.

-- Ted Ts'o

Hrát si na Boha fsyncováním svého popisovače souboru je především velmi sobecká věc a za druhé poněkud méně efektivní, než si myslíš, že to je.

-- Tom Christiansen je zpátky

Návrat utrace

Jaderná infrastruktura utrace pro sledování kódu v uživatelském prostoru byla dlouho mezi nevyřízenými věcmi; dodává se v každém jádře Fedory od Fedory Core 6, strávila nějaký čas v -mm stromě, ale nikdy se nedostala do hlavní řady. To se nyní možná mění vzhledem k nedávnému tlaku na začlenění základního kódu utrace. O začlenění utrace nicméně přetrvávají otázky, rozhodně co se 2.6.30 týče, protože ta sada patchů nepřidává žádného jaderného uživatele tohoto rozhraní.

Utrace vyrostl z práce Rolanda McGratha na údržbě systémového volání ptrace(). Toto volání používají z uživatelského prostoru programy, které dělají věci jako sledování systémových volání pomocí strace, ale používá se také méně zjevnými způsoby - například k implementaci Linuxu v uživatelském režimu [user-mode-linux, UML]. I když ptrace() obecně postačuje, je to podle všech měřítek poněkud ošklivé a zachybované rozhraní, které se jaderným vývojářům špatně udržuje a programátorům obtížně používá. Roland popsal zrod utrace v nedávném příspěvku na linux-kernel:

Základní návrh utrace se vylíhl, když jsem nedávno strávil spoustu času opravováním vnitřností ptrace a další spoustu času pomáháním autorům debuggerů v uživatelském prostoru a podobným zjistit, jak s ptrace pracovat (a slyšel jejich stížnosti na něj.) Ve stejnou dobu skupina, ve které (stále) jsem, dumala nad implementačními záležitostmi obecného debuggeru, jak zajistit, aby se vypracoval na úroveň mnohem chytřejších debuggerů, a také nad návrhem toho, z čeho se stal systemtap.

Jednoduše řečeno utrace implementuje framework pro kontrolu úloh v uživatelském prostoru. Poskytuje rozhraní, které mohou využít různé sledovací "enginy" implementované jako nahrávatelné jaderné moduly, které si přejí být upozorněny na údálosti, k nimž dojde u sledovaných vláken. Jak lze očekávat, enginy pro specifické události registrují funkce pro zpětná volání [callback], pak se připojí k jakémukoliv vláknu, které si přejí sledovat.

Zpětná volání se volají z "bezpečných" míst v jádře, která funkcím poskytují velkou svobodu v tom, co mohou dělat. Když se zavolá zpětné volání, nejsou drženy žádné zámky, takže je možné po krátký čas blokovat (ve voláních jako kmalloc()), ale nemělo by to být příliš dlouho - udělat to by znamenalo riskovat, že signál SIGKILL nebude fungovat správně. Jestliže zpětné volání potřebuje provést I/O nebo blokovat kvůli nějaké jiné dlouhotrvající aktivitě, mělo by zastavit vykonávání vlákna, vrátit se a obnovit vlákno, až se operace dokončí.

Pomocí utrace lze sledovat různé události: vstup do systémového volání a jeho opuštění, fork(), posílání signálů úloze atd. Krokování sledované úlohy utrace umožňuje taktéž. Jednou z výhod, kterou utrace poskytuje a ptrace() postrádá, je možnost sledovat jednu úlohu několika sledovacími enginy. Utrace je dobře zdokumentováno v DocBook manuálu, který je přiložen k patchi.

Jaderné noviny se utrace věnovaly před dvěma lety, ale od té doby se ztratilo z očí. Reimplementace ptrace() pomocí utrace je rozhodně jedním z cílů, ale současné patche to nedělají. Je zde však zásadní neshoda mezi Rolandem a ostatními jadernými vývojáři o tom, jestli bez toho utrace může být začleněno. Problém je, že nové rozhraní nemá žádného uživatele ve stromě a, jak to řekl Ted Ts'o, společně s novým jaderným rozhraním potřebujeme uživatele tohoto jaderného rozhraní.

Navržená sada patchů utrace se skládá z malého patche, který pročišťuje část funkcí tracehook, velkého 4000řádkového patche, který implementuje jádro utrace, a dalšího patche, který přidává ftrace sledovač založený na obsluze událostí utrace. Ten poslední, implementovaný vývojářem SystemTapu Frankem Eiglerem, by poskytl jaderného uživatele nového kódu utrace, ale od Inga Molnára obdržel poněkud chladnou reakci: [...] bez pluginu ftrace je celé to soukolí utrace jenom něčím, co poskytuje tunu háčků něčemu, co je kompletně externí: hlavně SystemTapu.

Zde leží jedna z hlavních obav z utrace. Rozhraní utrace-ftrace není považováno za skutečného uživatele utrace, spíš za velký pokus o odvrácení pozornosti, jak to nazval Andrew Morton. Panuje zde obava, že přidání utrace by pouze zjednodušilo udržovat SystemTap mimo hlavní řadu. I když jsou jaderní hackeři značně rezervovaní vůči specifikům implementace SystemTapu, rádi by ho viděli začleněný do hlavní řady. Je zde obava, že začleňování věcí, jako je utrace, by podporovalo SystemTap v tom být mimo hlavní řadu mnohem déle. Ingo zaslal svůj pohled na věc, kde shrnul:

Vložením utrace do upstreamu by jenom bylo pohodlnější mít SystemTap jako oddělenou entitu - bez jakékoliv výhody. To chceme? Možná bychom to mohli být udělat i lépe, řekl bych.

Krom toho Ingo není potěšen tím, že změny v utrace nebyly revidovány vývojáři ftrace a že byly zaslány v době, kdy se má právě otevřít začleňovací okno 2.6.30. Myslí si, že Roland, Frank a další vývojáři utrace by měli spolupracovat s týmem ftrace:

kernel/utrace.c by měl být pravděpodobně představen jako kernel/trace/utrace.c, ne kernel/utrace.c. Také se překrývá se současnou prací ve stromě tracing a spolupráce by zde byla hezká a žádaná.

Plugin ftrace/utrace je jediné skutečné spojení mezi utrace a zbytkem hlavní řady, takže náležitá revize od lidí od sledování a spolupráce s nimi je pro celou věc velmi zapotřebí.

Roland věci vidí poněkud odlišně. Z jeho pohledu je utrace dostatečně užitečné samo o sobě - ne primárně jako část SystemTapu - aby ho bylo možné zvažovat do hlavní řady; v daném vlákně bylo zmíněno několik dalších použití pro utrace: kmview, jaderný modul pro virtualizaci; usondy [uprobes] pro sledování z uživatelského prostoru ve stylu DTrace; změna UML, aby používal přímo utrace místo ptrace(); a další. Frank také obhajuje utrace jako samostatnou vlastnost:

utrace je lepší způsob, jak spravovat uživatelská vlákna, než který je k dispozici nyní, a spojka utrace-ftrace ukazuje, jak zaháčkovat [hook] události vlákna jako syscally lehčím a spravovatelnějším způsobem, než byl ten navržený předtím.

Ingo by byl rád, kdyby před začleněním utrace vznikl patch nazvaný "přepsat ptrace pomocí utrace". Ten by poskytl solidního uživatele v jádře, kterého by jaderní vývojáři mohli použít pro testování a ladění utrace. Roland ale ještě není připraven tento kód zaslat:

Kód utrace-ptrace zatím ještě není příliš hezký na pohled a není připraven na premiéru. Jak bylo zmíněno, je to "čistě cvičení v pročišťování". Jako takové to nemá nejvyšší prioritu. Také se mi to příliš nezdálo jako argument pro začlenění utrace: "Podívejte, víc kódu a teď to dělá úplně to samé!"

Spojení se SystemTapem svým způsobem nespravedlivě ovlivňuje reakci na utrace. Ingo poskytl výborné shrnutí věcí, které mu (a dalším jaderným hackerům) brání používat SystemTap - společně s případnými řešeními - ale utrace a SystemTap nejsou totéž. Možná nedává smysl začlenit utrace bez vážného jaderného uživatele rozhraní, ale většina z ostatních argumentů se týkala SystemTapu, ne utrace. Jak řekl Roland:

Práce na ptrace nám skutečně nekoupí nic, co by se okamžitě vyplatilo. Je opravdu ostuda, že brání lidem skutečně se podívat na samotné utrace. (Tohle zatím byla dlouhá konverzace s nulovou diskuzí o kódu.) Spolupráce se zaměřením na to, jaké nové věci lze vybudovat, místo na důvody, proč nepostavit základy, by byla krásná věc.

Ještě uvidíme, jestli se utrace dostane do 2.6.30, nebo ne. Linus Torvalds nebyl nadšen hlášeními z kerneloops.org, které mu předal Ingo a mezi kterými u Fedory převládalo utrace - i když chyba, která tyto problémy způsobila, je již dlouho opravena. Roland vidí hodnotu v začlenění utrace předtím, než bude hotový přepis ptrace(), ostatní vývojáři ne. Pokud utrace začleňovací okno propásne, zdá se pravděpodobné, že se vrátí do 2.6.31 společně s přepisem; v takové situaci bude začlenění pravděpodobně poměrně rychlé.

Nftables: nový engine pro filtrování paketů

Filtrování paketů a firewalling má v Linuxu dlouhou historii. První mechanismus filtrace nazvaný "ipfwadm" byl vydán roku 1995 pro jádro 1.2.1. Tento kód se používal do vydání stabilního jádra 2.2.0 (leden 1999), kdy nastoupil nový modul "ipchains". I když byl užitečný, vydržel pouze do 2.4.0 (leden 2001), kdy byl nahrazen iptables/netfilter, který v jádře zůstává doteď. Pokud se však správce netfilteru Patrick McHardy bude držet započaté cesty, iptables také v budoucnu zmizí, budou nahrazeny novým mechanismem nazvaným "nftables". Tento článek nabízí přehled o tom, jak nftables fungují, a diskuzi, co tuto změnu motivovalo.

První veřejné vydání nftables přišlo 18. března. Na tomto kódu se nicméně nějakou dobu pracovalo, nápady byly diskutovány na 2008 Netfilter Workshop. Nftables tedy nejsou tak nové, jak by se mohlo zdát.

Do současného kódu (iptables) je zabudováno velké povědomí o protokolech. Je zde například modul zaměřený na získávání čísel portů z UDP paketů, který je odlišný od modulu, který se zabývá TCP pakety. Implementace nftables je zcela jiná; do ní nejsou zabudovány žádné protokoly. Místo toho jsou nftables implementovány jako jednoduchý virtuální stroj, který interpretuje kód nahraný z uživatelského prostoru. Nftables tedy nemají žádnou operaci, která by říkala něco jako "porovnej cílovou IP adresu s 192.168.0.1"; místo toho se vykoná kód, který vypadá nějak takto:

payload load 4 offset network header + 16 => reg 1
compare reg 1 192.168.0.1

(Patrick kód prezentuje v mnemonické formě a autor článku udělá totéž; skutečný kód nahraný do jádra ve skutečnosti používá operační kódy [opcodes].) První řádek nahraje z paketu čtyři byty umístěné 16 bytů za začátkem síťové hlavičky do registru 1. Druhý řádek tento registr porovná s danou síťovou adresou.

Jazyk samozřejmě umí víc než porovnávat adresy. Je zde například vlastnost vyhledávání v množině [set lookup]. Například následující:

payload load 4 offset network header + 16 => reg 1
set lookup reg 1 load result in verdict register
        { "192.168.0.1" : jump chain1,
          "192.168.0.2" : drop,
          "192.168.0.3" : jump chain2 }

Tento kód způsobí, že pakety namířené na 192.168.0.2 budou zahozeny; pro další dvě vyjmenované adresy bude řízení předáno udaným řetězům pravidel. Tato množinová [set] vlastnost umožňuje vícenásobné větvení způsobem, který současná implementace iptables neumožňuje (i když v tomto ohledu pomáhá mechanismus ipset). Kód výše nám také zavádí registr rozhodnutí [verdict register], který si zapamatuje akci provedenou s paketem. V nftables může být na paket uplatněn více než jeden verdikt; je možné přidat ho do specifického čítače, logovat ho a zahodit, to vše v jednom řetězci bez nutnosti testy opakovat (jak je to k vidění u iptables.)

Do virtuálního stroje nftables je zabudováno mnoho dalších možností. Je zde sada operací pro komunikaci s mechanismem sledování spojení, což umožňuje rozhodovat o osudu konkrétního paketu na základě informací o spojení. Další operace řeší různé bity metadat paketu známých síťovému subsystému; ty zahrnují délku, typ protokolu, informace o bezpečnostní značce [security mark] a další. Existují operátory pro logování paketů a zvyšování čítačů. Je zde samozřejmě také kompletní sada operátorů porovnání.

Správci sítě pravděpodobně nebudou příliš nadšeni nápadem programovat nízkoúrovňový virtuální stroj, až budou v budoucnu potřebovat nastavit firewall. Dobrá zpráva je, že je k tomu nebude nic nutit. Místo toho napíší pravidla na vyšší úrovni, která se posléze přeloží na kód virtuálního stroje předtím, než se nahrají do jádra. Tuto práci zajišťuje nástroj nftables, který implementuje čitelný jazyk obalující většinu z potřebných informací o tom, z čeho se skládají pakety. Takže pokud se podíváme na první test uvedený nahoře:

payload load 4 offset network header + 16 => reg 1
compare reg 1 192.168.0.1

Správce by jednoduše napsal ip daddr 192.168.0.1 a nechal nftables změnit to na kód výše. Kompletní (i když jednoduché) pravidlo vypadá nějak takto:

rule add ip filter output ip daddr 192.168.0.1 counter

Toto pravidlo bude počítat pakety zaslané na 192.168.0.1.

Nové API nftables je přirozeně založeno na netlinku. Na rozdíl od současného API iptables má možnost modifikovat jednotlivá pravidla bez potřeby znovu načíst celou konfiguraci. V nftables je také zabudován dekompilační nástroj, který umožňuje znovuvytvoření čitelných pravidel ze současné konfigurace v jádře.

Ve shrnutí to vypadá jako hezky navržený mechanismus pro filtrování paketů, ale začlenění nftables pravděpodobně bude kontroverzní. Mechanismus iptables funguje dobře a je široce využíván; jeho nahrazení kódem, který porušuje API do uživatelského prostoru a rozbije všechny existující konfigurace iptables, zaručeně vyvolá nějaké vrásky. Může se jednat o rušivý a drahý přechod, i když se, jak se zdá nutné, vývojáři zavážou k tomu, že po delší dobu budou v hlavní řadě spravovat jak iptables, tak nftables. Jaderná vývojová komunita bude chtít znát nějaké velmi dobré důvody, proč uživatelům způsobit takovéto problémy.

Jsou zde nějaké dobré důvody, ale mělo by se začít tím, že by mělo být možné vytvořit nástroj, který načte současné konfiguraci iptables a konvertuje ji do jazyka nftables - nebo přímo na kód jaderného virtuálního stroje. Patrick, zdá se, očekává, že Jednoho Krásného Dne takový nástroj vytvoří, ale v současnosti ještě neexistuje.

Některé z důvodů, proč nahradit iptables, byly již naznačeny výše. Postupem času se vědomosti o protokolech zabudované v kódu iptables staly problémem; je zde spousta duplicitního kódu, který dělá stejnou věc (řekněme extrahuje čísla portů) pro různé protokoly. A co je horší, schopnosti a syntaxe mají tendenci se mezi protokoly lišit. Přesunutím všech těchto znalostí do uživatelského prostoru nftables značně zjednodušují jaderný kód a umožňují konzistentnější obsluhu všech protokolů.

Do nového systému je zabudováno mnoho možností optimalizace. Některé drahé operace (například inkrementace čítačů) lze přeskočit, pokud je uživatel opravdu nepotřebuje. Vlastnosti jako vyhledávání v množině a mapování rozsahu mohou celou sadu pravidel pro iptables sloučit do jedné operace nftables. Vzhledem k tomu, že pravidla pro filtrování se nyní překládají, je tu také potenciál k tomu, aby je překladač dále optimalizoval. Tradiční konfigurace firewallu mívají tendence provádět stejné testy opakovaně; chytrý překladač nftables by mohl odstranit mnoho z této duplicitní práce. Není překvapení, že tato optimalizace zůstává na seznamu "dodělat", ale fakt, že všechna tato práce se provádí v uživatelském prostoru, zjednoduší v budoucnosti přidání takovýchto vlastností.

Nástroj nftables bude také schopen provést kontrolu pravidel, která jsou mu předána, na vyšší úrovni a bude schopen poskytnout mnohem užitečnější diagnostiku, než jakou lze dostat od kódu iptables.

Dost možná nejdůležitější motivace je možnost vyhodit současné ABI. ABI iptables se postupem času stává pro vývojáře čím dál tím větší překážkou. Obsahuje pole specifická pro protokol, která je obtížné rozšířit; to je částečně důvod, proč jsou v jádře tři kopie kódu iptables. Když vývojáři chtěli vytvořit arptables a ebtables, museli v podstatě zkopírovat kód a přebušit ho do nového pro protokol specifického tvaru. Patrick odhaduje, že i po čtyřech letech sjednocujících prací je v jádře stále nějakých 10 000 řádek duplicitního filtrovacího kódu. Krom toho jsou struktury používané v ABI také používány přímo v interní jaderné reprezentaci, kvůli čemuž je změna implementace ještě obtížnější. Oddělení by bylo možné přidáním překladové vrstvy, ale detaily v tom zahrnuté (včetně potřeby překládat v obou směrech) zvyšují riziko zanésení choulostivých problémů. Ve shrnutí se ABI iptables stalo vážnou překážkou dalšího rozvoje filtrování paketů.

Nftables představují šanci veškerý tento kód zahodit a nahradit ho mnohem menším filtrovacím jádrem, které by se mělo ukázat jako mnohem flexibilnější. Se štěstím by nftables mohly vydržet dlouhou dobu; virtuální stroj lze rozšířit dnes neočekávanými způsoby bez nutnosti porušit ABI do uživatelského prostoru (zase). Menší velikost je předurčuje k nasazení na malých routerech, bezzámkový návrh by se měl líbit správcům high-end systémů. Existuje slušná šance, že větší komunita bude považovat tuto změnu za užitečnou. Ale ne hned: v nftables jsou nedokončené kousky a ještě nezačala širší diskuze.

(Pro více informací vizte tento weblog ze srpna 2008 a tyto slidy z Patrickovy prezentace [ODF] na Netfilter Workshop.)

       

Komentáře

[Peter H.]

Používám [ext4] na svém laptopu od července a ještě jsem neztratil významnější objem dat.

Aj malý objem dát může byť veľký problém

[cronin]

Ja som to pochopil tak, ze cela ta poznamka bola ironicka. Podla mna chcel tym povedat, ze o nejake udaje [vinou ext4] prisiel a to je velky problem.

[stativ]

Hmm… tak se mi nftables začíná líbit víc a víc.

[Jirka]

Myslenka virtualnich stroju jako v pripade nftables by se mohla uchytit i jinde v jadre.

A nakonec skonci Linux u mikrokernelu .

[Filip Jirsák]

Jenom aby v tom jádře nebylo několik nekompatibilních implementací pro různá použití – jeden pro firewall, druhý pro přístupová práva k souborům, třetí pro oprávnění programů…

[Semo]

Tradiční konfigurace firewallu mívají tendence provádět stejné testy opakovaně; chytrý překladač nftables by mohl odstranit mnoho z této duplicitní práce.

Nie ze by som bol na to extra odbornik, ale to iste sa da predsa dosiahnut definovanim vlastneho novehoh chainu (iptables -N) a presnutim vsetkych akcii do neho, nie?