Portál AbcLinuxu, 23. dubna 2024 23:29
Stav vydání jádra. Citáty týdne: Tycho Andersen a James Bottomley. WireGuard v upstreamu.
Kernel release status. Jonathan Corbet. 8. srpna 2018
Současné vývojové jádro je 4.18-rc8, vydané 5. srpna. Linus řekl: „Jak už několikrát padlo v příslušných vláknech, poslední týden nebyl úplně bezproblémový a 4.18 nakonec bude jedno z těch vydání, kterým se dostane týden testování rc navíc.“
Stabilní aktualizace: 4.17.12, 4.14.60 a 4.9.117 byly vydány 3. srpna, poté 6. srpna následovaly aktualizace 4.17.13, 4.14.61, 4.9.118 a 4.4.146. Aktualizace 4.17.14, 4.14.62, 4.9.119, 4.4.147 a 3.18.118 byly v době psaní tohoto textu revidovány a měly vyjít 9. srpna.
Quotes of the week. 8. srpna 2018
Dinesh Subhraveti tvrdí, že část téhle řady [seccomp] může být patentovaná. I když mi neposkytl nic, podle čeho bych to mohl ověřit, zatím tu skupinu patchů pozdržím.
Ohledně toho, jak tyto situace obecně řešit.
Za prvé, nikdy v e-mailové konferenci nediskutujte o detailech. Patenty jsou problematická oblast, ve které je potřeba důvěrnosti a když to tak nebude, prospěje to jenom držiteli patentu.
Za druhé, neurčité hrozby (jako tato) můžeme v klidu ignorovat. Díky podmínkám GPL a díky krokům provedeným OIN máme licence k širokému portfoliu patentů, takže u každé neurčité hrozby, že existuje nějaký patent, bychom měli předpokládat, že k němu máme řádnou licenci, dokud se vyhrožování nekonkretizuje.
Konečně, když už se neurčitá hrozba konkretizuje (což znamená citaci čísla patentu a držitele), měli byste využít zdroje, které máme k dispozici, k prošetření případu. Pravděpodobně to bude na OIN, ale začít byste měli poradou s tím, kdo řeší příspěvky do projektu u vaší firmy. Pokud přispíváte jako jednotlivci, můžete začít konzultací poskytnutou Linux Foundation.
WireGuarding the mainline. Jonathan Corbet. 6. srpna 2018
VPN tunel WireGuard se už několik let vyvíjí – a přitahuje pozornost. Na Linux Weekly News si můžete přečíst recenzi z května. Ačkoliv je WireGuard k nalezení v repozitářích řady distribucí, zatím se nedodává s hlavní větví jádra, protože její autor Jason Donenfeld se k tomu dříve nedostal – to se změnilo 31. července, kdy Donenfeld napsal, aby se lidé z jádra na WireGuard podívali. Dostat samotnou WireGuard do hlavního stromu by asi nebylo těžké, to se však nedá říct o začlenění některého podpůrného kódu.
WireGuard implementuje jednoduchý tunelovací protokol, který umožňuje směrovat síťový provoz přes poskytovatele virtuální privátní sítě. Při jejím vývoji byl kladen důraz na to, aby byla malá, snadno verifikovatelná a výkonná, spíš než na objem funkcí. Ve zprávě doprovázející patch se praví, že [WireGuard] „používají obrovské společnosti s enormním síťovým provozem.“ Tomu, aby WireGuard byla široce dostupná, bylo věnováno jisté úsilí, které pomohlo vybudovat významnou uživatelskou komunitu. Nicméně zásadní krok ke zpřístupnění takovéhoto softwaru spočívá v jeho zahrnutí do jader všech uživatelů, a to znamená dostat ho do upstreamu.
Zatím se kód WireGuard nejeví příliš kontroverzní. Je potřeba vypořádat se s řadou menších problémů, a to včetně nevyhnutelného požadavku (na kód týkající se sítí), že deklarace proměnných bude uspořádána do „reverzního vánočního stromku“, jakožto i několika dalších záležitostí, které by mělo snadné vyřešit. Nejspíš to zabere pár iterací, ale pro osud WireGuard pravděpodobně bude klíčová tato „recenze“ Linuse Torvaldse:
Všiml jsem si, že Jason skutečně poslal žádost o začlenění wireguard do jádra.
Můžu ještě jednou zopakovat, jak se mi to líbí a že doufám v brzké začlenění? Ten kód možná není dokonalý, ale proletěl jsem ho a ve srovnání s hrůzami OpenVPN a IPSec jde o umělecký počin.
Možná je v tom ale háček. WireGuard, jak by se dalo čekat, šifruje provoz mezi konci tunelu a koncové body provádějí kryptografickou autentizaci svých protějšků. Jádro sice poskytuje obsáhlý kryptografický subsystém, který by se k tomu dal použít, jenže se ukazuje, že Donenfeld není z tohoto API zrovna nadšený. Mezi plány, jak dostat WireGuard do upstreamu, z minulého listopadu uvedl záměr „zapojit se do mnohačetné snahy o přepracování kryptografického API.“ Nakonec vytvořil zcela nový jaderný kryptografický subsystém a WireGuard založil na něm namísto původního jaderného kryptografického kódu.
Není si těžké představit, i když jste třeba nový kód nezkoumali, že prosadit snahu překopat zavedené ústřední API bude docela oříšek. Donenfeld si to ještě zkomplikoval, když své kryptografické API „Zinc“ zaslal jako jediný patch o 24 tisících řádek – filtry e-mailové konference ho prostě zahodily. Je však k dispozici v Donenfeldově repozitáři, kdyby se na něj někdo chtěl podívat. Seznam změn popisuje důvody ke vzniku Zincu, a to řekněme velmi sebejistým jazykem typickým pro vývojáře zabývající se bezpečností. Zdá se, že z principu dráždí natolik, aby se čtenář nezabýval skutečným obsahem.
Stručně řečeno, Donenfeld tvrdí, že jaderné kryptografické API je příliš složité a komplikované na použití. Je navržené tak, aby pracovalo s hardwarovou akcelerací a umožňovalo sofistikované skládání operací, takže uživatelé musejí první provést úkony jako kontexty transformací a seznamy rozsypání/sesbírání dat, která se mají šifrovat. Většina uživatelů ale chce prostě provést přímočarou kryptografickou operaci a nemá žádný užitek z komplikovaného jaderného API, jemuž se tím pádem vývojáři raději vyhýbají. Co je potřeba, říká Donenfeld, je jiný typ kryptografické knihovny:
V jádře obvykle nejde o to, hledat nové způsoby využití šifrování, ale spíš implementovat různé konstrukce, takže v podstatě potřebuje knihovnu primitiv a až na několik zvláštních výjimek nikoliv vysoce abstraktní systém připravený k nasazení v podnikovém softwaru.
Zinc se touto filosofií řídí: poskytuje jednoduchou sadu kryptografických algoritmů, které je možné zavolat bez jakýkoliv komplikovaných vyvolávacích rituálů. Řada těchto algoritmů poskytuje funkcionalitu vzhledem ke stávající kryptografické vrstvě v jádře duplicitní. V seznamu změn je řeč o tom, že jaderný kód by časem měl přejít na Zinc, leč tuto práci dosud nikdo neudělal.
Ačkoliv se Zincu nedostalo přijetí s otevřenou náručí, nebyl ani přímo zavržen. Když Donenfeld řeší složitost současného kryptografického API, dává to smysl. Doposud nejzevrubnější zpětnou vazbu poskytl jaderný vývojář zabývající se kryptografií Eric Biggers, který poté, co se vyjádřil, že chce WireGuard v upstreamu, ohledně Zincu řekl, že „několik věcí nemíří správným směrem.“ Například by byl rád, kdyby některé algoritmy byly vyčleněny a přidány zvlášť, aby se skupina patchů snáze revidovala. Upozornil, že Zinc nemůže podporovat hardwarovou akceleraci šifrování, což Donenfeld považuje za vlastnost. Všehovšudy se povaze Zincu v principu nebrání, ale v implementaci by rád viděl řadu změn.
Také Andy Lutomirski se vyjádřil v zásadě pozitivně, přičemž poznamenal, že v minulosti se pokusil do kryptografického kódu dostat některé podobné změny. Podpora hardwarové akcelerace, řekl, by se měla implementovat nad Zincem; příslušný kód by pak mohl používat nutně komplexnější API, přičemž implementace Zincu by posloužila jako záložní varianta pro případy, kdy hardwarová akcelerace není k dispozici nebo se z jiných důvodů nehodí. Lutomirsky se přidal k řadě Biggersových návrhů změn. Herbert Xu, správce kryptografického subsystému, se mezím diskuze neúčastnil.
Donenfeld byl obecně otevřený návrhům na změny a přislíbil, že nová verze Zincu mnoho z nich zohlední. Tím téměř jistě debata nekončí – tak zásadní operace v ústředním subsystému jádra neproběhne jen tak přes noc. Ale pokud zúčastnění zůstanou otevření tomu, co říkají ostatní, zbývající hrany by se mělo podařil uhladit poměrně brzy. WireGuard pak bude na nejlepší cestě do upstreamu.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.