Vlákno názorů k článku Záplatování jádra za běhu: kGraft to zvládne bez výpadku od Marek Knápek - Za prvé: Windows má tohleto "už sto let",...
-
Za prvé: Windows má tohleto "už sto let", nevím jak pro jádro, ale pro user space knihovny (user32.dll, kernel32.dll, …) určitě. Používají to některé opravy přicházející skrze Windows Update. Na začátek funkce se přidá sedm bajtů, dva pro "jmp near", a pět pro INT3. Těch pět může patchovací mechanismus v klídku neatomicky přepsat na "jmp far" a později atomicky přepsat "jmp near" na "nop nop". Odskok, jak už tu bylo zmíněno, může být někam do trampolíny, která rozhodne, jestli se bude volat nová varianta funkce nebo původní. Může také přepnout všechny patchovane funkce najednou.
Za druhé: Atomicky vyměnit osm bajtů na x86 samozřejmě lze. Předchází se tak ABA problému u lock-free datových struktur. Ale pro volání kódu (a tedy patchovani kódu za běhu) je to nepoužitelné.
Marek
-
Jiri Kosina (neregistrovaný)
Za prvé: Windows má tohleto "už sto let", nevím jak pro jádro, ale pro user space knihovny (user32.dll, kernel32.dll, …) určitě. Používají to některé opravy přicházející skrze Windows Update</strongi>
O windows vim jen z doslechu, ale co jsem slysel, tak ten mechanismus (tak jak ho popisujete, tzn. s tim docela peknym trikem pres short jmp tesne pred funkci) tam kdysi meli, ale nepouzivali ho, a ted uz to tam snad ani negeneruji. Ale je to zarucena zprava od agentury JPP.
Za druhé: Atomicky vyměnit osm bajtů na x86 samozřejmě lze. Předchází se tak ABA problému u lock-free datových struktur. Ale pro volání kódu (a tedy patchovani kódu za běhu) je to nepoužitelné.
Mate pravdu, je to tam napsano nepresne, a pri kontrolnim cteni textu jsem si toho nevsiml. Ve strucnosti jde o to, ze vymenu nopu za (far)jmp+adresa nelze udelat atomicky, a pro kod je potreba stejne prepisovani pres INT3 delat kvuli CPU (i kdyby byl short), ktere muze byt zrovna dany kus uz fetchnuty do pipeline resp. I$ (kde se koherence a-la MESI neprovadi).
Prilezitostne poslu Petrovi Krcmarovi nejaky navrh na reformulaci, diky za pripominku. -
Upřesnění: Windows mají na začátku funkcí "dvoubajtový nop" v podobě mov edi, edi a pět vyhrazených bajtů před funkcí, které by tam s nejvyšší pravděpodobností byly tak jako tak kvůli zarovnání. Mám k dispozici Windows 7 32 bit a tento pattern tam stále je (minimálně v user-space kernel32.dll, kernelbase32.dll a ntdll.dll). Marek.
-
Oprava mého předchozího příspěvku: Windows má na začátku patchovatelné funkce instrukci mov edi, edi (která se chová jako dvoubajtový nop). A pět volných bajtů před funkcí.
Těch pět bajtů mohou přepsat na skok typu "far jmp" někam do trampolíny a potom atomicky přepsat ten "fancy nop" na skok typu "near jmp" na ten plnohodnotný "far jmp".
-
KateStříbrný podporovatelWindows má tohleto už „sto let“ možná pro pár věcí, ten zbytek vynucuje restart OS, protože zamykání souborů. Vyměnit za běhu systémové knihovny a použít je prostým restartem aplikací prostě nejde, musí se otočit celý systém a ještě čekat na rozkopírování souborů před vypnutím a při startu OS. Takže jakýkoliv výpadek serveru při update je ještě delší než by být musel. Prostě super! :)
