mbox series

[v1,0/5] livepatch: klp-convert tool - Minimal version

Message ID 20231106162513.17556-1-lhruska@suse.cz (mailing list archive)
Headers show
Series livepatch: klp-convert tool - Minimal version | expand

Message

Lukas Hruska Nov. 6, 2023, 4:25 p.m. UTC
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@redhat.com

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

- rebase for v6.5
- cleaned-up SoB chains (suggested by pmladek)
- klp-convert: remove the symbol map auto-resolving solution
- klp-convert: add macro for flagging variables inside a LP src to be resolved by this tool
- klp-convert: code simplification

Previous versions
-----------------

RFC:
  https://lore.kernel.org/lkml/cover.1477578530.git.jpoimboe@redhat.com/
v2:
  https://lore.kernel.org/lkml/f52d29f7-7d1b-ad3d-050b-a9fa8878faf2@redhat.com/
v3:
  https://lore.kernel.org/lkml/20190410155058.9437-1-joe.lawrence@redhat.com/
v4:
  https://lore.kernel.org/lkml/20190509143859.9050-1-joe.lawrence@redhat.com/
v5:
  (not posted)
  https://github.com/joe-lawrence/klp-convert-tree/tree/klp-convert-v5-devel
v6:
  https://lore.kernel.org/live-patching/20220216163940.228309-1-joe.lawrence@redhat.com/
v7:
  https://lore.kernel.org/all/20230306140824.3858543-1-joe.lawrence@redhat.com/

Comments

Marcos Paulo de Souza April 10, 2024, 3:32 p.m. UTC | #1
On Mon,  6 Nov 2023 17:25:08 +0100 Lukas Hruska <lhruska@suse.cz> 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@redhat.com
> 
> 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
> ------------------------
> 
> - rebase for v6.5
> - cleaned-up SoB chains (suggested by pmladek)
> - klp-convert: remove the symbol map auto-resolving solution
> - klp-convert: add macro for flagging variables inside a LP src to be resolved by this tool
> - klp-convert: code simplification

Do we have anything that blocks klp-convert-mini to be merged, or something that
needs to be fixed?

Thanks,
  Marcos

> 
> Previous versions
> -----------------
> 
> RFC:
>   https://lore.kernel.org/lkml/cover.1477578530.git.jpoimboe@redhat.com/
> v2:
>   https://lore.kernel.org/lkml/f52d29f7-7d1b-ad3d-050b-a9fa8878faf2@redhat.com/
> v3:
>   https://lore.kernel.org/lkml/20190410155058.9437-1-joe.lawrence@redhat.com/
> v4:
>   https://lore.kernel.org/lkml/20190509143859.9050-1-joe.lawrence@redhat.com/
> v5:
>   (not posted)
>   https://github.com/joe-lawrence/klp-convert-tree/tree/klp-convert-v5-devel
> v6:
>   https://lore.kernel.org/live-patching/20220216163940.228309-1-joe.lawrence@redhat.com/
> v7:
>   https://lore.kernel.org/all/20230306140824.3858543-1-joe.lawrence@redhat.com/
Miroslav Benes April 11, 2024, 6:27 a.m. UTC | #2
Hi,

> > Summary of changes in this minimal version
> > ------------------------
> > 
> > - rebase for v6.5
> > - cleaned-up SoB chains (suggested by pmladek)
> > - klp-convert: remove the symbol map auto-resolving solution
> > - klp-convert: add macro for flagging variables inside a LP src to be resolved by this tool
> > - klp-convert: code simplification
> 
> Do we have anything that blocks klp-convert-mini to be merged, or something that
> needs to be fixed?

there is feedback from Petr and I agree with him that a selftest would be 
appropriate.

Lukas, are you planning to send v2 with everything addressed?

Miroslav
Lukas Hruska April 11, 2024, 1:58 p.m. UTC | #3
Hi,

> > Do we have anything that blocks klp-convert-mini to be merged, or something that
> > needs to be fixed?
> 
> there is feedback from Petr and I agree with him that a selftest would be 
> appropriate.
> 
> Lukas, are you planning to send v2 with everything addressed?

Yes, I definitely want to send v2 soon. I am starting to work on it
today and hopefuly I will be able to send it next week.

Lukas