Jaderné noviny – 27. 8. 2014: Zprávy z Kernel Summitu 2014

17. 9. 2014 | Tadeáš Pelech | Jaderné noviny | 3177×

Aktuální verze vývojového jádra: 3.17-rc2. Zpráva ze síťové minikonference. Zprávy kernel.org: dvoufázové ověřování a další.

• Aktuální verze vývojového jádra: 3.17-rc2
• Zpráva ze síťové minikonference
• Zprávy kernel.org: dvoufázové ověřování a další

Aktuální verze vývojového jádra: 3.17-rc2

Vývojové jádro 3.17-rc2 vyšlo dne 25. srpna (oznámení). Nová verze vyšla o den později. Linus to vysvětlil:

Odchýlil jsem se od normálního nedělního termínu částečně proto, že nebylo moc co dělat (může za to KS a LinuxCon), a pak taky ze sentimentálních důvodů: na 25. srpna připadá výročí původního ohlášení Linuxu (Zdravím všechny uživatele minixu), takže je to vhodný den na ohlášení nové verze.

Stabilní aktualizace: Minulý týden nebyla vydána žádná.

Změna správce verze 3.4.x
Jak bylo ohlášeno na Kernel Summitu 2014, Greg Kroah-Hartman se vzdal správy jádra 3.4. Normálně by v této situaci verze 3.4 pokračovala bez správce, po (téměř) dvou letech slíbených aktualizací. V tomto případě ale Li Zefan souhlasil, že bude toto jádro spravovat ještě dva roky, do září 2016.

Zpráva ze síťové minikonference

Druhý den Kernel Summitu 2014 zahrnoval i minikonferenci pro vývojáře síťového subsystému.

Dave si připravil několik témat, prvním byl protokol SCTP (Stream Control Transmission Protocol). Síťová vrstva obsahuje spoustu vysoce abstraktního kódu sdíleného mezi implementacemi protokolu. SCPT měl ale vždycky potíže účastnit se tohoto sdílení kvůli své koncepci „Asociací“. V důsledku toho vzniká v subsystému SCTP spousta duplicitního kódu. Vzniká ale nová iniciativa na přepracování implementace SCTP a (významného) sjednocení kódu se zbytkem síťového subsystému.

Jednou z neoptimalizovaných oblastí síťového kódu jsou větší hashovací tabulky alokované pro protokoly jako TCP při spouštění. Zabírají hodně paměti, ale nemusejí být tak velké. Při spouštění systému ale nejde určit, jak velké budou potřeba. Síťová vrstva nyní obsahuje dynamické hashovací tabulky chráněné mechanismem RCU (čtení-kopie-aktualizace). Alokaci tabulek je nyní možné měnit podle potřeby, nemusí se tedy udržovat moc velké.

Práce na eBPF (rozšířený filtr paketů Berkeley) se podle Dava potýká s jistými problémy. Vývojář Alexej Starovojtov připravuje spousty oprav, které recenzenti nestíhají zapracovat. Dave proto musí Alexeje trochu brzdit.

Ted Ts’o navrhl, aby se na eBPF podívali vývojáři SystemTap, protože by mohl úspěšně nahradit speciálně vytvořené moduly jádra, které jsou nahrané nyní. Ale podle Jamese Bottomleyho potřebuje SystemTap co nejobecnější spouštěcí engine s rozsáhlým přístupem k jádru, což mu eBPF umožnit nemůže.

Dave přednesl zprávu o nedávném workshopu Netfilteru ve Francii. Usilovně se pracuje na odstranění centrálního zámku v kódu sledování připojení, aby byl kód podstatně účinnější. Také probíhá výzkum možností provozu rozhraní na maximální hardwarovou rychlost v případě provozu složeného z malých paketů, kde linuxové sítě trochu zaostávají.

Také se diskutovalo o nftables, virtuálních strojích v jádru, které by měly výhledově nahradit iptables. I když probíhají usilovné práce na zajištění vrstvy kompatibility, rozhraní příkazového řádku zatím neumožňuje plynulý přechod z iptables. Neočekává se ale, že by nftables v dohledné době nahradily iptables, nejsou ostatně ani vzájemně kompatibilní na úrovni rozhraní jádra.

Všechny zajímá možnost dávkového odesílání paketů. Rozhraní síťového ovladače je navrženo na odesílání paketů po jednom, neví, jestli jich nebude víc, což často bývá. Kdyby ovladač věděl, že bude posílat víc paketů, odložil by spouštění hardwaru, což by významně snížilo režii. Plánuje se použití několika operací spouště dávkového přenosu. Když bude hardware při čekání na dávku paketů vypnutý, mohly by se deaktivovat kabely, což je ještě potřeba ošetřit.

Bezdrátové sítě

Probíralo se například téma proxy ARP, která by šetřila energii. Přístupové body většinou znají adresy MAC klientů, mohly by tedy odpovídat na požadavky ARP, aniž by adresy znovu zjišťovaly od klienta. Tato úloha by měla být zahrnuta do kódu pro režim bridge.

Větším problémem je přenášení síťových funkcí, kdy procesory v režimu bridge spravují předávací databázi a vůbec do cyklu nezapojují procesor. Problém ovšem je, že správa probíhá buď pomocí binárních ovladačů, nebo kódu uživatelského prostoru, který používá každý výrobce jiný. Některé funkce by mělo pokrýt rozšíření rozhraní netlink. Pro testování se připravuje testovací prostředí emulované pomocí QEMU.

John Linville oznámil, že ho správa bezdrátové sekce začíná zmáhat, ale že ještě nenašel vhodného nástupce. Většina talentovaných vývojářů pracuje pro výrobce hardwaru. A ti obecně neradi vidí, když jejich vývojáři podporují ovladače pro konkurenční výrobce. John proto vyzývá vývojáře, kteří pracují pro subjekt nezávislý na konkrétním výrobci a kteří by chtěli správu převzít, aby se mu ozvali.

Zprávy Kernel.org: dvoufázové ověřování a další

Vývojáři jádra jsou značně závislí na webu kernel.org, který hostuje repozitáře Git a správu zavádění změn a oprav. Proto se také novinky z tohoto webu probíraly i na letošním Kernel Summitu. Diskusi vedl Konstantin Rjabicev. Na kernel.org je založeno 286 účtů vývojářů, tedy o 34 více než loni. Web spravuje celkem 604 repozitářů Git, většinou jde o klony hlavního repozitáře jádra. Protože se ale využívá mechanismu „alternate“, každý jedinečný objekt je na webu uložen jen jednou. Díky tomu zabírají všechny repozitáře jen asi 20 GB místa na disku.

V Montrealu se instaluje nový front-end, na který bude zkopírovaná celá záloha webu. Po spuštění tohoto serveru bude odpojeno západní pobřeží USA. Nyní jsou v provozu dva front-endy. Jeden v Palo Alto (spravovaný ISC) a jeden v Portlandu (spravovaný Tizen Association). Předchozí pokusy a přestěhování front-endu mimo Severní Ameriku prozatím odpadly. Hlavně proto, že je to poměrně nákladné. Tento problém se prozatím daří obcházet vytvořením soustavy zrcadel na webu kernel.googlesource.com. Ty jsou rozmístěny po celém světě a za hlavním zdrojem jsou opožděny maximálně v řádu minut. Problematický je přístup z pevninské Číny, kde nejsou servery Googlu dostupné. Konstantin zatím neví, jak by bylo možné tento problém řešit.

Dvoufázové ověřování

Největší letošní změnou na webu kernel.org je ovšem zavedení dvoufázového ověřování zápisu do repozitářů. Úspěšný útok v roce 2011 podle všeho zneužil klíče SSH z několika odcizených notebooků vývojářů. I když již není možné přihlášení do příkazového řádku, klíče se stále dají zneužít. Bezpečnost by proto mělo zvýšit dvoufázové ověřování.

Jeho použití je prozatím volitelné a lze aktivovat pro každý repozitář samostatně. Podporovány jsou mechanismy HOTP (hardwarové klíče jako Yubikey) a TOTP (mechanismus časových klíčů).

Mechanismus na webu kernel.org pracuje s ukládáním adres IP ověřených vývojářů do whitelistu. Pokud je daná adresa ve whitelistu, je z ní možné provádět zápis do repozitáře. Pokud není, musí se příslušný vývojář ověřit jedním z výše zmíněných způsobů. Po úspěšném ověření je zařazen do whitelistu standardně na dobu 24 hodin. V některých případech mohou vývojáři žádat o zařazení až na 30 dní.

Ověření je na úrovni uživatele, v případě přístupu víc uživatelů k jednomu repozitáři se každý musí ověřit samostatně. Repozitář může mít dva režimy ověřování – dobrovolné (pro uživatele, kteří se chtějí dvoufázově ověřovat z vlastní iniciativy) a požadované (povinné pro všechny uživatele).

Vývojáři se mohou ověřovat různými nástroji. Je podporován například proprietární Google Authenticator nebo Authy. Konstantin doporučuje open source FreeOTP, které se vyčlenilo z Google Authenticatoru, než přešel na proprietární model. Je také možné použít hardwarový klíč Yubikey ze zásoby, kterou vývojářům poskytla společnost Yubico.

Linus Torvalds a Greg Kroah-Hartman používají dvoufázové ověřování zhruba měsíc a zatím na žádný závažný problém nenarazili.

       

Komentáře

[aubi]

Omlouvám se, ale tohle nešlo vydržet.

Nejprve jsou vývojáři značně závislý (asi jsou z toho tvrdý ), ale teď můžou požádat o začazení až na 30 dní.

Samozřejmě díky za článek, Jaderné novinky si vždycky rád přečtu.

[Petr Tomášek]

ale teď můžou požádat o začazení až na 30 dní.

rasisti!

[Tadeáš Pelech]

Díky za upozornění, za ty jazykové úlety se omlouvám.

[kapo]

...ale teď můžou požádat o začazení až na 30 dní.

Tak to je krásný překlep

[Roger]

Přidávám se s prosbou o sjednocení mechanismů ("mechanizmuz" je docela síla).