Jaderné noviny - 24. 3. 2016: Začleňovací okno 4.6, 2. část

1. 4. 2016 | Redakce | Jaderné noviny | 2437×

Stav vydání jádra. Citát týdne. Začleňovací okno 4.6, 2. část.

Stav vydání jádra

Začleňovací okno 4.6 zůstává i nadále otevřeno. Viz článek o novinkách, které byly začleněny za poslední týden.

Stabilní aktualizace: Žádné nebyly vydány, žádné nejsou v procesu revidování.

Citát týdne

Mám úplně zavařený mozek, jak týdny koukám na výsledky fuzzingu, měl bych nějakou dobu dělat něco jiného… cokoliv jiného.

-Peter Zijlstra k málo známým nebezpečím současných debuggovacích metod

Začleňovací okno 4.6, 2. část

V době psaní tohoto článku začlenil Linus 11 118 neslučovacích sad změn vývojového cyklu 4.6 do hlavního repozitáře. Zhruba 10 000 jich přibylo od shrnutí z minulého týdne. Příliv patchů se již nedá popsat jako „pomalý“. V jejich záplavě můžeme najít spoustu významných novinek.

Mezi ty nejvýrazněji viditelné pro uživatele patří:

• Podpora klíčů pro ochranu paměti byla začleněna. Jde o specifikum Intelu, které uživatelskému prostoru umožňuje rozdělit paměť do zón a aplikovat další přístupová omezení jednotlivým zónám. Systémové volání pro manipulaci s klíči pro ochranu paměti zatím nebylo začleněno, čeká se na podrobnější kontrolu. Ovšem v Linuxu 4.6 dojde k využití klíčů k implementaci skutečné paměti pouze pro vyhodnocování, tedy ze které vyhodnocující proces nemůže číst.
• Kontrolní skupiny nyní pracují se jmennými prostory. Nový příznak CLONE_NEWCGROUP pro clone() slouží k vytvoření procesu v novém jmenném prostoru kontrolní skupiny. Viz tento patch pro dokumentaci této nové funkcionality. Souborový systém kontrolních skupin je nyní možné připojit uvnitř uživatelských jmenných prostorů.
• Systémová volání preadv2() a pwritev2(), která používají extra argument „flags“, byla zařazena. Umožňují přidání nové funkcionality. Prvním příznakem je RWF_HIPRI umožňující polling pro požadavky s vysokou prioritou.
• Page poisoning tradičně slouží k ladění jádra, naplňuje volné stránky speciálním vzorem, který se dá lehce rozpoznat, když hledáte, co se pokazilo. Ve verzi 4.6 se dá poisoning nastavit nezávisle na ostatních nastaveních pro ladění; hodnota „jedu“ může být nula, takže stránky budou po uvolnění automaticky vymazány. Toto chování, inspirované patchi grsecurity/PaX, snižuje šanci, že z jádra uniknou citlivá data.
• Kód rozpoznávání thrashingu subsystému řízení paměti nikdy pořádně nefungoval v kontrolních skupinách – to se povedlo napravit. Výsledkem by mělo být lepší chování v okamžiku, kdy jsou konkrétní kontrolní skupiny vystaveny tlaku paměti.
• Subsystém architektury měření integrity (IMA) nyní vyžaduje podepisování pravidel a měření integrity těchto pravidel před načtením.
• Architektura ARM64 nyní podporuje funkci „user access override“, která se nachází v ARMv8.2. Umožňuje (jádru) přístup k uživatelskému prostou za pomocí běžných, neprivilegovaných instrukcí, které kontrolují oprávnění vlastnických procesů běžným způsobem. To brání jádru před tím, aby bylo zmateno a přistupovalo k paměti, na kterou by nemělo sahat.
• ARM64 nyní podporuje také randomizaci rozvržení jmenného prostoru jádra.
• Reprezentace univerzálních I/O zařízení v jádře se dočkala velkého přepracování, struktura gpio_chip je nyní skutečným zařízením v modelu zařízení. K získávání informací o GPIO slouží nové ABI, ale ještě je třeba něco dodělat. Linus Walleij k tomu podotkl: „Nyní můžeme GPIO pořádně detekovat z uživatelského prostoru. Stále jsme však nepřišli se způsobem, jak GPIO z uživatelského prostoru použít.“ Viz tools/gpio/lsgpio.c pro ukázku nového ABI. Původní ABI sysfs je nyní považováno za zastaralé (ale ještě nebylo kompletně nahrazeno).
• Slack hodnota časovače procesu – hodnota, o kterou mohou být požadavky časovače zpožděny, aby se sešly s ostatními – může být nyní modifikována skrze /proc/PID/timerslack_ns.
• Rozšířený virtuální stroj BPF implementuje CPU mapy pro vysokorychlostní sběr statistik. Také byl přidán nový typ mapy pro sledování stavu zásobníku.
• K dispozici je „devlink“, nové API pro ovládání sítí. Je určeno ke konfiguraci různých parametrů, které nejsou spojené s žádnou konkrétní třídou zařízení. Tento protokol postrádá dokumentaci, nějaké informace se dají najít v začleňovacím seznamu změn.
• Byl sloučen multiplexer spojení jádra, který slouží k manipulaci s některými typy protokolů vyšší úrovně v jádru.
• Velký počet síťově orientovaných přepínačů (tcp_syn_retries, tcp_synack_retries, tcp_syncookies, tcp_reordering, tcp_retries1, tcp_retries2, tcp_orphan_retries, tcp_fin_timeout, tcp_notsent_lowat, igmp_max_memberships, igmp_max_msf, igmp_llm_reports a igmp_qrv) si je nově vědomý síťového jmenného prostoru, takže různé jmenné prostory mohou mít různé hodnoty.
• Byl začleněn mechanismus lokálního snižování zátěže kontrolního součtu (více v tomto článku). Zrychluje výpočet kontrolního součtu, čímž urychluje tunelové implementace protokolů. Viz Documentation/networking/checksum-offloads.txt.
• Došlo k odstranění podpory netlinku skrze segmenty sdílené paměti. Tato funkce nikdy nepracovala správně a vypadá to, že není využitá v žádném kódu v uživatelské prostoru.
• Došlo k přidání několika nových příkazů ioctl() souborového systému: Q_GETNEXTQUOTA a Q_XGETNEXTQUOTA. Umožňují efektivní iteraci skrze všechny kvóty na souborovém systému.
• Souborový systém Btrfs má nový parametr pro připojení, nologreplay, který zabraňuje opětovnému vyhodnocení stromu záznamů, dá se to využít spolu s ro, aby souborový systém byl skutečně připojený jen pro čtení. Další nový parametr usebackuproot slouží k nahrazení stávajícího recovery.
• Nově podporovaný hardware:
  • Audio: Kodeky Maxim MAX9867 a max98926, Realtek RT5514, audio koprocesory AMD, řadiče Allwinner A10 S/PDIF.
  • GPIO: GPIO ovladače WinSystems WS16C48, ACCES 104-DIO-48E, Technologic TS-4800 FPGA, TI TPIC2810 8-Bit I2C GPIO expandéry, řadiče TI TPS65218, TI TPS65086, MEN 16Z128.
  • Polohovací zařízení: Touchpady BYD BTP10463, dotykové obrazovky MELFAS MIP4, integrované dotykové obrazovky Freescale i.MX25 a další zařízení, která využívají protokol Synaptics „Register Mapped Interface“.
  • Multimédia: „adaptační vrstvy kamery“ nahrávacích enginů TI.
  • Různé: Řadiče Xilinx NWL PCIe, Cavium ThunderX PEM PCIe, generátory náhodných čísel Microchip PIC32, doplňkové procesory ST Microelectronics, enginy Qualcomm HIDMA DMA, a spoustu dalších.
  • Sítě: Gigabitové ethernetové řadiče MediaTek MT7623 a karty Intel Etherner X722 i WARP.
  • USB: PHY Rockchip EMMC a DisplayPort.
  • Watchdog: Intel MEI iAMT, National Instruments 903x/913x, časovače WinSystems EBC-C384 a generické SBSA ARM.

Změny viditelné pro vývojáře jádra:

• Byly začleněny patche validace zásobníku při překladu. Poskytují nástroj, který zajišťuje, že zásobník volání bude vždy platný. Výsledkem je spolehlivější trasování zásobníků pro vývojáře. Tato funkce je nutná pro další vývoj mechanismu pro patchování za chodu.

• K dispozici je nová funkce pro uvolňování sady objektů:

  void kfree_bulk(size_t size, void **objects);

  Od kmem_cache_free_bulk() se liší absencí ukazatele na strukturu kmem_cache, což znamená, že je možné uvolnit objekty z vícero slabů současně. Tato metoda něco stojí, takže někdy se doporučuje používat kmem_cache_free_bulk().

• Subsystém cpufreq, nabitý nastavenými frekvencemi CPU tak, aby odpovídaly aktuální zátěži, se dočkal významných změn. V současných kernelech využívá časovače k periodickým vzorkům zatížení procesoru a možná také ke změnám. Ve verzi 4.6 naopak budou časovače eliminovány přímým voláním správců cpufreq plánovači. V budoucnu bude správa používat předpokládané informace o zatížení přímo z plánovače a doufejme, že dospěje k lepším rozhodnutím, ale tohle je úkol pro budoucí vývojové cykly.
• sscanf() má nyní základní podporu pro porovnávání skupin znaků. Používá operátor %[ (např. %[abc] k nalezení některého abc). Porovnávány mohou být pouze explicitně vyjmenované skupiny, "-" nemá v setu znaků žádný speciální význam.
• Nový nástroj dtx_diff v adresáři scripts/dtc umí vypočítat rozdíly mezi stromy zařízení v různých formátech.
• Generický kód podporující šifrované souborové systémy byl přesunut do vrstvy VFS (fs/crypto), takže je možné ho použít i mimo souborové systémy ext4 a f2fs.
• Subsystém I2C má nyní nový sběrnicový demultiplexor založený na pinovém ovladači, který dovoluje vybrat běhové prostředí mezi několika I2C řadiči. Viz i2c-demux-pinctrl.txt pro více informací.
• Byl začleněn analyzátor pokrytí kódu jádra "kcov". Pomáhá při fuzzingu a jiných testovacích metodách kontrolovat, že testy prošlo co nejvíce kódu. Viz Documentation/kcov.txt.

V tuto chvíli to vypadá, že většina změn již byla v tomto vývojovém cyklu začleněna. Okno pravděpodobně zůstane otevřené do 27. března (tzn. nyní je již zavřené), takže je možné, že se ještě něco zajímavého objeví. Příští týden se Jaderné noviny budou věnovat shrnutí významných změn, které se objeví na konci začleňovacího okna 4.6.

       

Komentáře

[Bill Gates]

"V době psaní tohoto článku začlenil Linus 11 118 neslučovacích sad změn"

Prominte mi muj hloupy dotaz, vyvoj linuxoveho jadra sleduji jen ze zdejsich jadernych novin, nicmene zajima me jedno: Jak muze jeden clovek zpracovat jakychkoliv 11000 polozek v rozumnem case? Jednotlive? Predpokladam ze to Linus dostane nejak predpripraveno a predsouhlaseno a klikne a je to zahrnuto do pristiho vydani jadra, treba 1000 patchu (sad zmen) jednim klikem. Nebo to skutecne prochazi a procte info o vsech 11000 polozkach? Vzdyt by nedelal nic jineho a m*dlo by mu z toho. Jak dlouho muze trvat zarazeni jednoho patche nebo jedne sady zmen?

Diky za objasneni.

[Michal Kubeček]

Většina commitů přichází prostřednictvím pull requestů (příklad) od maintainerů jednotlivých subsystémů. Patche z toho pull requestu už předtím prošly review buď přímo příslušným maintainerem subsystému nebo maintainery jednotlivých menších částí (v tomto případě např. netfilter nebo IPsec). Linus pak neprochází každý jednotlivý patch, ale jen to, co ho z nějakého důvodu zaujme.

[Jardík]

Znamená to, že když maintainer bude NSA donucen tam dát backdoor, tak to Linus prostě schválí, protože si to nepřečte. To je jeden z důvodů, proč vždy při aktualizaci jakéhokoliv programu musím procházet diff k předchozí verzi a celý den pak nestihnu dělat nic jiného, hlavně u kernelu jsou ty diffy obrovské.

[Michal Kubeček]

Někteří lidé by si měli uvědomit, že ani 1. dubna, nepřijde ostatním automaticky vtipné cokoli, co napíšou.

[Bill Gates]

A jak je to prosim s duveryhodnosti jednotlivych maintaineru? Linus jim musi bezvyhradne verit, jinak by se do jadra mohl dostat nejaky bordel. Tohle je v jednom cloveku proste uz neuhlidatelne asi. Takove mnozstvi. Zase ta rychlost vyvoje je samozrejme asi mnohem vetsi nez u komercnich projektu (treba Widle) kde kazdy dela do vyse mzdy a navic kvalitativne kdo vi jak, hlavne ze to funguje a nazdar. U opensource rada lidi dela bez naroku na mzdu treba jen kvuli tomu ze to sami potrebuji pro sve ucely (i komercni) ale presto to daji komunite k dalsimu uziti. Ten post Jardika neni az tak mimo. Jeden "vadny" (treba financne motivovany) maintainer muze do jadra zanest pekny nerad (i u opensource se da urcita funkcnost skryt ze neni na prvni pohled videt) a nez si toho nekdo vsimne (chvala bohu opensource) tak se to muze rozdistribuovat a byt prusvih.

[Michal Kubeček]

Ten post Jardika neni az tak mimo.

Hm… vy opravdu věříte tomu, že "Jardík" při každém updatu každého balíčku prochází kompletní diff natolik důkladně, aby odhalil případný backdoor? A že i v případě jádra mu to trvá jen "celý den"? Kdyby takový člověk existoval, určitě by neřešil otázku, jak sehnat práci, kam by nemusel dojíždět, protože by ho několik firem ochotně zaměstnalo, i kdyby trval na tom, že bude pracovat na home office z vily na Malibu, kterou mu tam firma bude muset postavit a platit její provoz.

Co se týká toho zbytku, jak byste si to tedy představoval jinak? Že se vývoj jádra zpomalí natolik, aby Linus osobně stíhal dělat důkladný review každého jednotlivého patche? Že se omezí jeho velikost natolik, aby Linus dostatečně detailně rozuměl celému stromu? A hlavně: když nedůvěřujete maintainerům jednotlivých subsystémů, proč absolutně důvěřujete Linusovi?

[Bill Gates]

Nedavam zadne konkretni zavery, jen se ptam a trochu teoretizuji. Zadne konkretni predstavy. Tak jak to funguje je to evidentne dobre a me osobne se to libi. Nicmene racionalne receno nelze to uplne uhlidat, uz to potrebuje vice lidi na spicce vyvoje - tech jakoby "osvicenych diktatoru". Na druhou stranu rychlost i kvalita vyvoje je diky otevrenosti vyssi nez u ciste komercnich projektu.

Jinak jako clovek, ktery od dob XPcek nekdy pred mnoha lety presedlal na linux (nejdriv fedora pak ubuntu a ted uz dlooooouho debian) nedam na linux dopustit. Filosofie vyvoje a cele to prostredi je proste luxus. Tedy az na systemd, jehoz jsem dost odpurcem. Ale to s linuxem mnoho nema spolecneho .. nastesti. Dokud se to nezacne cpat do jadra.

Dalsi vec - "absolutni duvera Linusovi" - nikoliv. V jednom cloveku se to uz neda zvladnout. Verim spise mnozstvi vyvojaru kteri pohledem do konkretni casti kodu a jeho ladenim mohou odhalit mnohem drive prusvih - diky otevrenosti, nez v uplne uzavrenem kodu. Dalsi moznosti je moznost forknout cele jadro a udelat jadro lepsi, bez pripadneho prusvihu. To znamena konkurence, decentralizace a to je myslim dobra cesta.

[Michal Kubeček]

Verim spise mnozstvi vyvojaru kteri pohledem do konkretni casti kodu a jeho ladenim mohou odhalit mnohem drive prusvih - diky otevrenosti, nez v uplne uzavrenem kodu.

Tak to v podstatě funguje. V těch exponovanějších částech jádra se patch typicky pošle do příslušného mailinglistu, kde se má možnost vyjádřit každý, koho to zajímá. Pak je nějakou dobu v gitu příslušného subsystému (u větších a kontroverznějších featur může trvat i několik vývojových cyklů, než se vůbec dostane tam), z něj teprve následuje pull request do Linusova stromu a i tam de facto čeká skoro dva měsíce, než se dostane do release. U bugfixů je celý proces rychlejší, ale ty zase bývají méně rozsáhlé a méně komplikované.