Jaderné noviny – 23. 9. 2009

15. 10. 2009 | Jirka Bourek | Jaderné noviny | 3280×

Aktuální verze jádra: 2.6.31. Citáty týdne: Linus Torvalds, Andrew Morton, Stephen Hemminger. AppArmor: Je zpááááátky. Vydán SystemTap 1.0. Devtmpfs a práva. Konec paravirt_ops? Začleňovací okno 2.6.32, část druhá. Nový sloupek: Ptejte se jaderného vývojáře.

Obsah

• Aktuální verze jádra: 2.6.31
• Citáty týdne: Linus Torvalds, Andrew Morton, Stephen Hemminger
• AppArmor: Je zpááááátky
• Vydán SystemTap 1.0
• Devtmpfs a práva
• Konec paravirt_ops?
• Začleňovací okno 2.6.32, část druhá
• Nový sloupek: Ptejte se jaderného vývojáře
  • Proč je jádro 2.6.27 stále udržováno, zatímco novější jádro 2.6.29 již aktualizováno není?
  • Jak zajistím začlenění patche do stabilní aktualizace jádra?

Aktuální verze jádra: 2.6.31

Začleňovací okno 2.6.32 je stále otevřené, v době psaní tohoto článku tedy není žádná vývojová verze jádra 2.6. Vydání 2.6.32-rc1 (a uzavření začleňovacího okna) lze očekávat 24. září.

Současné stabilní jádro je 2.6.31; během minulého týdne nevyšly žádné stabilní aktualizace; je revidována série aktualizací, ale v době psaní tohoto článku ještě nebyla vydána.

Citáty týdne: Linus Torvalds, Andrew Morton, Stephen Hemminger

Upřímně jsem nikdy neviděl důvod mluvit s jádrem pomocí nějakého idiotského paketového rozhraní. Je to jenom nablýskaný způsob, jak dělat ioctl, a každý ví, že ioctl jsou ošklivá a zlá. Proč je nablýskané paketové rozhraní najednou o tolik lepší?

-- Linus Torvalds o netlinku.

Ještě jsem pro tyto výhody neviděl uvěřitelné a kompletní vysvětlení. Několikrát jsem se na tyto věci ptal a nic se nedělo.

Mám podezření, že ve skutečnosti se postupem času stalo to, že dříve fungující kód byl rozbit, čehož si lidé později všimli, ale nepodařilo se jim analyzovat ho a opravit místo toho, aby všechno vytrhli a začali znova.

Takže pro nedostatek analýzy a opravování několika možných regresí jsme vyhodili velmi citlivý vnitřní jaderný kód, který měl za sebou desítky milionů strojových hodin testování. To považuji za neuvěřitelně uspěchané.

-- Andrew Morton o zpětném zápisu podle BDI.

-extern void refrigerator(void);
+extern void refrigerator(void) __cold;

-- Stephen Hemminger o správném mrazení.

AppArmor: Je zpááááátky

Bezpečnostní modul AppArmor měl těžký život – a to i když uvážíme, že bezpečnostní moduly obecně mívají těžkou cestu do hlavní řady. Jeho přístup založený na cestách [pathname] vyvolal obavy u mnoha vývojářů a implementace způsobila, že se ze všech koutů sítě ozývalo NACK. Nakonec hlavní vývojáři přišli o práci, distributoři ztratili zájem a AppArmor se ztratil z dohledu. Mezitím modul TOMOYO Linux překonal překážky a do hlavní řady se dostal.

Při své řeči na LinuxCon autor článku prohlásil, že neví, jestli se AppArmor vrátí, nebo ne. O den později John Johansen zaslal novou sadu patchů AppArmor. Co je zajímavé, John pracuje v Canonicalu, takže AppArmor, pokud se dostane do hlavní řady, by se mohl stát jedním z největších příspěvků této firmy do jádra. Jeho šance na začlenění by nyní měly být lepší; TOMOYO Linux rozbil bariéry pro povinné kontroly přístupu založené na cestách a AppArmor používá nové háčky pro bezpečnostní moduly, které byly přidány pro TOMOYO. V době psaní tohoto článku nicméně nebyla zaslána žádná hodnocení, takže se stále může stát cokoliv.

Vydán SystemTap 1.0

Tým SystemTap oznámil vydání SystemTap 1.0; SystemTap je dynamický sledovací nástroj pro Linux. Autor článku neví, čím si toto konkrétní vydání vysloužilo označení 1.0, ale nových věcí je v něm hodně, včetně experimentální podpory pro neprivilegované uživatele, křížový překlad pro jiné architektury, propojení třídy C++ a rozsahu jmenného prostoru, omezení spotřeby paměti za běhu, omezení režie ve značkách v uživatelském prostoru, opravy chyb a další… Více informací vizte v oznámení.

Devtmpfs a práva

Někteří vývojáři nejsou šťastni z toho, že do 2.6.32 bylo začleněno devtmpfs; jeden dokonce zaslal patch, který ho zase odstraňuje. Ingo Molnár místo toho jednoduše nahlásil chybu: Když devtmpfs vytvořil /dev/null a /dev/zero, znepřístupnil je neprivilegovaným účtům. To rozbíjí většinu aplikací v systému, což podle Inga není zcela žádoucí.

Vývojáři devtmpfs původně zareagovali tím, že v době, kdy by mohla běžet nějaká aplikace v uživatelském prostoru, by měl práva správně nastavit udev, nicméně devtmpfs nabízí možnost se přinejmenším na relativně jednoduchých systémech používání udev vyhnout. Linus souhlasil, že to by byla zajímavá možnost, ale poznamenal, že to nebude fungovat, pokud několik speciálních souborů nebude globálně přístupných. Nastavit práva správně není tak těžké, ale vede to směrem, kterým se vývojáři devtmpfs nechtěli dát: Směrem ke vkládání určitého objemu administrativních politik do jádra.

Nakonec se nicméně stalo přesně to; devtmpfs získal možnost dotázat se jaderných subsystémů na výchozí práva a ta nastavit. Vzhledem k tomu, že práva byla Linusovou největší stížností o celé této věci, zdá se nyní pravděpodobné, že devtmpfs má v jádře 2.6.32 bezpečné místo.

Konec paravirt_ops?

Mechanismus paravirt_ops poskytuje linuxovému jádru možnost efektivně se zaháčkovat do hypervizoru kvůli privilegovaným operacím, když běží ve virtualizovaném režimu. Postupem času se v procesorech objevily vlastnosti zaměřené na podporu virtualizace, nicméně stále bylo možné těžit z implementace některých operací pomocí paravirt_ops. Tato situace se ale, zdá se, mění.

VMI je paravirtualizační vrstva VMWare vytvořená nad paravirt_ops. Vývojáři ve VMWare nedávno zkusili sadu testů a došli k zajímavému závěru: Na současných systémech VMI výkonnost hostitelských systémů nezlepšilo – právě naopak, výkonnost se zhoršila. V blízké budoucnosti by měla být rozumná hardwarová virtualizace dostupná na téměř všech systémech, na kterých záleží, takže se vývojáři VMWare rozhodli, že VMI již nedává smysl; plánuji ji odstranit.

Vývojář KVM Avi Kiviti poznamenal, že v jeho táboře došli ke stejnému závěru; KVM se bude v blízké budoucnosti zbavovat podpory pro některé paravirtualizované operace. To nám ponechává dva další systémy – Xen a lguest – které paravirt_ops používají. Xen, jak se zdá, to tak bude dělat i nadále a lguest s vysokou pravděpodobností nikdy neobětuje dost štěňátek na to, aby mohlo začít hardwarovou virtualizaci používat. paravirt_ops tedy ještě malou chvíli zůstanou, ale jejich eventuální odchod je na obzoru. Až zmizí, dost možná vezmou lguest s sebou.

Začleňovací okno 2.6.32, část druhá

Od článku z minulého týdne bylo do hlavní řady pro vývojový cyklus 2.6.32 začleněno nějakých 3300 sad změn. Celkový počet neslučovacích sad změn mířících do 2.6.32 je nyní těsně přes 7800 – poměrně dost, ale rekord to ještě není.

Mezi změny viditelné pro uživatele patří:

• Nyní jsou k dispozici další dvoje systémové hodiny: CLOCK_REALTIME_COARSE a CLOCK_MONOTONIC_COARSE. Jsou zaměřeny na aplikace, které potřebují získávat časové značky s minimálními náklady a přitom jsou ochotny obětovat rozlišení.

• Nyní je podporována architektura Sunplus S+core.

• Kód pro sledování výkonnosti získal nové schopnosti pro zaznamenávání a analýzu informací o latencích plánovače. Je zde nový nástroj pro sledování událostí změny stavu správy napájení. Také proběhla změna značky, z „čítačů výkonnosti“ se staly „události výkonnosti“.

• Byl začleněn nástroj timechart Arjana van de Vena. Timechart zaznamenává události v systému způsobem, který uživatelům umožňuje přiblížit si specifická období a získat tak čím dál detailnější informace o tom, kde v systému vzniká zpoždění.

• Ovladač grafických karet i915 nyní podporuje dynamické řízení frekvence hodin. Tato vlastnost umožňuje snížit frekvenci hodin, když na grafické kartě probíhá malá nebo žádná aktivita, čímž se sníží spotřeba.

• Kód Radeon pro jaderné nastavování režimu (KMS) se stále vyvíjí rychlým tempem a je v něm podporováno čím dál tím více vlastností. Nyní je KMS podporováno i pro sérii R600.

• Do virtuálních souborů, jako je /proc/meminfo, bylo přidáno mnoho nových informací se záměrem pomoci správcům vysledovat uživatele paměti v situacích, kdy paměť dochází.

• Subsystém jádrem sdílené paměti [kernel shared memory, KSM] byl začleněn. KSM prohledává stránky v paměti a hledá stránky se stejným obsahem. Duplicitní stránky jsou nahrazeny odkazy s kopírováním při zápisu, což vede na významné omezení spotřeby paměti.

• Změny governoru cpuidle popsané v článku Lepší ovládání cpuidle byly začleněny.

• Vrstva Video4Linux nyní zná vysílací standardy ISDB-T a ISDB-S, což zpřístupňuje digitální TV v Japonsku a Brazílii.

• V /proc lze nyní nalézt rozšířené informace o využívání zásobníku vlákny.

• Souborový systém ocfs2 získal podporu pro referenční odkazy [reflink], ale bez systémového volání reflink() (bude přepracováno).

• Ze souborového systému qnx4 byla odstraněna podpora pro zápis; to pravděpodobně bude vadit jenom málo uživatelům, protože stejně nikdy skutečně nefungovala.

• Obvyklá hromádka nových ovladačů:

  • Desky a procesory:

    • procesory pro systém na čipu Broadcom BCM63xx,
    • procesory pro systémy na čipu TI DA830/OMAP-L137 a DA850/OMAP-L138,
    • desky SuperH EcoVec (SH7724) a
    • procesory SuperH SH7757.

  • Grafika:

    • integrovaná grafická čipová sada VIA VX855,
    • framebuffery DA8xx/OMAP-L1xx,
    • LCD řadiče Gumstix Overo,
    • LCD řadiče OMAP3 EVM a
    • framebuffery Qualcomm MSM/QSD.

  • Blokové: 64bitové čtyřkanálové UDMA133 ATA řadiče ARTOP 867X

  • USB:

    • EHCI řadiče Nuvoton W90X900(W90P910) a
    • hostitelský řadič Philips ISP1362

  • Video4Linux:

    • TV karty založené na Conexant 25821,
    • ISDB-T/ISDB-Tsb demodulátory DiBcom DiB8000,
    • USB kamery GL860,
    • TV karty založené na NXP SAA7164,
    • USB2.0 přijímače Friio ISDB-T a
    • PCI karty Earthsoft PT1

  • Různé:

    • teplotní senzory Texas Instruments TMP421/422/423,
    • GPIO zařízení na mnoha procesorech Freescale Coldfire,
    • integrované obvody pro správu napájení Wolfson Microelectronics WM831x,
    • dotykové obrazovky Motorola PCAP,
    • zařízení pro reálný čas ST-Ericsson AB3100,
    • řadič USB periférií Renesas R8A66597,
    • watchdog zařízení série Nuvoton NUC900,
    • infračervené dálkové ovladače Winbond IR,
    • SDCC řadiče Qualcomm MSM 7X00A,
    • rozhraní pro multimediální karty OMAP4,
    • SPI řadiče PPC4xx,
    • SPI/SSP řadiče Freescale STMP37xx/378x,
    • high-side/low-side přepínače Freescale MC33880,
    • hodiny reálného času ST-Ericsson COH 901 331,
    • RTC zařízení Philips PCF2123,
    • RTC zařízení Freescale STMP3xxx a MXC,
    • měřiče výkonu ACPI 4.0 a
    • zařízení pro regulaci napájení TI TPS65023 a TPS6507x.

Mezi změny viditelné pro vývojáře jádra patří:

• Kód architektury x86 byl dostatečně reorganizován, takže bylo možné přidat podporu pro architekturu Intel „Moorestown“.

• Vnitřní API ovladačů bylo rozšířeno, aby se subsystémům umožnilo poskytnout ne-výchozí oprávnění pro uzly zařízení vytvářené v devtmpfs.

• (Nyní) nepoužívaný mechanismus jaderných značek [kernel markers] byl odstraněn; místo nich by se měly používat sledovací body.

• API pro USB ovladač v uživatelském prostoru nyní ovladačům umožňuje zabrat si specifické porty hubu.

• Jsou k dispozici nové sledovací body pro alokace stránek v paměti a jejich uvolňování a události časovače a časovače s vysokým rozlišením.

Začleňovací okno by se obvykle blížilo svému konci; je však možné, že ho Linus trochu rozšíří, aby se nahradil čas, který strávil na LinuxCon a Linux Plumbers conference.

Nový sloupek: Ptejte se jaderného vývojáře

[Poznámka redaktora: Greg Kroah-Hartman ochotně souhlasil, že pro LWN příležitostně napíše sloupek, ve kterém bude zodpovídat otázky, které by čtenáři chtěli položit jaderné vývojové komunitě. Greg odvede skvělou práci, ale klíčem k úspěchu jsou zde dobré otázky; prosím, vymyslete co nejlepší a já je pošlu.]

Ahoj a vítejte u nového polotýdenního sloupku. Zde se budeme snažit zodpovědět vaše časté otázky o vývoji linuxového jádra. Tento sloupek bude spoléhat na čtenáře, že budou zasílat otázky k zodpovězení buď sem v komentářích nebo e-mailem na greg@kroah.com s pochopením, že ne na všechny lze odpovědět.

Platná témata jsou v rozsahu od technických po procedurálních otázky nebo směrem k čemukoliv, co je vzdáleně spojené s linuxovým jádrem a co vás napadne.

Abych začal, poskytl jsem pár „počátečních“ otázek, na které jsem často tázán a rád bych na ně tedy odpověděl najednou, abych to nemusel dělat znovu.

Proč je jádro 2.6.27 stále udržováno, zatímco novější jádro 2.6.29 již aktualizováno není?

Stabilní série linuxového jádra se snaží spravovat jenom jeden jaderný strom naráz, ten nejnovější s malým přesahem jednoho nebo dvou vydání, když vyjde nové jádro. V současnosti, kdy bylo právě vydáno jádro 2.6.31, jsou aktualizovány jak stromy .31, tak .30. Po dalším vydání stromu .30 bude tento opuštěn a aktualizován bude pouze strom .31.

Některé jaderné stromy jsou ale trochu „zvláštní“. Jádro 2.6.27 vypadalo jako dobré jádro pro delší údržbu. Někteří uživatelé nahlásili, že by rádi zůstali u jedné verze jádra déle než 3-4 měsíce, takže jaderný strom 2.6.27 se bude pokoušet být tím stromem, u kterého se lze spolehnout na to, že se do něj budou dostávat bezpečnostní opravy i opravy chyb po delší dobu. Vzhledem k tomu, že bylo jádro 2.6.27 vydáno 9. října 2008, je podporováno již téměř rok.

Až budu unaven údržbou této větve, Adrian Bunk se nabídl, že ji bude udržovat ještě déle, takže během přibližně roku přejde správa na něj a tato verze bude žít dál.

Jak zajistím začlenění patche do stabilní aktualizace jádra?

Nejprve se podívejte na Documentation/stable_kernel_rules.txt a ověřte si, že patch, který zvažujete, splňuje pravidla pro stabilní vydání jádra. Pokud ano, nejjednodušší způsob, jak ho nechat začlenit, je přidat řádek:

Cc: stable <stable@kernel.org>

do oblasti Signed-off-by: patche předtím, než ho pošlete správci subsystému. Když je patch s touto řádkou začleněn do Linusova jaderného stromu, stabilní tým je automaticky upozorněn, že tento patch by měl být začleněn, a oni ho zařadí do fronty k příštímu vydání jádra.

Pokud si všimnete patche, o kterém si myslíte, že by měl patřit do stabilního vydání, ale tuto značku nemá a v Linusově stromě již je, jednoduše napište e-mail na stable@kernel.org a uveďte id commitu patche v Linusově stromě a krátký popis toho, do které stabilní verze jádra by měl podle vás být začleněn. To je vše, co je potřeba.

Tak sem s otázkami!

       

Komentáře

[trekker.dk]

Nedal jsem to přímo do článku, ale pro jistotu: Jaderné noviny jsou překlad, takže pokud byste někdo chtěli posílat dotazy na jaderné vývojáře, pak buď původnímu autorovi nebo na adresu uvedenou v článku Gregovi KH. (Pochopitelně v angličtině)

[Martincek]

Jak to vypadá s tím AppArmor? Chci se naučit nějaké bezpečnostní rozšíření jádra a alternativou je už jen SELinux. A ten je opravdu složitý a jak říkají i někteří odborníci - jeho možnosti nastavení jsou tak jemné, že to jen tak někdo nezvládne. A upgrade každého programu se pak stává bolestnou záležitostí.

AppArmor přitom vypadá úžasně jednoduše a věřím, že i když je založen na cestách k souborům, třeba díry v php by mohl ochránit docela dobře.

Jenže jestli ho vyhodí z jádra, tak je konec. Přitom Ubuntu zvolilo AppArmor jako svoji hlavní bezpečnostní technologii.

Používá to někdo? Má to budoucnost?

[ivan]

Me prijde SELINUX docela nebezpecnej, protoze pouziva extended atributy filesystemu. Chapu, ze je z urcityho pohledu optimalni pristup, ale sprava takovyho systemu muze byt nebezpecna. Nekdy staci tohle(anebo neco podobnyho):

cp /etc/shadow /etc/shadow.bak
..
cp /etc/shadow.bak /etc/shadow

a jste v ... - novy shadow soubor nema spravne extended atributy.

[Dramon]

root si holt musí dávat pozor co dělá. Ale stejným způsobem si každý musí hlídat ACL, pokud se používají. A občas spuštěný restorecon systému také neublíží :)
Pokud by člověk chtěl systém založený na názvu souboru, může se v rámci SELinuxu tento název dát do konfiguračního souboru démona restorecond a on mu to pohlídá.

[asdf]

SELinux zase tak slozity neni. Vypilovat konfiguraci, aby delal vse, co je potreba, muze byt pracne, ale pridani nekolika jednoduchych pravidel je docela snadne. Dobrou dokumentaci je
http://www.root.cz/knihy/ceska-dokumentace-pro-selinux/,
http://www.root.cz/serialy/jak-spravne-na-selinux/

[Karry]

...každý ví, že ioctl jsou ošklivá a zlá...

Já to nevím... Co je na nich tak zlého? Vždyť se používají všude... Co by se místo nich mělo používat?

[cronin]

Co je na nich tak zlého? Vždyť se používají všude.

Prave to je na nich zle - su vsemocnym mechanizmom ako zasahovat do vsetkeho mozneho, a to bez spolocneho dizajnu, zjavnej semantiky a cohokolvek co by sa dalo nazvat navrhnutym rozhranim. Same o sebe povodne vznikli len ako workaround, ktory metastazoval do celeho kernelu.

[Karry]

su vsemocnym mechanizmom ako zasahovat do vsetkeho mozneho

bezesporu...

Koukni na tento kousek:

unsigned long int value;
fd = syscall(SYS_open, devf, O_RDONLY);
ioctl(fd,VIDIOC_G_CTRL,&value);
close(fd);

Je to kus kódu z použití V4L API. Přijde ti tohle špatně navržené? Jak tohle udělat lépe, aby se pokud možno zachovala jednoduchost?

[petr_p]

V mikrojádrech je tento způsob zcela normální, protože prakticky všechny zbytné „služby systému“ jsou formálně zprávy zasílané mezi procesy. V podstatě je to jen otázka curryfikace – jestli je název služby vestavěn do názvu funkce nebo veden jako argument.

[ivan]

Mel by na to byt zvlastni syscall. unixy maji obecne minimum syscallu(narozdil od woken). Chybejici syscally se nahrazuji ioctl. Pro samostnou fukcionalitu aplikace to asi neni problem. Co kdyz prozenete svuj program nejakym analyzatorem a ten vam rekne ze jste stravil 80% casu cekanim na iotl? Jaky z toho udelate zaver? Zrovna to V4L proslo nejakym vyvojem - ioctl umoznuje snadnou zmenu rozhrani ovladace, beze zmeny zbytku kernelu a userspace knihoven. To nemusi byt zrovna vyhodne pro uzivatele.