On Tue, Aug 27, 2024 at 02:30:45PM +0200, Lukas Hruska wrote: > Summary > ------- > > This is a significantly simplified version of the original klp-convert tool. > The klp-convert code has never got a proper review and also clean ups > were not easy. The last version was v7, see > https://lore.kernel.org/r/20230306140824.3858543-1-joe.lawrence@xxxxxxxxxx > > The main change is that the tool does not longer search for the > symbols which would need the livepatch specific relocation entry. > Also klp.symbols file is not longer needed. > > Instead, the needed information is appended to the symbol declaration > via a new macro KLP_RELOC_SYMBOL(). It creates symbol with all needed > metadata. For example: > > extern char *saved_command_line \ > KLP_RELOC_SYMBOL(vmlinux, vmlinux, saved_command_line, 0); > > would create symbol > > $>readelf -r -W <compiled livepatch module>: > Relocation section '.rela.text' at offset 0x32e60 contains 10 entries: > Offset Info Type Symbol's Value Symbol's Name + Addend > [...] > 0000000000000068 0000003c00000002 R_X86_64_PC32 0000000000000000 .klp.sym.rela.vmlinux.vmlinux.saved_command_line,0 - 4 > [...] > > > The simplified klp-convert tool just transforms symbols > created by KLP_RELOC_SYMBOL() to object specific rela sections > and rela entries which would later be proceed when the livepatch > or the livepatched object is loaded. > > For example, klp-convert would replace the above symbols with: > > $> readelf -r -W <livepatch_module_proceed_by_klp_convert> > Relocation section '.klp.rela.vmlinux.text' at offset 0x5cb60 contains 1 entry: > Offset Info Type Symbol's Value Symbol's Name + Addend > 0000000000000068 0000003c00000002 R_X86_64_PC32 0000000000000000 .klp.sym.vmlinux.saved_command_line,0 - 4 > > > Note that similar macro was needed also in the original version > to handle more symbols of the same name (sympos). > > Given the above, add klp-convert tool; integrate klp-convert tool into > kbuild; add data-structure and macros to enable users to annotate > livepatch source code; make modpost stage compatible with livepatches; > update livepatch-sample and update documentation. > > > Testing > ------- > > The patchset selftests build and execute on x86_64, s390x, and ppc64le > for both default config (with added livepatch dependencies) and a larger > SLE-15-ish config. > > > Summary of changes in this minimal version v3 > ------------------------ > > - klp-convert: symbol format changes (suggested by jlawrence) > - samples: fixed name of added sample in Makefile (suggested by pmladek) > - selftests: added ibt test case as an example (DON'T MERGE) > - fixed all suggested small changes in v2 > > Previous versions > ----------------- > > RFC: > https://lore.kernel.org/r/cover.1477578530.git.jpoimboe@xxxxxxxxxx/ > v2: > https://lore.kernel.org/r/f52d29f7-7d1b-ad3d-050b-a9fa8878faf2@xxxxxxxxxx/ > v3: > https://lore.kernel.org/r/20190410155058.9437-1-joe.lawrence@xxxxxxxxxx/ > v4: > https://lore.kernel.org/r/20190509143859.9050-1-joe.lawrence@xxxxxxxxxx/ > v5: > (not posted) > https://github.com/joe-lawrence/klp-convert-tree/tree/klp-convert-v5-devel > v6: > https://lore.kernel.org/r/20220216163940.228309-1-joe.lawrence@xxxxxxxxxx/ > v7: > https://lore.kernel.org/r/20230306140824.3858543-1-joe.lawrence@xxxxxxxxxx/ > v1 minimal: > https://lore.kernel.org/r/20231106162513.17556-1-lhruska@xxxxxxx/ > v2 minimal: > https://lore.kernel.org/r/20240516133009.20224-1-lhruska@xxxxxxx/ > Hi Lukas, Thanks again for posting the patchset and trying a simpler approach. I tested with latest kpatch-build tree with no ill effects -- essentially klp-convert is safe to run against .ko files that already contain klp-relocations. I would prefer more extensive selftests for various klp-relocation types (as well as symbol position), however I believe wasn't the point of the minimal version of this patchset. We can add more tests later. Anyway, now we have two RFC / patchsets supporting in-tree creation of klp-relocations (klp-convert and Josh's objtool patchset). I think we need to figure out whether one precludes the other, can they co-exist, or does that even make sense. Since LPC is right around the corner, does it make sense for folks to sync up at some point and talk pros/cons to various approaches? We don't have a microconference this year, but perhaps over lunch or beers? -- Joe
