On
8/8/19 1:51 PM, Pawel Wieczorkiewicz wrote:
The patched ELF object file contains all sections and symbols as
resulted from the compilation. However, certain symbols may not be
copied over to the resulting object file, due to being unchanged or
not included for other reasons.
In such situation the resulting object file has the entire sections
copied along (with all their entries unchanged), while some of the
corresponding symbols are not copied along at all.
This leads to having incorrect undefined (STN_UNDEF) entries in the
final hotpatch ELF file.
The newly added function livepatch_strip_undefined_elements() detects
and removes all undefined RELA entries as well as their corresponding
PROGBITS section entries.
Since the sections may contain elements of unknown size (sh.sh_entsize
== 0), perform the strip only on sections with well defined entry
sizes.
After replacing the stripped rela list, it is assumed that the next
invocation of the kpatch_rebuild_rela_section_data() will adjust all
section header parameters according to the current state.
The
code in this patch seems to be very similar (i.e. somewhat copy-and-pasted) to kpatch_regenerate_special_section() which prunes the rela list and rebuilds the corresponding text section according to the predicate should_keep_rela_group(). The intent of the
function also seems to be the same (only keep elements that are needed).
In
what situations does the existing function not do the right thing?
Can
should_keep_rela_group() be updated instead?
Yes, the code is largely based on the kpatch_regenerate_special_section(). However, the livepatch_strip_undefined_elements() and kpatch_regenerate_special_section()
have different "granularity" and different scope.
1. Scope
- livepatch_strip_undefined_elements(): all RELA sections
- kpatch_regenerate_special_section(): special RELA sections
2. "granularity"
- livepatch_strip_undefined_elements(): all relas to be checked
- kpatch_regenerate_special_section(): all relas in a group are copied
I think it should be possible to create a common function with the base functionality that could take most of the common code in and then be used from within both of the functions.
However, I did not want to touch existing functionality and I am afraid the changes may result in a pretty convoluted code.
If you think it is still worth it, I can give it a shot.
Thanks,
--
Ross
Lagerwall
