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ě.