Portál AbcLinuxu, 11. května 2024 22:57
Stav vydání jádra. Citáty týdne. Projekt bezpečnostního stromu linux-stable. Sledovací body s BPF.
Současný vývojový kernel je 4.6-rc3, vydaný 10. dubna. „Největším samostatným patchem je vzkříšení ovladače olpc_dcon, který, jak se ukázalo, nebyl až tak zbytečný. Promarnili jsme šanci – vzkříšení ovladače minulo Velikonoce o týden. Slibuji, že do příště se naše oddělení pro komické načasování polepší.“
Stabilní aktualizace: 4.5.1, 4.4.7 a 3.14.66 byly vydány 12. dubna.
Je to nemoc rozšířená mezi lidmi, kteří studovali informatiku. Lidi si myslí, že „návrh s ohledem na budoucí rozšiřování“ je dobrý nápad.
Je to _příšerný_ nápad.
Pokud si myslíte, že „návrh s ohledem na budoucí rozšiřování“ je dobrý nápad, vlastně tím říkáte: „Já nevím, co chci dělat.“
Naše nedávná zkušenost s linuxovým plánovačem odhalila, že tlak na práci s náročnými vlastností moderního hardwaru, jako jsou architektura NUMA, vysoké náklady na koherenci a synchronizaci cache a divergence latencí CPU a pamětí, vyústil v plánovač s neuvěřitelně složitou implementací. Výsledkem je, že základní funkce plánovače, která má zajišťovat, že spustitelná vlákna používají nečinná jádra, se z něj vytratila.
—Jean-Pierre Lozi et al. [PDF]
Sasha Levin oznámil vznik projektu „Bezpečnostní strom linux-stable“. Cílem je projít všechny stabilní aktualizace a odfiltrovat vše, co není klasifikováno jako bezpečnostní oprava. „Docela dost uživatelů stabilního stromu poukázalo na to, že na komplexních nasazeních, kde ověřování není zrovna triviální, chybí motivace držet se stabilního stromu poté, co dojde k nasazení produktu do provozu. O „nahodilé“ opravy kernelu není zájem a jediným požadavkem je držet krok s bezpečnostními riziky.“
Jednou ze zajímavých funkcí sledovacích nástrojů, jako jsou SystemTap nebo DTrace, je možnost nahrát kód do kernelu a provést analýzu první úrovně na trase datového toku. Sledování může produkovat značné množství dat, ale tato data se často dají významně redukovat jednoduchým zpracováním – například zvětšováním položek histogramu. Současná jádra obsahují velké množství sledovaných bodů, ale postrádají schopnost před exportem výsledků provést jakékoli zpracování sledovaných událostí hned v jaderném prostoru. Vypadá to, že situace se změní díky sadě patchů určených pro vydání 4.7.
Pravidelné čtenáře Jaderných novin by nemělo překvapit, že technologie používaná pro načítání kódu do jádra, je virtuální stroj BPF. BPF umožňuje vykonání kódu v jádře s přísnými omezeními: patří k nim mimo jiné to, že kód může přistupovat pouze k datům, která mu jsou poskytnuta explicitně, a nemůže obsahovat cykly, takže je zaručeno, že poběží v omezeném čase. Kód BPF se dá také zrychlit – může být přeložen do strojového kódu, a to pomocí just-in-time kompilátoru v jádře. Tato kombinace vlastností pomohla BPF dostat se i do dalších jaderných subsystémů mimo ten síťový.
Každý program BPF nahraný do jádra má svůj specifický typ, který vymezuje, kde je vlastně možné program spustit. Patch set Alexeje Starovoitova vytváří nový typ (BPF_PROG_TYPE_TRACEPOINT) programů, které mají být navázány na sledované body. Tyto programy je poté možné nahrát do kernelu pomocí systémového volání bpf(). Navázání programu na sledovaný bod se pak provádí otevřením souboru sledovaného bodu (v debugfs nebo tracefs), přečtením ID sledovaného bodu a použitím příkazu PERF_EVENT_IOC_SET_BPF ioctl(). Tento příkaz umožňuje programům BPF připojení ke kprobes v současných jádrech. Patch set rozšiřuje možnosti použití v závislosti na předaném typu programu BPF.
Když dojde k aktivaci sledovaného bodu navázaného na program BPF, tento program se spustí. „Kontextová“ oblast předaná programu jednoduše představuje data sledovaného bodu, která by byla předána uživatelskému prostoru, až na přístupnost „běžných“ polí. Patch set kupříkladu obsahuje vzorek, který se váže ke sledovanému bodu sched/sched_switch, který se aktivuje, pokud plánovač spustí vykonávání jiného procesu. Soubor format tohoto sledovacího bodu (nachází se v příslušném adresáři v debugfs nebo tracefs) poskytuje následující data:
field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:char prev_comm[16]; offset:8; size:16; signed:1; field:pid_t prev_pid; offset:24; size:4; signed:1; field:int prev_prio; offset:28; size:4; signed:1; field:long prev_state; offset:32; size:8; signed:1; field:char next_comm[16]; offset:40; size:16; signed:1; field:pid_t next_pid; offset:56; size:4; signed:1; field:int next_prio; offset:60; size:4; signed:1;
Od každého programu, který přistupuje k datům sledovaného bodu, se očekává, že tento soubor přečte, aby zjistil, která data jsou dostupná a kde se nacházejí. Pokud tak neučiní, hrozí selhání, pokud se data spojená s tímto sledovaným bodem v budoucnu změní. Program BPF v jádře tento soubor program nemůže, takže je nutné najít jiné řešení. Soubor format tudíž musí přečíst vývojář a pak ho převést na strukturu v C; slouží k tomu nástroj zvaný tplist. Tento patch set obsahuje následující strukturu, generovanou právě pomocí tplist:
/* taken from /sys/kernel/debug/tracing/events/sched/sched_switch/format */
struct sched_switch_args {
unsigned long long pad;
char prev_comm[16];
int prev_pid;
int prev_prio;
long long prev_state;
char next_comm[16];
int next_pid;
int next_prio;
};
Pole pad existuje, protože první čtyři pole (ta společná pro všechny sledované body) nejsou přístupná programům BPF. Ke zbytku se však dá dostat pomocí jména v programu v C (který bude kompilován do BPF a nahrán do jádra). Tento program z této struktury nejspíše extrahuje požadovaná data, zpracuje je po svém a uloží výsledek do mapy BPF, odkud je možné získat výsledek z uživatelského prostoru.
Stejně jako v případě dalších typů BPF programů používá pomocný jaderný kód jména sekcí jako direktivy pro to, jak má být naloženo s konkrétním programem. Takže program, který slouží k tomu, aby byl navázán na sledovaný bod, by měl být uložen explicitně v sekci „tracepoint/name“, kde name představuje jméno požadovaného sledovaného bodu. Takže pro vzorový program je jméno sekce „tracepoint/sched/sched:switch.“
Tento mechanismus pracuje a co je důležitější, na sledovaný bod navázaný program BPF je mnohem úspornější než použití kprobe a následné připojení programu. Již se pracuje na nástrojích (např. argdist), které vytvoří programy BPF pro konkrétní úlohy, argedist vytvoří program pro histogram hodnot daného pole sledovaného bodu. Celkově vzato to vypadá na zajímavý pokrok v nástrojích jádra.
Existuje ovšem potenciální háček: starý problém se sledovanými body a stabilitou ABI. Sledované body odhalí vnitřek jádra, což naznačuje, že se tyto body musí změnit, pokud se změní jádro. Změna sledovacích bodů však může poškodit aplikace, které je využívají. Tohle je problém, který se v minulosti objevil již několikrát. Je to také důvod, proč některé subsystémy (např. vrstva virtuálního souborového systému) použití sledovacích bodů vůbec neumožňují – správci mají obavy, že nebudou moci dělat důležité změny, protože by to mohlo rozbít aplikace, které jsou na příslušných sledovaných bodech závislé.
Pro programy v uživatelském prostoru byl celý problém poněkud zmírněn dostupností kódu knihoven, který umožňuje přístup k datům sledovaných bodů. Aplikace, která tyto nástroje využívá, by měla být přenosná napříč různými verzemi jádra. Jenže programy BPF nemají k těmto knihovnám přístup a dojde-li ke změně využívaných sledovaných bodů, tyto programy se (možná nepozorovaně) pokazí. Obavy spjaté s ABI pozdržely zařazení této funkcionality v minulosti, tentokrát se však o ABI téměř nemluví. Alexej tvrdí, že rozhraní pro programy BPF je shodné s tím pro programy uživatelského prostoru, takže ohledně ABI by se neměly objevit nové starosti. Zda nepřinese rozhraní BPF žádné nové problémy spojené s ABI, to se ukáže až v následujících letech.
Vskutku to vypadá, že se dočkáme toho, jak to dopadne. David Miller patche zařadil do next-tree, což znamená, že by se do hlavního repozitáře mohly dostal v začleňovacím okně 4.7. Uživatelé, kteří chtějí mít lepší přehled, co se děje v jádře, nejspíše ocení, že tady ta možnost bude.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.