Portál AbcLinuxu, 13. května 2024 04:54
Vzhledem k tomu, že se nám příliš nedaří dohnat skluz u překladů Jaderných novin, jsme se rozhodli vydávat každý týden až do konce roku jakýsi souhrn z vybraných článků a citátů za celý daný měsíc. Od ledna potom najedeme na aktuální dění kolem vývoje jádra a budou vycházet skutečné Jaderné noviny. Tento týden je to přehled za říjen.
Vývojový kernel 4.3-rc3, byl vydán 27. září. Linus řekl: „Jako obvykle je rc3 větší než rc2 (začínají se trousit opravy), ale nic alarmujícího nevyniká. Vše vypadá normálně, převážnou část tvoří ovladače (největší část připadá na GPU a síťové ovladače) a aktualizace architektur, sítě a aktualizace souborového systému, spolu s dokumentací.“
Vývojový kernel 4.3-rc4 byl vydán 4. října. „Všichni víte, jak to chodí. Je neděle a nová verze je venku.“
Vývojový kernel 4.3-rc5 byl vydán 11. října. „Jako obvykle hromada malých oprav pro ovladače a kód architektur, navíc pro zpestření aktualizace souborového systému.“ Tento prepatch obsahuje také změnu názvu jádra, které zní „Blurry Fish Butt“.
Vývojový kernel 4.3-rc6 byl vydán 18. října. „Vše je v poklidu, dokonce se to ještě zlepšuje. Mám z toho radost, i když moje podezřívavá povaha hledá věci, na které bych si mohl postěžovat. Chovají se všichni vzorně, protože se blíží Kernel Summit, a tak se snaží vypadat co nejlépe?“
Vývojový kernel 4.3-rc7 byl vydán 25. října. „Možná, že doma je stále sobota, ale já mám s blížícím se Kernel Summitem v Koreji náskok, jsa v časovém pásmu +0900, a tak už mám neděli. Což znamená, že je den vydání.“ Mělo jít o poslední prepatch a finální vydání se plánovalo na 27. října.
Stabilní aktualizace: 4.2.2 a 4.1.9 byly vydány 29. září.
Stabilní aktualizace: 3.14.54 a 3.10.90 byly vydány 1. října, 4.2.3 a 4.1.10 3. října.
Stabilní aktualizace: 4.2.4, 4.1.11, 3.14.55 a 3.10.91 byly vydány 22. října. Potom je 27. října následovaly verze 4.2.5, 4.1.12, 3.14.56 a 3.10.92.
Osobně bych byl rád, kdyby došlo k začlenění RT-PREEMPT – využití pro to existuje. To samé bych si přál v případě NOHZ. Měla by se tím vyřešit hromada problémů s izolací RT úkolů bez ztráty výkonu na non-RT CPU. A konečně by mi nevadilo začlenění nelinuxového RT jádra, třeba Cobalt (ó hrůzo) do hlavního stromu. Každý z těchto přístupů má své výhody i nevýhody. Linux je koneckonců to, co chceme, aby byl – a klidně by mohl mít v kódu nějaký malý RT mikrokernel.
Pokud je mi známo, tak jsou patentové spory ohledně dvojího jádra, které nás trápily, za námi, takže se nabízí prostor k prozkoumání.
Dlouho jsem měl pocit, že RT-PREEMPT stahuje pozornost od ostatních, technicky platných RT přístupů, od začlenění do hlavního stromu.
„Host Managed Drive“ je eufemismus prodejců pro „nevíme, jak to zrychlit, ale máme v nabídce tohle (nestandardní) rozšíření pro ‚aplikace‘, které by to mělo zrychlit. Nejsme si sice jisti, jak by se mělo používat, ale to není náš problém.“
Sarah Sharp oficiálně oznámila, že odchází z jaderné komunity. „Nebylo to jednoduché rozhodnutí. Dlouho jsem se kvůli odchodu cítila provinile. Nakonec mi došlo, že nemůžu přispívat do komunity, kde mě všichni respektovali po profesionální, ale nikoli po osobní stránce. Nemůžu pracovat s lidmi, kteří ochotně povzbuzovali nováčky, aby posílali patche, a potom tvrdili, že správcům by mělo být dovoleno používat jakákoli odporná slova, v zájmu zachování radikální emocionální poctivosti. Nechci pracovat s lidmi, kterým jsou promíjeny drobné sexistické nebo homofobní vtipy. V komunitě, která má ‚Code of Conflict‘ (kodex pro řešení konfliktů), ve kterém chybí seznam chování, kterému by bylo dobré se vyhnout, ale nemá sílu prosadit jeho dodržování, se cítím bezradně.“
James Bottomley, správce sybsystému SCSI, zveřejnil svůj pohled na problematiku zdvořilé e-mailové komunikace kolem vývoje jádra. „Celkově jsem hrdý na to, jaký pokrok jsme udělali ve zdvořilosti a jak jsme se za ty roky zlepšili. Jsme dokonalí? V žádném případě (ale v takto velké komunitě není dokonalost dosažitelným cílem). Nicméně jsme prošli zatěžkávací zkouškou: i jedinci se špatnými patchi zaslanými na několik mailing listů se dostalo zdvořilosti a ochotné pomoci, přestože se příslušné chování několikrát opakovalo.“
Stephen Rothwell, správce linux-next, oznámil, že nejméně do 2. listopadu nebudou žádné nové aktualizace. Takže kód přidaný do subsystému stromů po 22. říjnu se neobjeví dříve, než se otevře začleňovací okno 4.4. Řekl, že zatím obsahuje linux-next na 8500 commitů, takže očekává, že na 4.4 je ještě hromada práce, která zatím není vidět.
V době neustávajících útoků a sledování je pořádné generování náhodných čísel k zabezpečení našich systémů a komunikace nutné. Kvalita těchto čísel bývá často tématem diskuzí. Výkon, s jakým jádro generuje náhodná čísla, většinou nebývá problém. Ukazuje se ovšem, že na velkých systémech (např. NUMA) s velkou poptávkou po náhodných číslech může problém s kolizí zámků v generátoru náhodných čísel (RNG) vést k významnému omezení výkonu systému jako celku. Patch, který toto napravuje, je relativně jednoduchý, ale dává nám také možnost blíže prozkoumat, jak tento subsystém vlastně pracuje.
Většina čtenářů je jistě obeznámena s tím, že jaderný subsystém RNG shromažďuje entropii (náhodnost) a poskytuje je dále skrze dvě rozhraní. První (/dev/random) je přísně omezeno tak, že nemůže poskytovat více entropie, než kolik bylo systémem nashromážděno, druhé (/dev/urandom) funguje jako generátor pseudonáhodných čísel. Tímto způsobem může pokračovat v poskytování náhodných dat v situacích, kdy dodávaná entropie nestačí k pokrytí poptávky. Pro většinu aplikací, i těch kryptografických, je druhá varianta více než dostatečná, ale /dev/random je zde pro ty, kdo vyžadují a potřebují skutečně náhodná data a nevadí jim trochu si počkat, když to situace vyžaduje.
Celý článek je zde.
Počítače stráví hodně času kopírováním souborů. Souborové systémy mají často mechanismy k urychlení, ale obecně se dá říct, že kopírování stále probíhá v uživatelském prostoru – v cyklu dochází ke čtení velkých bloků dat z jednoho souboru a jejich zápisu do dalšího. Za ta léta se objevilo několik nápadů, které měly nabídnout rychlejší kopírovací mechanismy (viz diskuze ohledně reflink()), ale ani jeden se zatím nedostal do hlavního stromu. Naděje je ovšem věčná, nové iniciativě by se to mohlo podařit.
Jedná se o patch Anny Schumakerové copy_file_range(). Je postaven na základech, které dříve položil Zach Brown, ke kterým Anna přidala spoustu vylepšení. Tento patchset přidává nové systémové volání:
ssize_t copy_file_range(int fd_in, loff_t *off_in, int fd_out,
loff_t *off_out, size_t len, unsigned int flags);
V zásadě toto systémové volání kopíruje len bajtů od offsetu *off_in v souboru fd_in do offsetu *off_out v fd_out. Má-li kterýkoli z offsetů hodnotu NULL, operace začne na aktuální pozici v souboru (důvodem pro použití ukazatelů v offsetech je právě schopnost rozlišovat mezi hodnotami NULL a nula). Vracená hodnota představuje počet zkopírovaných bajtů, která může být jako obvykle menší, než co bylo požadováno.
Celý článek je zde.
Virtuální stroj Berkley packet filter (BPF) za posledních několik let získal nové schopnosti a vyrostl nad rámec svého původu v síťovém subsystému. Kromě jiného získal také své vlastní systémové volání bpf(), které umožňuje načítání programů BPF do jádra, a další pomocné funkce. V současných jádrech je systémové volání bpf() dostupné pouze uživateli root – a to ne ledajakému. K využití tohoto volání je třeba být rootem v systémovém jmenném prostoru od samého začátku. Původním záměrem ovšem bylo zpřístupnit volání bpf() neprivilegovaným uživatelům. Nyní jsou v oběhu patche, které by toto měly umožnit.
Vývojáři jsou pochopitelně nesví z toho, že by měli umožnit neprivilegovaným uživatelům nahrávat kód do jádra pro jeho další zpracování v kontextu jádra. Možností, jak by se věci mohly vymknout z ruky a způsobit škody, je požehnaně. Posun od prvotního reflexu, který prostě zakazuje takový přístup, vyžaduje značnou míru jistoty, že neexistuje způsob, jakým by mohl škodlivý program BPF jakkoli ohrozit jádro.
Celý článek je k dispozici zde.
Čekací fronta je v jádru datová struktura, která umožňuje jednomu nebo více procesům čekat, dokud se nestane něco „zajímavého“. Využívá se v celém jádře k čekání na dostupnou paměť, dokončení I/O, příchod zpráv a další věci. V počátcích Linuxu byla čekací fronta jednoduše seznamem čekajících procesů, ale řada komplikací se škálovatelností (včetně problému, o kterém se psalo v neblaze proslulé zprávě Mindcraft z roku 1999) vedla k tomu, že nabyla na složitosti. Patch jednoduchých čekacích front je pokusem vrátit kyvadlo zpět na druhou stranu.
Jednoduché čekací fronty nejsou nic nového, psalo se o nich v roce 2013. API se od té doby moc nezměnilo, tím pádem zde není třeba opakovat tehdejší diskuzi. Pokud se vám nechce pročítat původní článek: jednoduché čekací fronty poskytují rozhraní, které se podobá klasickým čekacím frontám. Rozdílem jsou funkce, o které byly jednoduché fronty okleštěny. Jedná se např. o exkluzivní probouzení (důležitá funkce, motivovaná právě výše uvedeným reportem Mindcraft), zrušitelná „killable“ čekání, časové limity ve vysokém rozlišení atd.
Celý článek je zde.
Jak uvedl ve svém úvodu na letošním Kernel Summitu James Morris, pro bezpečnost Linuxu toho bylo za posledních 10-15 let uděláno hodně. I tak je stále spousta věcí, které bychom mohli dělat lépe, a někdo by mohl poznamenat, že nestíháme držet krok v řadě oblastí, včetně sebeobrany a kalení (hardening). Po této poznámce předal slovo a nechal Keese Cooka, aby přítomným sdělil špatnou zprávu o tom, co všechno je třeba v zájmu zabezpečení jádra udělat.
V oběhu je miliarda zařízení s Androidem. Většina z nich stále běží na jádru 3.4 a (stále docela staré) vydání 3.10 je s velkým odstupem druhé. To je podle Cooka „naprosto děsivé“. Životnost kritických bezpečnostních chyb je obrovská. Často se podaří je najít až po letech od zavedení do jádra. Ovšem útočníci tyto chyby nalézají mnohem dříve a využívají je, dokud to jde.
Chyby se daří nacházet, pomohlo zejména zavedení více kontrolorů a podobně. Opravujeme je. Ale chyby tu vždy budou, protože je píšeme. Je to jak u blbých, ale dělat blbé nám tady moc nepomůže. Místo toho se musíme dostat do bodu, kdy budeme schopni opravovat selhání bezpečně. Nepřeháním, když řeknu, že v době samořiditelných automobilů záleží životy na naší snaze vyřešit tento problém.
Celý článek je zde.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.