Vlákno názorů k článku
Fedora nemá v plánu nasadit patchování jádra za běhu od marekp - Ty patch jsou predpokladam binarni, jak vlastne takovy...

Ty patch jsou predpokladam binarni, jak vlastne takovy patch vznikne? mam distribucni jadro, objevi se v nem chyba, opravi ji a udelaji diff nove-puvodni jadro a to co zustane je ten patch ktery se aplikuje nekam na spravne misto v pameti? nebo to stejne musim "otocit" tak jak to delal napr. kexec?

Obecně mají patchované funkce nějaký entry point. Pokud jde o syscall, existuje většinou nějaká tabulka čísel služeb a pointerů na funkce které je vykonávají (ve Windows je to KiServiceTable). Změnou pointeru můžete celkem jednoduše přesměrovat daný syscall na nový kód. Pokud tenhle přístup nelze použít, můžete přepsat začátek kódu staré funkce skokem na novou verzi.

Samozřejmě to přináší jisté problémy. Na prvním místě to není univerzální, protože pokud patch mění datové struktury kernelu, nebo je používá jiným způsobem, tak tuhle techniku nelze použít. Na druhém místě se musíte ujistit, že vám do měněného kódu nikdo nevlítne. Kpatch to řeší zastavením všech procesů po dobu patchování, kGraft po omezenou dobu běží obě verze kódu podle toho kdo je volá.

Ve výsledku je to technika kterou lze použít na jednoduché opravy. Pokud měníte řekněme if (a==1) na if (a==2) :), a věříte že je live patching implementovaný správně (což po zkušenostech třeba s ftrace chce dost víry), tak to bude fungovat. Na použití této techniky na upgrade kernelu na novou verzi ovšem zapomeňte.

Teoreticky by šlo i zvést paralelně kompletní nový kernel, zastavit systém, transformovat datové struktury, a začít používat nový kernel. Průšvih je s tou transformací datových struktur, kterou z žádného diffu automaticky nevygenerujete. Asi by se to dalo řešit nějakými metadaty v kódu, ale to by znamenalo ručně projít celý kernel. Navíc ta transformace dat by mohla dost trvat.

Navíc je otázkou, jestli dneska ještě reboot někoho trápí. Je to celkem rychlá akce, a u kritických systémů není problém používat víc nodů, které se patchují a rebootují postupně.

To asi nepracujete se servery, tam reboot a nasledna inicializace trva minuty (napr HP DL380G8 to ma k bootladeru asi 3).

DL380G8 je pět let starý model, a POST na něm trvá dlouho primárně kvůli ROM RAID controlleru. Zkuste to s UEFI firmwarem a RAID controllerem s UEFI modulem. Výsledek bude výrazně lepší.

Oprava, je to tři roky starý model.

Jeden reboot nikoho netrapi, ale tech 40 v pripade widli uz celkem nasere co? S jakou verzi se budou umet widle patchnout jednim vrzem?

Při patchování běžícího systému je potřeba jeden restart. Při instalaci jich může být víc, ale těžko 40. Navíc schopní admini umí dodat patche rovnou na instalační médium.