On
8/8/19 1:35 PM, Pawel Wieczorkiewicz wrote:
…snip...
* The rela groups in the .fixup section vary in size. The beginning of each
* .fixup rela group is referenced by the .ex_table section. To find the size
@@ -1072,6 +1090,18 @@ static struct special_section special_sections[] = {
.name
= ".altinstructions",
.group_size
= altinstructions_group_size,
},
+ {
+ .name
= ".altinstr_replacement",
+ .group_size
= undefined_group_size,
+ },
+ {
+ .name
= ".livepatch.hooks.load",
+ .group_size
= livepatch_hooks_group_size,
+ },
+ {
+ .name
= ".livepatch.hooks.unload",
+ .group_size
= livepatch_hooks_group_size,
+ },
{},
};
Unless
I'm misunderstanding something, I can't see how kpatch_regenerate_special_section would work with .altinstr_replacement having a group size of 0. It looks to me like the for loop in that function would become an infinite loop (due to incrementing by group_size)
and should_keep_rela_group would always return false.
AFAICS, the group_size 0 sections are never actually processed by the kpatch_regenerate_special_section().
They are not RELA sections and the following check excludes them from this processing:
static void kpatch_process_special_sections(struct kpatch_elf *kelf)
{
[…]
for (special = special_sections; special->name; special++) {
[…]
sec = sec->rela;
if (!sec)
continue;
kpatch_regenerate_special_section(kelf, special, sec);
}
Nevertheless, you are right. It does not make much sense to rely on this assumption.
I will add explicit checks to kpatch_regenerate_special_section() and friends dealing with group_size 0 sections.
Regards,
--
Ross
Lagerwall
Best,
Pawel Wieczorkiewicz
Amazon Development Center Germany GmbH
Krausenstr. 38
10117 Berlin
Geschaeftsfuehrung: Christian Schlaeger, Ralf Herbrich
Eingetragen am Amtsgericht Charlottenburg unter HRB 149173 B
Sitz: Berlin
Ust-ID: DE 289 237 879
|
