24.6.2008 06:46
ashen
| blog: wheeeeeee
Rozbalit Rozbalit vše Re: Jaderné noviny - 30. 4. 2008
Portál AbcLinuxu, 5. května 2025 19:19
Aktuální verze jádra: 2.6.25.1. Citáty týdne:. Začleňovací okno 2.6.26, část druhá. Omezení roota pomocí bezpečnostních bitů pro každý proces. Ksplice: jaderné patche bez rebootu.
Začleňovací okno pro 2.6.26 zůstává otevřené, takže stále nebylo vydáno žádné vývojové jádro 2.6. Shrnutí patchů začleněných v tomto týdnu najdete v článku níže.
Během minulého týdne nebyly vydány žádné stabilní verze. V době psaní tohoto článku jsou revidovány aktualizace stabilních jader 2.6.24.6 a 2.6.25.1; jestliže všechno půjde dobře, budou tyto aktualizace vydány 1. května.
Ti, kdo sledují konferenci linux-kernel, ví, že začleňovací okno 2.6.26 bylo poněkud drsnější, než ta dřívější. To vedlo k trochu ostřejší diskuzi o tom, jak se do hlavní řady dostávají změny. Tady je pár vybraných kousků.
Neříkám, že ten patch je špatný... nebo že by se neměl udělat jenom proto, že rozbil voyager. Říkám, že neměl být vložen do stromu x86 bez revizí v konferenci.
Gitový strom neznamená samovládu; jde o všeobecnou důvěru a aby sis tu důvěru udržel, musíš strom provozovat transparentním způsobem... a jediný způsob, jak tohle zajistit, je udělat z mailové konference jediný vstup pro patche. Také to pomáhá s revizemi, u kterých všichni cítíme, že se jich dělá málo.
Ale na druhou stranu nám určitě nebude vadit poslat každé tři měsíce (nebo častěji) do lkml (nebo jinam) 1000 x86.git patchů, pokud si to lidé budou přát.
-- Ingo Molnár
Můžeš do lkml posílat každý patch, který chceš, třeba milionkrát. To není problém. Problém je to, že ty patche nebudou revidovány a poslat je víckrát nebo jinam nepomůže.
-- David Miller
Urovnávání kódu architektury x86 určitě způsobí, že se rozbije pár vajec, nicméně mám podezření, že víc času stál zápas Dave vs. Ingo (12 kol, dva pády, dvě rezignace nebo knockout) než opravování spadu několika problémových případů.
-- Alan Cox
Takže tady je návod, jak vyřešit Davidův problém:
Všichni dostanou své věci do linux-next
Spousta lidí bude testovat linux-next. Jednou týdně.
Tyto dva kroky pomohou zlepšit chaos začleňovacího okna. Věci se zlepší.
IMO je začleňovací okno příliš krátké na to, aby se v něm skutečně dalo něco otestovat. Překládám jádro jednou nebo i dvakrát za den a není způsob, jak bych ho mohl skutečně otestovat. Můžu jenom zjistit, když hned nefunguje. A když je to tak, není čas na to zjistit, co ho rozbilo předtím, než do něj přistane dalších pár set commitů.
A ano, je tu řešení: nevyvíjejte tolik. Nedovolte tisícům vývojářům zapojit se. Vytvořte malou skupinu a zařiďte, aby vývoj byl tak těžký a nepohodlný, abyste měli jenom několik desítek lidí, kteří píší kód. Proklepněte si je a nuťte je skákat skrz obruče, když chtějí přidávat nové vlastnosti (a nebo, když jsme u toho, opravovat ty staré).
Od shrnutí, které bylo sepsáno minulý týden, si svou cestu do repozitáře hlavní řady jádra našlo dalších 3700 sad změn. Nejvýznamnější změny viditelné pro uživatele zahrnují:
Byly začleněny nové ovladače pro
Nyní je přítomna základní podpora pro braillské řádky.
Podpora pro architekturu One Laptop Per Child XO byla začleněna do hlavní řady.
Nové virtuální soubory v /proc/pid/mountinfo poskytují informace o všech připojených souborových systémech viditelných příslušným procesem.
Nový virtuální soubor /proc/vmallocinfo zobrazuje informace o využití vmalloc prostoru uvnitř jádra.
Architektura SPARC Niagara má nyní podporu pro NUMA.
Byl začleněn balónový ovladač Xen (který umožňuje přidávat nebo odebírat paměť virtuálním hostům.)
Ve výchozím stavu nyní nelze použít /dev/mem k přístupu do RAM; Fedora a Red Hat měly tento patch aplikovaný roky, ale nyní si našel cestu i do hlavní řady.
Paravirtualizační subsystém KVM nyní podporuje architektury S/390, PowerPC 440 a ia64.
Jsou podporovány "bezpečnostní bity" [securebits] pro každý proces. Tyto bity řídí, jakým způsobem jsou spravovány kvalifikační bity [capability bits]; tento patch má za cíl pomoci těm, kteří chtějí přejít na systém plně založený na kvalifikacích. Detailnější popis této vlastnosti najdete v tomto článku.
Systémové volání getrusage() má nyní novou volbu RUSAGE_THREAD, která způsobí, že funkce vrátí informace pouze o aktuálním vlákně.
Patch kontrolní skupiny whitelistu zařízení [device whitelist control group] (krátce popsaný v tomto článku) byl začleněn.
Nyní je možné vytvářet a používat oddíly na síťových blokových zařízeních [network block device].
Subsystém auditu nyní může události testovat proti souboru, se kterým se pracuje.
VFS nyní zpřístupňuje pomocné informace o zařízení v /sys/class/bdi. Lidé, kteří mají zájem, se tam mohou podívat na proměnné ovládající dopředné čtení [readahead] a zpětný zápis [writeback] pro každé zařízení.
Souborový systém FUSE nyní podporuje vytváření a sdílení zapisovatelné mapované paměti.
Změny viditelné pro vývojáře jádra zahrnují:
Funkce ioremap() na architektuře x86 nyní vždy vrátí necachované mapování. Předtím používala volnější přístup a cachování ponechala tak, jak ho nastavil BIOS. Praktickým výsledkem bylo, že téměř vždy vytvořila necachované mapování s příležitostnými výjimkami. Ovladače závislé na cachovaném mapování se rozbijí; budou muset místo této funkce použít ioremap_cache().
API Video4Linux2 nyní definuje sadu ovládacích prvků pro kamery; umožňují uživatelskému prostoru pracovat s parametry, jako je typ expozice, naklánění a otáčení, ostření a dalšími.
U x86 je nyní nový konfigurační parametr, který gcc umožňuje se samostatně rozhodnout o inlinování funkcí, i když jsou tyto funkce deklarované jako inline. V některých případech může tato volba redukovat velikost kódového segmentu jádra o více než 2 %.
Stará IDE vrstva prošla mnoha interními změnami, které rozbijí všechny zbývající IDE ovladače.
Operace nopage() na oblasti virtuální paměti byla odstraněna; všechen kód v jádře místo ní nyní používá fault().
SLUB alokátor nyní podporuje nový soubor v sysfs (/sys/kernel/slab/name/order), který umožňuje správci systému změnit velikost alokace stránky používané jmenovaným slabem.
Stav, který způsobí varování s WARN_ON, nyní také poskvrní [taint] jádro.
Rozhraní get_info() pro /proc soubory bylo odstraněno. Také je nová funkce pro vytváření těchto souborů:
struct proc_dir_entry *proc_create_data(const char *name, mode_t mode,
struct proc_dir_entry *parent,
const struct file_operations *proc_fops,
void *data);
Tato verze přidává ukazatel data a zajišťuje, že bude nastaven ve výsledné struktuře proc_dir_entry předtím, než se uživatelský prostor může pokusit k ní přistoupit.
byla začleněna infrastruktura pro ladění objektů.
Začleňovací okno zůstává otevřené; nalaďte si nás příští týden a dozvíte se o posledních (měly by být) sadách změn začleněných do 2.6.26.
Linuxové kvalifikace měly jako součást jádra dlouhou a poněkud mučivou cestu. Do této bezpečnostní vlastnosti jsou pomalu - a velmi opatrně - přidávány funkce, aby se z ní stala použitelná alternativa k všechno-nebo-nic setuid(0) modelu. Nedávno začleněný patch přidává vlastnost bezpečnostní bity pro každý proces [per-process securebits], což na kvalifikacích založeným démonům a subsystémům umožní koexistovat s existujícími setuid() utilitami.
Linuxové kvalifikace rozdělují privilegované úkoly obvykle spojené s rootem (tedy uid 0) na jemněji dělené možnosti, které mohou být jednotlivě povolovány nebo zakazovány pro specifické procesy. Cílem je změnit standardní unixový model, kde root má všechna zvláštní oprávnění, kdežto všichni ostatní uživatelé nemají žádná. Tato terminologie je nicméně vždy poněkud sporná, protože linuxové kvalifikace jsou odvozeny od POSIX návrhu, který nebyl nikdy přijat, ale sdílí jméno "kvalifikace" se zcela jiným přístupem; tento článek se zabývá pouze linuxovou verzí kvalifikací.
Dlouho je zájem na vytvoření linuxového systému, který by nezávisel na jediném účtu root. Kvalifikace jsou považovány za způsob, jakým toho dosáhnout, ale trpěly problémem typu vejce-slepice. Díky nedávné práci, která přidala kvalifikace založené na souborech a obnovila CAP_SETPCAP do jeho původního významu, je nyní pravý na kvalifikacích založený systém možný. V patchi, který byl začleněn do 2.6.26, Andrew Morgan popisuje novou funkci:
Vlastnost přidaná tímto patchem může fungovat jako páka a potlačit privilegia spojená s (set)uid-0. Toto potlačení začne tak, že se proces spustí s CAP_SETPCAP - platí to pouze pro 'aktuální' proces (je děděno přes fork()/exec()). Tato reimplementace se významně liší od historické podpory pro bezpečnostní bity, která byla celosystémová, těžkopádná a která postupně seschla na mrtvou relikvii ve zdrojovém kódu moderního jádra.
Patch odstraňuje globální proměnnou bezpečnostních bitů a nahrazuje ji záznamem v struct task_struct, se kterým mohou proces a potomci manipulovat (ale jenom se svým). Morgan si představuje hybridní systémy, které budou obsahovat některé utility používající k získání svých práv kvalifikace společně s nějakými setuid(0) utilitami. V tomto případě si na kvalifikacích založený démon nebo utilita mohou přát omezit, co jejich potomci mohou dělat, dokonce i když spustí setuid(0) binárku. Jako součást této evoluce mohou být vytvořeny stromy procesů, které nemohou získat oprávnění superuživatele.
Procesy, které mají kvalifikaci CAP_SETPCAP, mohou změnit nastavení svých bezpečnostních bitů systémovým voláním prctl(). Interakci kvalifikací a setuid řídí tři různé bity:
SECURE_NOROOT - povolení tohoto bitu nedává uid 0 žádná speciální privilegiaSECURE_NO_SETUID_FIXUP - nastavení tohoto bitu zakazuje opravy kvalifikací, když se přechází z nebo do uid 0 pomocí setuid. To se může udělat z důvodu kompatibility se staršími programy, které používají setuid k omezení vlastních práv.SECURE_KEEP_CAPS - když je nastaven, proces může obnovit své kvalifikace, i když se změní na proces běžící pod běžným (ne uid 0) uživatelem. Tento bit je vynulován voláním exec().Každý z těchto bitů má také doprovodný *_LOCKED bit, který, pokud je nastaven, neumožní jakémukoliv uživatelskému programu změnit odpovídající nastavení. Jak Morgan v patchi poznamenává, program, který může nastavovat své kvalifikace (má CAP_SETPCAP), může sebe i potomky zbavit všech privilegií voláním:
prctl(PR_SET_SECUREBITS, 0x2f);
To je ekvivalentní nastavení SECURE_NOROOT, SECURE_NO_ROOT_LOCKED, SECURE_NO_SETUID_FIXUP, SECURE_NO_SETUID_FIXUP_LOCKED a SECURE_KEEP_CAPS_LOCKED.
Vzpomínka na chybu v kvalifikacích sendmail z roku 2000 způsobuje neklid mezi některými vývojáři - nebo hůř - pokud jde o patche, které zahrnují kvalifikace a setuid. Andrew Morton se ptá: Cože to bylo za chybu, kvůli které jsme zmrzačili dědění kvalifikací ve dnech minulých? (Nějaká věc se sendmailem?) Příčinou této chyby bylo to, že neprivilegovaní uživatelé mohli odstranit kvalifikaci CAP_SETUID ze setuid programů jako sendmail. Poté, když posléze sendmail použil setuid, aby se zbavil svých práv, selhal, ale nedělal žádné ověření, takže běžel dál s plnými právy. To se uživatelem dalo zneužít a získat oprávnění superuživatele. Bylo to odloučení kvalifikací a dlouho fungujícího chování unixových systémů, pokud jde o zbavování se práv.
Morgan reagoval na Mortonovy otázky sepsáním detailního popisu chyby kvalifikací v sendmailu. Zdůrazňuje, že se chce k plné podpoře kvalifikací dostat bez rozbití existujícího kódu:
V základě mám zájem na implementaci kvalifikací podle modelu POSIX.1e a jejím ucelení - ale naprosto jasně bez ochromení staré podpory superuživatele během tohoto procesu.
Až si lidé na tento plně kvalifikovaný model zvyknou, věřím, že budeme moci z jádra vyházet víc odpadu, nicméně i toto pročištění ponechá na místě plně funkční starý [legacy] model. Cítím to tak, že by sloužil pro něco, jako je init nebo některé z jeho potomků, aby byly schopny spouštět subsystémy ve starém nebo pouze kvalifikovaném režimu.
Vypadalo to, že Andrew Mortona uklidnila, když byly jeho připomínky vzaty v potaz, ale stejně se dále zajímá o budoucnost kvalifikací: A jak se tedy dostaneme do stavu, kdy budeme moci distributorům doporučit, aby tyhle věci zapnuli, a jak je přimějeme, aby s námi souhlasili? To opakoval Ismail Dönmez, který hledal konkrétní příklady, jak tyto bezpečnostní bity použít. Morgan poskytl odkaz na několik příkladů společně se svým tvrzením, že věří, že někdy brzy budou vývojáři kvalifikací dostatečně přesvědčeni o tom, že je možné vypnout příznak "experimental" u jaderné volby SECURITY_FILE_CAPABILITIES. Tento příznak řídí jak na souborech založené kvalifikace, tak bezpečnostní bity pro každý proces. K tomu Morgan řekl:
Co je důležitější, doufám, že v té době budeme mít nasbírán dostatek dokumentace, zkušeností z uživatelského prostoru a příkladů, abychom přesvědčili ostatní, že toto je opravdu životaschopná vlastnost, kterou lze podporovat v mainstreamových distribucích.
Jako dobré reference pro danou práci byly ve vlákně zmíněny článek o kvalifikacích založených na souborech na developerWorks od Serge Hallyna a webová stránka o POSIX kvalifikacích od Chrise Friedhoffa, které popisují skutečné použití kvalifikací v systému. Tyto články jsou starší než současná práce na bezpečnostních bitech, takže Dönmez hledal příklad použití nové vlastnosti. Morgan odpověděl, že jedním z nich jsou kontejnery a předal slovo Hallynovi, který měl několik nápadů, jak bezpečnostní bity využít:
Máme tendence mluvit o 'systémových kontejnerech' versus 'aplikačních kontejnerech'. Systémový kontejner by byl jako instance vserveru nebo openvz - něco, co vypadá jako stroj sám o sobě. Chtěl jsem říct, že si neumím představit, jak by se tady hodily bezpečnostní bity pro každý proces, ale ve skutečnosti, vzhledem k tomu, že systémový kontejner nepotřebuje nijak nastavovat hardware, by mohlo být mnohem jednodušší nastartovat plné SECURE_NOROOT distro než skutečný stroj. Vždyť na skutečném stroji může init a několik starých [legacy] démonů běžet ve jmenném prostoru initu, kdežto uživatelé se mohou přihlašovat a Apache běžet v SECURE_NOROOT kontejneru.
Nicméně mně se obzvláště líbí myšlenka třeba Postfixu, který běží v pečlivě vypracovaném aplikačním kontejneru (s vlastní virtuální síťovou kartou, omezenou adresářovou strukturou a bez možnosti vidět ostatní procesy) se zapnutým SECURE_NOROOT.
Kvalifikace jsou zajímavá i když komplikovaná bezpečnostní vlastnost. Během téměř deseti let byly součástí jádra, ale buď nefungovaly nebo byly ignorovány nebo obojí. Po nejnovější práci, kterou udělali Hallyn, Morgan a ostatní, se kvalifikace konečně stávají plně fungující alternativou k věcem, jako je SELinux. Bude zajímavé pozorovat, jestli se objeví více uživatelských utilit, které budou kvalifikace využívat, a jestli je začnou využívat distribuce. Jednoho dne root možná odplyne do dáli.
Jaderní vývojáři obecně velmi dobře reagují na bezpečnostní problémy. Jakmile je objevena slabina v jádře, patch brzy následuje; správci systému potom mohou patch aplikovat (nebo od svého distributora získat opatchované jádro), rebootovat stroj a žít s klidem, že slabina byla opravena. To je systém, který funguje vcelku dobře.
Zbývá ale jeden háček: reboot systému je problém. Přinejmenším proto, že vyžaduje několik minut downtimu, což v mnoha situacích nelze tolerovat. Restart také přeruší jakoukoliv probíhající práci, přeruší síťová spojení a může způsobit ztrátu výsledků dlouho běžících procesů. A to nejdůležitější - rebooty se pro jistou skupinu linuxových administrátorů, kteří si vysokého uptime váží nadevšechno, ukázaly jako traumatizující. Administrátoři si v současnosti mohou vybrat mezi mnoholetým uptime a bezpečnostními opravami; cokoliv, co je zbaví dilema této velikosti, lze pouze uvítat.
Toto "cokoliv" by mohl být právě nedávno oznámený projekt ksplice. S ksplice mají správci systému to nejlepší z obou světů: bezpečnostní opravy bez ošklivých rebootů.
Podrobné vysvětlení, jak ksplice funguje, lze nalézt v tomto dokumentu [PDF]. Ve zkratce ksplice potřebuje na vstupu zdrojový kód běžícího jádra a bezpečnostní patch. Potom přeloží dvě jádra, jedno s patchem a jedno bez něj; jádra jsou přeložena se speciální sadou voleb, které umožní jednoduše přijít na to, které funkce se vlivem patche změnily. Obě jádra jsou porovnána za účelem nalezení těchto funkcí - změny se mohou šířit dále, než by se dalo čekat, obzvlášť pokud byla například modifikována inline funkce.
Jakmile je vytvořen seznam těchto funkcí, jejich aktualizovaný kód se zabalí do jaderného modulu, který je posléze nahrán do systému. Teď přichází ta obtížnější část: přimět běžící jádro, aby začalo používat nový kód. To vyžaduje patchování běžícího kódu, což je riskantní záležitost. Ksplice začíná voláním stop_machine_run(), který každému procesoru naloží vlákno o vysoké prioritě, čímž převezme kontrolu nad všemi procesory v systému. Potom prozkoumá všechna vlákna běžící v systému, aby se ujistil, že žádné z nich neběží ve funkci, která se bude měnit; pokud je tato podmínka splněna, na začátek každé nahrazované funkce se vloží trampolínový skok na začátek nahrazující funkce (volání starého kódu "přeskočí" do nahrazujícího kódu) a život jde dál. Pokud některé z vláken běží v nahrazované funkci, ksplice se stáhne a zkusí to později.
Tato metoda ukládá mnoho omezení. Jedno je to, že lze aplikovat jedině takové změny v kódu, ve kterých se nezměnily datové struktury. Další vyplývá z přístupu založeném na opakování, kterým se ujišťujeme, že žádné vlákno neběží v patchovaných funkcích; co se stane, pokud některá z těchto funkcí není nikdy volná? U jaderných funkcí jako jsou schedule(), sys_poll() nebo sys_waitid() je pravděpodobné, že v nich vždy budou běžet nějaké procesy. V takovém případě se ksplice nakonec vzdá a informuje uživatele, že oprava nebyla možná; že jednoduše není možné v těchto konkrétních funkcích změny provést.
Tato omezení znamenají, že z 50 patchů prozkoumaných vývojáři ksplice by jich nebylo možné aplikovat osm, takže mnoholetý uptime se s aplikací všech patchů stále neslučuje. Nicméně i tak má ksplice velký potenciál redukovat downtime spojený s opravami jádra. Je dost pravděpodobné, že o ksplice bude velký zájem na místech, kde jsou provozovány kritické [mission-critical] systémy s vysokým uptime.
Začlenění tohoto kódu do jádra stojí v cestě pár věcí. Jednou je záležitost kvality programování a lze ji vyřešit. Potom je tu problém, že hlavní vývojář není přesvědčen, že začlenění tohoto kódu má smysl, protože je to v podstatě samostatná vlastnost. Odpověď Andiho Kleena vyjasnila (obvyklé) důvody:
Abych byl upřímný, nejsi první, kdo s něčím takovým přišel (ačkoliv, pokud vím, jsi první, kdo to poslal do l-k). Nicméně obvyklým problémem čehokoliv, co je spravováno mimo strom, je, že to obvykle shnije a je zapomenuto. Jediný použitelný způsob, jak takováto rozšíření udržet obecně použitelná, je začlenit je do hlavní řady.
Dá se předpokládat, že kód bude časem navržen k začlenění, nicméně je tu ještě jedna obtíž, na kterou upozornil Tomasz Chmielewski: Microsoft drží patent popsaný takto:
Systém a metody pro automatické aktualizace komponent softwaru na běžícím počítačovém systému bez potřeby přerušení služby. Softwarový modul je patchován za běhu nahráním patche do paměti a modifikací instrukce v původním modulu tak, aby se skočilo do patche.
Microsoft s touto novinkou přišel v dávné minulosti: 2002. Oznámení okamžitě vytáhlo na světlo dav překvapených prošedivělých pánů, kteří si jednoznačně pamatují používání této techniky na svých systémech PDP-11 několik dekád předtím, než Microsoft patchování za běhu "vynalezl". Základní tvrzení tohoto patentu se tedy zdá být zneplatněno několika dekádami předchozího používání [prior art], ale některá závisející tvrzení zahrnují vlastnosti (jako například obsazení všech ostatních procesorů v systému), u kterých je nepravděpodobné, že by na PDP-11 k něčemu byly.
Vzhledem k tomu, že jaderní vývojáři jsou si nyní tohoto patentu vědomi, musí ho při rozhodování, jestli kód zařadit do hlavní řady, vzít do úvahy. Nebylo by překvapení, kdyby se rozhodli vyhnout se štvanici od microsoftí FUD mašinérie, i kdyby se všichni shodli na tom, že patent není platný. Takže u slibné technologie se objevuje riziko, že v jádře nebude kvůli softwarovému patentu, který byl zapsán nejméně o 30 let pozdě.
Jediné opravdu rozumné řešení by bylo, kdyby kód začlenil Novell v rámci patentové dohody s MicrosoftemTakže by pak mohl být jen v jádrech od SUSE, resp. imunní vůči buzeraci by byli pouze platící zákazníci SUSE krytí jeho nasmlouvanou ochranou?
24.6.2008 12:23
stativ | skóre: 54
| blog: SlaNé roury
S tim take souvisi otazka, zda zdrojove kody k programu s patentovanou vlastnosti ten patent porusuji, nebo ne? Zdrojove kody jsou preci jen plan na ten program, ne samotny program, a jako takove jsou podobne dokumentaci toho patentu jako takoveho.Pamatuju, jak byly nektere kryptograficke programy, jejichz vyvoz z USA byl nezakonny, legalne vyvezeny jako zdrojove kody svazane do knihy, ktera byla nasledne nasacanovana a zOCRkovana zpet na zdrojak. U patentu to nejspis bude podobne - zdrojak na papire neni program, takze by na nej patent platit nemel.
24.6.2008 22:48
Grunt | skóre: 23
| blog: Expresivní zabručení
| Lanžhot
Vzhledem k tomu, že jaderní vývojáři jsou si nyní tohoto patentu vědomi, musí ho při rozhodování, jestli kód zařadit do hlavní řady, vzít do úvahy. Nebylo by překvapení, kdyby se rozhodli vyhnout se štvanici od microsoftí FUD mašinérie, i kdyby se všichni shodli na tom, že patent není platný.To by si tak mohli zkusit…
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.